How to Approve Data Migration Before Software Cutover

By Essential Designs Team | Published September 21, 2026 | 10 min read

Direct answer: approve a software data migration only when the business owner can demonstrate that the right records arrived, the important relationships and calculations still work, exceptions are understood, and the new system supports the real tasks people must perform after cutover. A successful import job is evidence, but it is not acceptance.

This guide is for operations, product and technology leaders replacing a business system. It concentrates on the buyer's go/no-go decision, not a vendor-specific migration tool. The details of retention, privacy and regulated records require separate review by the appropriate specialists.

Key Takeaways

• Define the business evidence needed for acceptance before the first test import.
• Use more than record counts: check relationships, representative records and the workflows that consume them.
• Give each discrepancy an owner and a disposition rather than hiding it in an overall pass rate.
• Specify the point after which a simple return to the old system is no longer safe.
• Make a named business owner, not only the migration script, responsible for the final decision.

Why Can a Migration Report Say Success While Staff Cannot Work?

A transfer can finish without an error and still leave a customer with the wrong account owner, an order without its line items, a historical status translated into the wrong new state, or a report that no longer reconciles with finance. Technical completion answers whether a process ran. Business acceptance answers whether the resulting information supports the agreed work.

The distinction matters during custom software development because the new application often changes the data model. A field that was free text in the old system may become a controlled value. One customer record may split into several related entities. Duplicate contacts may have been tolerated for years, then become impossible to use in the new workflow. Those decisions are product decisions as well as import decisions.

Before a development partner estimates the work, identify the systems and owners in the software requirements checklist. This article picks up at the next question: what evidence will persuade the business to accept the moved data?

The Five-Evidence Acceptance Gate

Use five evidence types. The exact thresholds belong to your system and must be agreed in advance; there is no universal acceptable error percentage.

Evidence	Question to answer	Example proof	Owner
Coverage	Did the agreed population move?	Source-to-target counts by entity, date range and inclusion rule	Data owner
Relationships	Do linked records still point to the correct people and objects?	Sampled account, order, invoice and attachment chains	Process owner
Meaning	Did fields and historical states keep their intended meaning?	Approved mapping rules and reviewed exception cases	Business analyst
Workflows	Can users complete the tasks that depend on the data?	Task-based acceptance tests using migrated records	Operational lead
Reconciliation	Do critical totals and reports agree at the defined cut-off?	Signed comparison of source and target reports	Finance or reporting owner

For a distributor, one acceptance test might trace an active account through its addresses, open orders, line items and fulfilment status. Another might compare the value of open orders by region at the same cut-off time in both systems. These are hypothetical examples. The organization must decide which records are material and which differences can be accepted.

Decide What Moves, What Stays and What Is Archived

The first scope decision is not the migration tool. It is the destination of each information class. Active customers may need to be editable in the new application. Closed orders may need to be searchable but not editable. Some historical material may be retained in a controlled archive instead of transformed into a new operational model. Define those outcomes explicitly.

Write an inclusion rule with an effective date and a source of truth. For example, "all open service tickets plus closed tickets from the agreed retention window" is testable; "all useful history" is not. Record exclusions such as test records, duplicates awaiting review and data owned by another system. Assign each exception a decision, rather than silently dropping it.

A mapping register should explain old field, new field, transformation, default rule, reference table, owner and test case. Give particular attention to identifiers, dates, currencies, statuses and parent-child links. If an old field cannot be mapped honestly, do not substitute a convenient but misleading value. Surface the uncertainty to the business owner.

Test With Realistic Tasks, Not Just Rows

Run a rehearsal in a non-production environment using an approved representative dataset. Protect sensitive information according to the organization's policy. Include ordinary records and difficult cases: cancelled transactions, merged accounts, unusual characters, missing values, archived products and historical changes. The point is to test the cases that affect work, not just the cleanest sample.

Ask users to perform tasks they will need on the first morning: find an existing customer, update an open item, see its history, produce a familiar report and resolve an exception. Note both defects and confusing transformations. A person who cannot recognise the account they own will not be reassured by a row-count match.

AWS's Database Migration Service validation documentation describes technical validation between source and target. Use that kind of tool evidence alongside business review, not as a replacement for it. The UK's legacy-systems service guidance also recommends understanding constraints and making changeover manageable before replacing an older system.

What Belongs in the Cutover Decision?

At the final rehearsal, the sponsor needs a compact decision record. Include the source snapshot or extraction time, mapping version, import version, validation results, open discrepancies, severity, owner, expected resolution, proposed cutover time and recovery option. Everyone should know whether new transactions will continue entering the old system during the move and how the final change set will be handled.

Microsoft's data-migration cutover guidance highlights timing, communication, validation, rollback planning and monitoring. AWS's cutover guidance calls for predefined rollback checkpoints and an identified decision-maker. These are useful principles beyond either vendor's specific products.

There is a crucial boundary: once people enter new data in the replacement system, returning to the old one may require copying those changes back or choosing a different recovery approach. "We can always roll back" is not a plan unless the team has worked through that boundary and tested the data consequences.

A Simple Go/No-Go Record

1. Scope: state exactly which entities, locations, periods and users are in this release.
2. Evidence: link the coverage, relationship, meaning, workflow and reconciliation results.
3. Exceptions: list every material unresolved discrepancy with its impact and owner.
4. Operational readiness: confirm user access, support contacts, monitoring and the first-day work plan.
5. Recovery: name the decision window, checkpoint, responsible person and handling of new transactions.
6. Decision: have the business sponsor record go, conditional go or no-go, with the reasons and time.

A conditional go is not a way to bury defects. It is appropriate only when the owner understands an exception, has a controlled workaround, and can explain why it does not compromise the core work. If a critical business relationship or total cannot be trusted, a delayed launch may be the more responsible decision.

How This Fits a Replacement Project

Essential Designs designs and develops custom business software and supports applications after launch. A migration acceptance gate belongs in discovery and delivery planning, not only in the final weekend. It can affect architecture, workflow design, test environments, reporting and support.

For a broader phased replacement approach, see the existing legacy-system replacement guide. For ongoing operation after cutover, review software support. To plan a replacement project around your actual systems and acceptance evidence, discuss the scope with Essential Designs.

Sources and Maintenance

Sources reviewed September 21, 2026: AWS DMS data validation; AWS migration cutover; Microsoft cutover planning; and GOV.UK legacy-system guidance. This article presents a buyer-side decision framework, not a report of a specific Essential Designs client project. Review the guidance quarterly and after material changes to the cited sources.