How to Migrate Business Data Safely: Checks Before Go-Live

A safe business data migration starts with an agreed source of truth and ends with evidence that the new system holds the right records and supports the required work. Inventory the sources, approve the mapping, rehearse the import, reconcile the results and test recovery before cutover. An import success message alone does not prove that balances, relationships or attachments are correct.

This guide is for businesses moving records from an old application, database or export into a new system. It focuses on the checks needed before accepting the move. For workbook cleanup, formulas and spreadsheet-specific import steps, use the Excel-to-software migration guide.

About the examples: The tables below are planning templates with synthetic values. They are not client records, completed migration results or a claim that a particular product includes every listed capability. Adapt the checks to the source, target and agreed scope.

Start with a migration acceptance plan

Before choosing an import tool, agree on what must move, what may remain archived, who can approve changes and what evidence will permit go-live. Name a business data owner as well as the technical implementer. A developer can check that an import ran; an accounts or operations reviewer must confirm that the resulting records mean the right thing.

Use this sequence:

1. Inventory the sources and decide which records are authoritative.
2. Approve scope, mapping, identifiers and exception rules.
3. Rehearse with representative data in an isolated environment.
4. Compare records, relationships and business totals.
5. Test recovery and agree the final cutover decision.
6. Import final changes, verify workflows and record acceptance.

The illustration summarises the stages. The acceptance and recovery checks below determine whether it is appropriate to move between them.

Decide what data should move

A customer list, unpaid invoice, stored document and calculated report need different migration rules.

For each source, record its system, responsible role, approximate volume, export format, last update and relationship to other sources. If two systems disagree, assign someone to resolve the conflict before import. Keep an explicit exclusion register for records outside scope; exclusion must not silently become deletion.

Microsoft's migration-planning guidance distinguishes configuration, master and open-transaction data and describes mappings, dependencies and ownership. Those distinctions are useful references even when the destination is not Dynamics 365.

Protect source copies and control access

Preserve a dated source export and an appropriate system backup before transformation. Record what each contains and how it can be restored. A CSV export may omit attachments, audit history, permissions or configuration; it is not automatically a complete backup.

Use access-controlled storage and an agreed transfer method. Restrict access to the people who need the records, and agree how working copies will be retained or removed after acceptance. Public examples and initial discussions should use synthetic or appropriately redacted samples. Do not place customer exports in public file links or send production passwords through an enquiry form.

Test restoration in an isolated environment before relying on the backup. Record the result, required access, software version and missing elements. The business should understand the recovery limits before choosing a cutover window.

Approve mappings and stable identifiers

A mapping specification explains how a source value becomes a target value, including required fields, transformations, relationships and rejected records. Version it so the rehearsal and final import can be traced to approved rules.

Synthetic mapping example: These are illustrative fields and values, not a production schema.

Define dates, time zones, decimal precision, units and character encoding where relevant. Keep source identifiers separate from display names: similar customer names may belong to different businesses. Route uncertain duplicate matches to a reviewer and record approved merges so reconciliation can explain the reduced count.

Import order also matters. A transaction may require its customer, product or configuration record first. Frappe's Data Import documentation gives examples of required fields, import warnings, parent/child records and identifiers used for updates. These are tool-specific examples; confirm the equivalent behaviour in the actual destination.

Rehearse the import and its failure cases

Choose representative trial data rather than only the easiest records. Include missing required fields, duplicates, unusual characters, old dates, linked transactions and attachments when in scope.

The rehearsal should answer:

• Which records were accepted, rejected, skipped or merged, and why?
• Does retrying the same batch create duplicates or update existing records?
• Does a partial failure leave an incomplete transaction or relationship?
• Can rejected records be corrected without repeating successful work?
• Are dates, precision and status values interpreted correctly?
• Can the intended staff roles find and use the migrated records?

Keep trial work isolated from production. Review scheduled jobs, outbound emails, SMS, webhooks and payment actions so testing cannot trigger unintended business activity. Use supported integration test environments or controlled substitutes and record what was not tested.

Save the mapping version, import version, trial identifier, counts and error report. Unresolved critical discrepancies should block acceptance even if the tool reports that the upload completed.

Reconcile results before signing off

Reconciliation explains how approved source records correspond to target records. Counts are one check; they do not establish that fields, balances or relationships are correct. Two datasets can have the same number of rows and still disagree on important values.

Record the expected result, actual result, evidence reference, reviewer and unresolved exception for each check. Do not hide differences within a broad tolerance; explain intentional conversions or rounding rules and who approved them.

AWS DMS data validation distinguishes transferring data from comparing source and target values, and reports mismatches or records that cannot be validated. A small migration can use simpler comparison tools, but it still needs an explicit validation result.

Plan the final cutover

Cutover is when the new system becomes authoritative for the agreed workflows. Decide whether source writes will stop or a supported process will capture changes made during migration. Avoid an undefined period in which both systems accept transactions independently.

A runbook records the task sequence, owner, expected duration, completion evidence and stop condition:

1. Confirm the approved release, mapping and source scope.
2. Confirm reviewers, support access, backups and recovery readiness.
3. Freeze source changes or begin the agreed final-change capture.
4. Export and import the final approved dataset or delta.
5. Reconcile results and run role-based workflow checks.
6. Obtain the recorded go/no-go decision before normal operations resume.
7. Monitor the agreed operating cycle and reconcile remaining exceptions.

Include dependencies such as connected systems, reports and scheduled work. AWS pre-cutover guidance covers rehearsal, downtime, rollback and runbooks with task owners and sequence. Choose a method suited to the system; zero downtime should not be assumed.

Define recovery before new transactions begin

A rollback plan needs more than “restore the backup.” Record who makes the decision, its triggers, the latest safe return point, expected disruption and how restored data will be verified.

Synthetic decision example: An agreed control balance differs after the final import, and the cause cannot be resolved within the approved window. The business acceptance owner pauses go-live. The technical owner follows the rehearsed recovery procedure, and the reviewer verifies the restored state before operations resume.

Once users have created new transactions in the target, restoring an older snapshot can lose their work. Decide in advance how those transactions will be captured, reconciled and safely replayed, or whether a controlled correction is preferable. A simple restore is not a complete plan for this situation.

Keep the old system or archive available for agreed verification and retention needs. Retirement should have its own acceptance decision after dependencies and access to required history are checked.

Scope the cost and schedule from evidence

There is no dependable migration price or duration based only on row count. An estimate should state assumptions about source systems, data quality, relationships, historical depth, attachment volume, transformations, rehearsals, downtime constraints and reviewer availability.

Ask the quotation to separate extraction, cleanup, mapping, trial imports, reconciliation, cutover, training and agreed support. Identify who resolves incorrect source data and what happens if new formats or exceptions are discovered. A protected sample review and mapping exercise can clarify the work before committing to the full move.

Prepare the software requirement template, then connect migration scope to the software handover checklist and staff training plan. For CRM-specific fields and cutover considerations, see the CRM implementation guide.

Final acceptance and handover

Before acceptance, record:

• approved source scope, exclusions and mapping version;
• import outcomes and resolved or explicitly accepted exceptions;
• reconciliation results and business workflow checks;
• tested recovery procedure and cutover decision;
• staff guidance, support responsibilities and monitoring period;
• account names, access owners and secure storage references, without passwords or secret values in the handover document.

Keep migration evidence accessible to authorised reviewers. Use custom software services to discuss the wider system scope and web application services when workflows or portals are also being rebuilt.

Frequently asked questions

Should every historical record move?

Not necessarily. Agree which master records, open transactions, history and attachments the new system needs and what remains in a usable archive. Record the reasons and verify required history can still be retrieved. Retention obligations need advice appropriate to the business and record type.

Is matching the total number of rows enough?

No. Check identifiers, relationships, grouped business totals, attachments, permissions and representative workflows. Explain excluded, rejected and merged records separately.

What should happen to rejected records?

Keep an error report with a reason and responsible reviewer. Correct the source or mapping, rehearse the correction and confirm that a retry does not duplicate accepted records. Critical unresolved records should block the agreed acceptance gate.

Who should approve the migration?

The technical owner confirms execution and recovery evidence. The business data owner or relevant department reviewer confirms the records and workflows. Name the person with final go-live authority before cutover starts.

Can migration happen in phases?

Yes, when phases have clear ownership, dependencies and an authoritative system for each workflow. Define how records shared between phases stay consistent and how changes are reconciled.

What should we share for an initial discussion?

Share the source and target systems, data groups, approximate volumes, history requirements, important reports and acceptable disruption. Use synthetic examples to explain fields. Do not submit customer exports, passwords, tokens or private documents in a public enquiry.

Can VASUYASHII help plan the migration?

VASUYASHII can review migration requirements as part of an agreed custom-software scope. Source access, target behaviour, cleanup ownership, acceptance criteria and cutover support must be confirmed before an estimate or delivery commitment.

Discuss your software and migration requirements