Data Migration Between Systems: A Safe, Step-by-Step Plan

By Grocito14 October 2026

Data migration is moving records from one system to another, such as from spreadsheets or an old application into a new platform. A safe migration scopes what to move, cleans the data, maps every field, runs trial migrations with reconciliation checks, agrees a cutover and rollback plan, and ends with business sign-off. Skipping trial runs and a rollback plan causes most failures.

Key takeaways

Decide what to migrate, archive or drop before you map anything. Moving less is often the safest improvement.
Clean and standardise data before moving it, not after.
Run at least one full trial migration and reconcile it with counts, totals and spot checks.
Choose a cutover strategy deliberately: big bang, phased or parallel run, each with different risks.
Write a rollback plan before cutover day, and have the business owners sign off on the result.

What is data migration, and why does it go wrong?

Data migration sounds simple: copy data from system A to system B. In practice the two systems store information differently, and the old one often holds years of inconsistencies that people worked around.

Migrations commonly fail because of:

Dirty data: duplicates, missing values, free-text where the new system expects a list.
Undocumented fields: columns people use for an unofficial purpose that nobody wrote down.
No rollback plan: when something goes wrong at cutover, there is no safe way back.
Late testing: the first real test happens on the day of the switch.

Step 1: What should you scope and what should you leave behind?

List every data set in the old system and decide for each one:

Migrate: needed for daily operations in the new system.
Archive: needed for reference or legal retention, but not for daily work. Keep it in a read-only archive or export.
Drop: out of date, duplicated or never used.

Ask how far back history really needs to go; moving years of closed records adds time, cost and risk. Retention duties vary by country and sector, so check what applies to your data with a qualified professional before deleting anything.

Step 2: How do you map and transform the data?

A data map is a table showing, for each field in the old system, where it goes in the new one and what must change on the way.

For each field, record:

Source system, table and field.
Target system and field.
Format changes, such as date formats, phone numbers or currency fields.
Value translations, such as old status codes mapped to new status names.
Rules for missing or invalid values.
Who owns the decision if the mapping is unclear.

Watch fields that do not map neatly, such as one old field splitting into two new ones. Errors hide there.

Identifiers and relationships

Records refer to each other: orders to customers, tickets to contacts. Decide how old identifiers will be preserved or translated, and keep a cross-reference table of old and new IDs. Other systems, such as accounting tools or reports, may also refer to these identifiers, so check every connected integration. Our guide to API integration for business explains how those links usually work.

Step 3: Why clean the data before moving it?

Moving dirty data into a clean new system relocates the problem. Cleaning typically means merging duplicates, standardising formats, flagging missing required values and correcting obvious errors. Ask the people who use the data daily to review samples; they spot problems that scripts cannot. For a deeper look at this stage, read our guide to data quality basics.

Keep a log of what was changed and why.

Step 4: How do trial runs and reconciliation work?

A trial migration is a full rehearsal into a test environment using a copy of real data. Do at least one before cutover, ideally several.

After each trial, reconcile the results:

Counts: the number of records in each table in the old system versus the new one, with every difference explained.
Totals: sums of key financial or quantity fields, such as outstanding invoices or stock on hand.
Spot checks: pick a sample of records, including unusual ones, and compare them field by field.
Relationship checks: confirm that each order still belongs to the right customer.
Business checks: ask users to run their normal reports in the test system and say what looks wrong.

Each trial should produce a list of defects, fixes and a re-run. Aim for a boring, repeatable process by cutover.

Step 5: Which cutover strategy should you choose?

Big bang

Everyone switches on a single date. It is simple to understand and avoids running two systems, but all the risk lands on one moment. It needs a clear downtime window and a rehearsed rollback.

Phased

You move in stages, by department, region, customer group or module. Risk is spread and lessons from early phases improve later ones. The cost is a longer project and a period where data may live in two places, which needs careful rules about which system is the source of truth.

Parallel run

Both systems run side by side for a period and results are compared. It builds confidence, but it doubles the workload for staff and creates a risk of the two drifting apart. It tends to be reserved for critical processes such as finance.

Choose based on how much downtime the business can tolerate and how much extra effort your team can absorb.

Step 6: How do you plan downtime and rollback?

Downtime

Decide when changes to the old system will be frozen, how long the final migration is expected to take based on the trials, and who must be available. Choose a quiet time, tell customers and staff in advance, and prepare a short note on what people should do meanwhile.

Rollback

A rollback plan answers one question: if the new system fails or the data is wrong, how do we get back to a working state? Prepare it before cutover:

Take a verified backup of the old system immediately before the final migration.
Define the decision point and who has the authority to call a rollback.
Define the criteria: for example, failed reconciliation on key totals or a broken critical process.
Test the rollback in a rehearsal, not just on paper.
Decide what happens to data already entered into the new system.

For larger moves to hosted infrastructure, the cloud migration checklist covers related planning.

Attachments, history and audit trails

Files, images, notes and activity history are often overlooked. Decide whether they will move, where they will live and how they will be linked to records. Decide whether history such as comments and status changes is migrated in full or summarised. If you may need the old audit trail later, keep a read-only copy.

Security and access during migration

Migration copies large amounts of sensitive data, often into temporary files and test environments. Treat these with the same care as production.

Limit who can see exports and test copies, and use named accounts.
Encrypt files in transit and at rest where possible.
Do not leave exports on laptops or shared drives; delete test copies when finished.
Mask personal data in test environments when you can.
Review user permissions in the new system before opening it.

Personal data rules vary by country and sector, so involve whoever handles data protection in your organisation.

Validation, sign-off and monitoring after go-live

Business owner sign-off

The people who own the data, such as the heads of finance, sales or operations, should formally confirm it is correct. Give them the reconciliation results and a window to test. Sign-off is a business decision, not a technical one.

After go-live

Keep the old system read-only for a defined period. Watch for support requests, report discrepancies and integration errors, and fix them quickly. When the period ends, archive the old system properly.

A worked example

Imagine a service company moving its customer records from several spreadsheets and an old CRM into a new platform. During scoping, it decides to migrate active customers and open jobs, archive older closed jobs as read-only exports and drop duplicate test records. Trial one shows that phone numbers lost leading zeros and that two statuses in the old system had no equivalent in the new one. They fix the mapping and re-run. The second trial reconciles on counts and on totals of open invoices. The sales manager signs off after testing her own pipeline reports. Cutover happens over a weekend with a verified backup and a written rollback decision point on Sunday afternoon. In the end the rollback is not needed.

FAQ

What are the steps in a data migration?

Scope the data, clean it, map fields between systems, run trial migrations with reconciliation checks, plan cutover and rollback, migrate, then validate and sign off with the business owners. Monitoring the new system after go-live completes the process.

How long does a data migration take?

It depends on the volume, the quality of the data and the complexity of the mapping. Dirty data and unclear ownership usually cause delays, so allow time for cleaning and several trial runs rather than planning only the final copy.

What is the safest cutover strategy?

There is no single safest option. A phased approach spreads risk, a parallel run builds confidence for critical processes and a big bang is simplest but concentrates risk on one moment. Whichever you choose, a tested rollback plan matters most.

How do I check that migrated data is correct?

Compare record counts and key totals between the old and new systems, spot-check a sample of records field by field, test relationships between records and ask users to run their normal reports. Have the business owners confirm the results before you retire the old system.

Next steps

Start by listing your data sets and marking each as migrate, archive or drop, then draft a field mapping for the most important one. If you need help planning or running a migration, or building reports on the cleaned data through our data analytics services, contact us.