In this article (16 sections)
Short answer: migrating data to a new system works when you move less history than you think, clean the data in the old system before moving it, and refuse to go live until three checks pass: totals reconcile, your most important records are right, and record counts match. As a 2026 market reference, the migration usually runs 10% to 25% of the development budget, and it climbs fast when the old system can't export its data.
Data migration is the part of a software project that gets estimated in one line and paid for in weeks. It's also, by a wide margin, the part that decides whether people actually use the new system.
The reason is simple: trust in a system is won or lost in the first week. If on day one someone looks up a customer and finds three of them, or checks a balance that doesn't match what they know, the system has lost. From then on nobody will base a decision on data that already let them down.
The decision that costs the most and gets the least thought
How much history to bring over.
The instinctive answer is "all of it". It's almost never the right one.
Bringing eight years of transactions multiplies the cost of the migration, carries over eight years of mistakes and leaves the new system full of old clutter. And afterwards almost nobody looks at it.
What works in the vast majority of cases:
Data | What to migrate | Why |
|---|---|---|
Master records (customers, vendors, products) | All of them | They're used every day |
Current balances (accounts receivable, inventory) | As of the cutover date | The new system has to start from the real number |
Transactions | The last year, maybe two | Enough to operate and compare against last year |
Older history | Nothing: keep it read-only in the old system | Available if someone asks, at a fraction of the cost |
That last row resolves 90% of the anxiety and costs a fraction. Nobody needs the 2019 delivery note inside the new system. They need to be able to find it if anyone ever asks.
Keep the retention rules in mind when you decide how long that read-only copy has to stay reachable. In the US, the IRS guidance is that most business records should be kept for at least three years, and longer in specific situations such as employment taxes or bad debt deductions. Check your own case with your accountant.
Your data is dirtier than you think
Always. No exceptions. Here's what you're going to find:
- The same customer entered three times, with the name spelled differently and the balance split across the three records.
- Dates stored as text, in three formats.
- Fields used for something else: the notes field holding the tax ID, because someone needed it once and there was nowhere to put it.
- Duplicate codes that the old system allowed.
- Orphan records: orders from customers who no longer exist.
- Balances that don't reconcile with the accounting.
None of this is anyone's fault. It's what happens to any database with years of use and several people entering data.
The order that works
1. Assess the data before you get a quote
Before estimating the migration, someone has to look at the data. How many records, how many duplicates, how many empty fields that should be filled in.
A migration quoted without opening the database is a made-up number. Ask for the data to be reviewed first, even if it costs a few hours.
2. Clean in the old system, not the new one
Counterintuitive and very important. The temptation is to migrate everything and fix it later.
Don't: merge the duplicates and fix the bad data in the system where people know it, with the people who know it. In the new system, nobody has the context to tell which of the three records for the same customer is the right one.
3. Run several test migrations
The first migration isn't the final one. It runs, it gets reviewed, the process gets fixed, it runs again. Three or four rounds is normal.
What matters is that business people review it, not just technical people. A developer sees that the records are there; the head of sales sees that your biggest customer is missing.
4. Cut over with clear rules
Before cutover day you need to have decided:
- The exact date and time of the cutover.
- What happens to work in progress: open orders, deliveries not yet invoiced.
- Who validates that the balances reconcile, and against what.
- How you roll back if something goes wrong.
That last point isn't pessimism. It's what lets you cut over calmly. Planning guides for large migrations, such as Microsoft's Cloud Adoption Framework, make the same point at enterprise scale: decide the rollback path before you need it.
The three checks you don't skip
After migrating, before operating:
- The totals reconcile. The sum of customer balances and the inventory valuation, against the old system. If it doesn't match, you don't start.
- The ten most important cases are right. Your top ten customers, your twenty fastest-moving products. Checked by hand, one by one, by someone who knows them.
- The counts match. How many customers there were, how many there are. Any difference needs an explanation.
It sounds obvious and it gets skipped constantly under schedule pressure.
What it costs
As a 2026 market reference, the migration usually lands between 10% and 25% of the development cost, and it rises sharply when the old system has no way to export.
The factor that drives the cost isn't volume: it's how the data gets out of the old system.
How the old system gives you the data | Effect on the migration cost |
|---|---|
Clean export (CSV, Excel, an API) | Contained, predictable work |
Direct reads from its database | Higher: someone has to understand the schema first |
Only through the screens, record by record | A different category of cost: plan for it explicitly |
Find that out before you ask for a quote. It's the question that moves the number the most.
At Atomix, data migration is part of the project scope, not a separate surprise: a project runs USD 5,000 to 10,000, and only exceptional, much larger projects go above that. You see a free working demo with your case in 24 to 48 hours before any quote, and most projects reach production in under a month. The details are on our custom software development page.
One piece of advice worth more than the rest
Keep a full copy of the old system, exactly as it was on cutover day, and don't delete it.
Not the vendor's backup: a copy of your own, somewhere you control. It's cheap, and it's the only thing that saves you from the question that shows up nine months later: "how was this before?".
If you're still deciding whether to leave spreadsheets at all, start with when to move from Excel to a real system. If the old system is a legacy application you can't simply switch off, read legacy system modernization strategies.
Frequently asked questions
How much historical data should I migrate to the new system?
All master records (customers, vendors, products), current balances as of the cutover date, and one or two years of transactions. Older history stays read-only in the old system, where it can still be looked up if someone needs it.
Should I clean the data before or after migrating?
Before, in the old system, with the people who know the data. In the new system nobody has the context to decide which of three duplicate customer records is the right one.
How many test migrations are normal?
Three or four rounds. Each one is reviewed by business users, not only developers, and the process is fixed between rounds.
How much does a data migration cost?
As a 2026 market reference, between 10% and 25% of the development cost. The biggest factor is how the data comes out of the old system: a clean export is contained work, while extracting data only through screens costs far more.
What should I do with the old system after cutover?
Keep a full copy of it, as it was on cutover day, somewhere you control, and keep it accessible for as long as your record-retention obligations require.
If you want to see how your migration would look on a working demo of the new system, book a call.