In most ERP migrations, only open records and a slice of history move to the new system. Everything else stays behind in the old one, and it disappears when that system is turned off unless you plan for it. Your options are to migrate everything, migrate open records plus summaries, use a vendor or third-party archive, keep a read-only license on the old system, or build a searchable archive of your own. The right choice depends on how often people need old history, what customers and auditors require, and what it costs to keep the old system alive.
Changing ERPs is one of the biggest projects a small or mid-sized business takes on. Most of the planning goes into the new system: configuration, workflows, go-live. The old data gets a line on the project plan that says "historical data: TBD," and that line is where a lot of trouble starts.
What gets lost in an ERP migration?
A migration is where good process quietly gets lost. It's rarely the big things. It's the things nobody wrote down.
- The workaround nobody documented. A custom field the shipping team uses to flag rush orders. A note convention that tells purchasing which supplier to avoid. It worked for years, and it isn't on anyone's requirements list.
- The report only one person knows how to run. The month-end margin report, the customer quality history, the scrap analysis someone built a decade ago. If it doesn't exist in the new system on day one, people notice fast.
- The history nobody migrated because it didn't fit. The new ERP organizes data differently. Old transactions, routings, lot records or pricing history don't map cleanly, so the project leaves them behind. Then a customer calls about a part shipped four years ago.
None of this is a failure of the new system. It's the gap between two systems, and someone has to own it.
What are your options for old ERP data?
| Option | Cost drivers | Best for | Risks |
|---|---|---|---|
| Migrate everything | Data mapping and conversion for every record type; cleanup of years of history | Short histories, or systems with very similar data models | Slow and expensive; clutters the new system with data that doesn't fit its structure |
| Migrate open records plus summaries | Moving active data and building summary balances for reporting | Most businesses, as the core of the plan | Detailed history is no longer in the new system; you still need a plan for it |
| Vendor or third-party archive | Subscription or license, plus extraction and setup | Businesses that want a packaged product and have standard data | May not keep the relationships between records; ongoing fees; another vendor to manage |
| Keep a read-only license on the old system | Ongoing license and hosting fees for the old ERP | A bridge for the first months after go-live | Costs never end, skills fade, the old vendor may stop supporting it |
| Custom searchable archive | Building the extraction, data model and search screens once | Long histories, unusual data, or teams that need to look things up often | Needs to be built well and owned; you're responsible for hosting and access |
Most good plans combine two of these: migrate open records and summaries into the new system, and put the full history somewhere people can still search it.
What should you do with old ERP data after a migration?
After an ERP migration, keep the old data searchable, read-only and connected, and stop paying for the old system as soon as you safely can. Start by listing what people actually look up from history: past orders and pricing, lot and quality records, customer and supplier history, financial detail for audits. Then check what customers, regulators and your own policies require you to keep, and for how long. Migrate open records and summary balances into the new ERP, because that's what the new system is designed for. Put the rest into an archive that keeps the relationships between records, so a part number still leads to its orders and its quality history. A short read-only license on the old system can bridge the first months after go-live. Long term, an archive you own is usually cheaper and more reliable than paying for software nobody uses day to day.
What did this look like for a manufacturer?
From June through September of this year, we worked with a manufacturer changing ERPs. They needed two things: to keep years of history their people relied on, and to help their people work well in a system that was new to them.
We built an archive that mirrors the system they left, so people can look up old records in the way they're used to, with the relationships between those records intact. Alongside it, we built tools that make the new ERP easier to work in day to day.
The old system can go away. The history and the know-how don't have to.
What else makes an ERP migration go well?
Old data is one part of the plan. A few others matter just as much.
Clean the data before you move it. Duplicate customers, retired part numbers and inconsistent units of measure are cheaper to fix in the old system than the new one. Cleanup is also when you discover which records nobody needs.
Run in parallel long enough to trust the results. Process real work in both systems and reconcile the results, usually through at least one month-end close. It's tedious, and it's the best way to catch mapping errors while the old system is still there to compare against.
Train after go-live, not just before. People learn a new system when they use it for real. Plan for support at their desks in the first weeks, and for quick fixes to the small things that slow them down.
Plan post-go-live support. Reports that need adjusting, an integration that needs tuning, a workflow that doesn't fit. Budget for a period of steady fixes after launch. If the new ERP has to connect to your CRM or document systems, our post on system integration for small business covers the options.
And if you haven't chosen the new system yet, our guide to choosing business software without getting sold explains how to make the migration plan part of the selection.
Why are ERP migrations cheaper than they used to be?
The expensive parts of a migration have always been the detailed ones: mapping fields between two data models, writing and testing conversion scripts, reconciling results and building the archive. AI-assisted engineering has made that work much faster. The decisions still need people who understand the business, but acting on those decisions takes far fewer hours than it did a few years ago.
That's why Mosaic now takes on ERP and software migrations that used to require a large consultancy. We've worked in NetSuite and Plex, along with the CRMs, document systems and homegrown tools that sit around an ERP. Most of our work is hourly, pay-as-you-go. We don't pass through system or AI time in our bills: you'll only be charged for time that real people spent on the task. When a migration also needs new integrations or internal tools, that's part of our software and automation work.
If you're planning an ERP change in Cedar Rapids, Iowa City or anywhere else, and the line on your project plan still says "historical data: TBD," see how we handle ERP migration and data archives.