A safer move starts before migration day.

Moving records is only one part of moving a business to new software. A customer record can arrive successfully while its order history is disconnected. A total can look correct while a date has been interpreted differently.

Before a migration, decide what evidence will show that the new system is usable. A successful import message is useful evidence, but it is not the whole acceptance check.

Define what is moving

Make a list of the record types in scope: customers, products, open orders, historical transactions, files, or other information your team needs. For each, name the source, the destination, and the person who can explain what it means.

Separate records needed for daily operations from records that may belong in a controlled archive. Agree retention and access requirements with the people responsible for them. This guide does not set those requirements for your organisation.

For each field, document the intended mapping. A useful mapping records the destination field, expected format, treatment of empty values, and any transformation. Give particular attention to identifiers, dates, currencies, units, and relationships between records.

Choose checks that reflect real work

Prepare representative examples before the migration. Include ordinary records and awkward ones: an inactive customer, an incomplete address, a product with variants, an order with a partial fulfilment.

Ask users to verify a short set of complete tasks in the destination system. Can someone locate the customer, inspect the relevant history, and complete the next step they are responsible for?

Use more than one kind of check:

Counts alone cannot establish that every field is correct. Record exceptions and decide which prevent launch.

Rehearse the transition

AWS's pre-cutover guidance recommends rehearsing the cutover and documenting tasks, owners, timing, testing, and contingency arrangements. Although its context is cloud migration, that preparation is also a useful prompt when planning a business-system transition.

Use a protected test environment and appropriately controlled data. Record how long the import and checks take, which steps need manual intervention, and what access the team requires. Feed those findings back into the live plan.

The rehearsal should help answer a practical question: can the team complete the agreed steps within the available operating window?

Decide how live changes are handled

A source system may continue receiving new orders or edits while an initial copy is being prepared. Decide whether there will be a write freeze, a final catch-up transfer, a replication process, or another approach supported by the systems involved.

Define exactly when the new system becomes authoritative. Tell staff where to work during the transition and how to report a problem. Avoid leaving two writable systems without a rule for resolving differences.

Make recovery a decision with an owner

A fallback needs a trigger, an owner, and a procedure that has been tested. Agree who can pause the launch, how long the team will investigate a failure, and what conditions require recovery instead of continuing.

Returning to the old application does not automatically preserve new work entered after the switch. Account for those changes explicitly. In some situations, fixing the new system forward may be preferable; the team should assess that choice before an incident, as well as during it. AWS's cutover guidance provides further context for rollback decisions.

Keep ownership after the switch

Assign a period of focused post-launch checking, with named people responsible for resolving discrepancies. Confirm that connected applications point to the intended system and that staff can find the support route.

The deliverable is a usable operational handover: accepted records, known exceptions, recovery arrangements, and clear ownership. Treat it as part of the project when comparing software proposals, rather than an unpriced task for launch week.