ERP Data Migration: A Complete Guide to Scope, Cost, and Cutover
ERP data migration is the process of moving master data, open transactions, and historical records from legacy systems into a new ERP and proving they behave correctly there. Most programs treat it as a field-mapping exercise, which is why they run over. Roughly ninety percent of data maps cleanly on the first pass, and the remaining ten percent of exceptions is where implementations lose their schedule.
Key takeaway: The mapping is not the hard part. The hard part is the small share of records that carry undocumented business rules, and those only surface when you load real volumes into a real target and run real transactions against them. Programs that find those exceptions in week two ship on time. Programs that find them in the dress rehearsal do not.
What ERP data migration actually involves
ERP data migration covers four distinct workstreams that programs routinely collapse into one line item. Master data is the item, customer, vendor, and chart-of-accounts records the new system needs to function. Open transactions are the in-flight purchase orders, sales orders, work orders, and open receivables that must land mid-lifecycle without breaking. Balances are the general ledger and inventory positions that have to tie out to the penny. History is everything you keep for reporting or compliance rather than for daily operation.
ERP data migration is the transfer of business data from one or more legacy systems into a new enterprise resource planning platform, including the mapping, transformation, cleansing, loading, and reconciliation required for that data to function correctly under the target system's rules.
Scope each of the four separately in your project plan, with separate owners and separate acceptance criteria. The most common estimating error in an ERP implementation is quoting the data workstream as a single line, because master data is a mapping problem, open transactions are a business-logic problem, balances are an accounting problem, and history is a storage-and-retention problem. They fail for different reasons and they need different tests.
What to migrate and what to archive
Migrate what the business needs to transact, and archive what it only needs to look at. Every record you carry across is a record you have to map, transform, validate, reconcile, and defend at cutover, and the marginal cost of the tenth year of closed sales orders is not zero.
Data archiving in a migration context means retaining legacy records in a read-only store or the decommissioned source system, accessible for reporting, audit, or compliance, rather than loading them into the new production environment.
Run the retention conversation before the mapping conversation, not after. Get finance, tax, legal, and operations in one room and force a decision on each object: transact, report-only, or drop. In practice most manufacturers and distributors need two to three years of transactional history live and everything older in an archive, but the number is a business decision with legal constraints, not a technical default. Ask specifically whether any open litigation, tax audit, or regulated retention period pins a longer window, because discovering that after cutover is expensive.
Who owns the ERP data workstream
The business owns the meaning of the data and IT owns the movement of it, and programs stall when that line is blurred. A systems integrator can build the pipeline, but no consultant can tell you what your operations team actually means by a status code they have been overloading for eleven years.
The data workstream owner in an ERP program is the person accountable for data readiness at each gate: source extraction, mapping sign-off, cleansing, load validation, and reconciliation approval at cutover.
Name a single accountable owner per data object and put their name in the plan. For the item master, that is usually a supply chain or engineering lead. For customers, sales operations. For the chart of accounts and balances, the controller. Interview the people who key the records daily, not only the managers who own the process on paper. The gap between how a field is documented and how it is used is where your exceptions live, and frontline users are the only reliable source for it.
This is the same discipline behind the most common ERP migration failure reasons: the exceptions are known to somebody in the building, and the program's job is to extract that knowledge before load rather than after.
How long an ERP data migration takes
An ERP data migration typically runs six to twelve months on a mid-market implementation and longer on multi-entity or multi-country programs, and the variance is driven almost entirely by how many load-and-fix cycles the team burns. The extraction and mapping work is largely predictable. The iteration is not.
A load-and-fix cycle, sometimes called a mock load or reload round, is a full pass in which mapped data is loaded into a staging or test environment, errors are identified, rules are corrected, and the data is reloaded. Implementations commonly run four to eight of these before cutover.
Panorama Consulting Group's 2026 ERP Report puts the median enterprise software project at nine months across the 170 organizations it surveyed, and in our experience the programs that overrun that median are rarely the ones that mapped a field incorrectly. They are the ones that kept finding new exception classes on the fifth reload.
Count your planned reload rounds explicitly in the schedule and treat each one as a fixed-cost event with a known duration. Teams that leave the number implicit discover it empirically, one painful round at a time. If you want to compress the timeline, the only lever that matters is finding exceptions earlier in the sequence, because a rule error caught in round one costs a day and the same error caught in round six costs a rebuild of everything downstream of it.
For a fuller breakdown of where the months go, see how long an ERP data migration actually takes.
What ERP data migration costs
Data migration on a mid-market to enterprise ERP program generally runs from about $250,000 to well over $1.5 million, and it is the line most often underquoted in an implementation statement of work. The reason is structural: integrators price the mapping because mapping is estimable, and the exception handling that consumes the back half of the project gets absorbed as change orders.
Data migration cost in an ERP program covers extraction, profiling, mapping design, transformation development, cleansing effort, repeated test loads, reconciliation, and cutover support. Licensing for tooling is usually a small fraction of the total; labor for iteration is the bulk of it.
For a full breakdown of data migration cost by program size, including the hour-by-hour build-up behind a quote, see what data migration costs and how the number is built.
Ask any vendor to price the reload cycles separately from the mapping, and ask how many are assumed in the number. If the SOW does not state an assumed cycle count, the quote is not comparable to one that does, and the difference between four assumed rounds and eight is most of the delta between a clean project and a change-order fight. Ask the same question about cleansing: whose staff fixes the bad records, and at whose rate.
The reload loop and why programs get stuck in it
Programs run repeated mock loads because each load reveals a new tranche of records the target system rejects, and each rejection sends the team back to rewrite rules. The loop is not a sign of a bad team. It is the standard mechanism by which undocumented business rules get discovered, and it is slow because discovery is serialized behind loading.
The reload loop is the cycle of load, error triage, rule correction, and reload that repeats until a dataset passes the target system's validation. Its length is determined by how many distinct exception classes exist in the data and how many are discovered per pass.
Break the serialization by validating against the target's rules before you load rather than learning them from load failures. That means encoding type and length constraints, required fields, primary key uniqueness, foreign key resolution, enumerated value membership, and row counts as checks you run against staged data. Every exception class you catch in that gate is a reload round you do not run.
Decision framework: how to sequence an ERP data migration
The right sequence depends on how much of your complexity sits in master data versus in-flight transactions. Use this to choose a path.
If your complexity is concentrated in master data (large item catalogs, many customers, messy vendor records), front-load profiling and dedup, and get a full-volume master data load into staging before you write a single transaction rule. The item master is the dependency root for almost everything else.
If your complexity is concentrated in open transactions (long order lifecycles, partial receipts, split shipments, project accounting), freeze scope on master data early and spend your iteration budget on transaction state. These records fail on business logic, not on formatting, and they need workflow simulation rather than field validation.
If you are consolidating multiple legacy instances into one ERP (post-merger, multi-entity, or multi-plant), resolve the survivorship rules before mapping anything. Which source wins on conflict, and on what tiebreak, is a business decision that will otherwise get made implicitly by whichever load runs last. The same logic applies when consolidating multiple CRM instances after an acquisition.
If you are on a hard vendor deadline (an end-of-support date, a lease expiry, a TSA exit), cut history scope first and open transactions last. History is the only one of the four workstreams you can defer without breaking day-one operations.
Validating ERP data before cutover, not after
Validation before load is what separates a scheduled go-live from a rescue. A sample test tells you your rules work on the records you already understand, which is the subset least likely to break. The exceptions that stall a program are, by definition, the ones nobody thought to sample.
Pre-load validation is the practice of running staged data against the target system's constraints (data types, field lengths, required fields, key uniqueness, referential integrity, permitted values, and row counts) before attempting a load, so that failures are found and fixed in staging rather than discovered by the target system.
Run the full dataset through a gate that mirrors the target's rules exactly, fix the failures in staging, and run it again. Then go further and simulate the workflows the business will actually execute on day one: receive against an open PO, ship a partial order, run a period close. Structural validity is necessary but not sufficient, because a record can be perfectly well-formed and still make a transaction impossible.
This is the part of the problem Settle was built for. Our engine proposes mappings with a confidence score, runs them through deterministic validation against the target's rules, loads to staging, and simulates real workflows, and it does that on the full dataset in the first week rather than in the fourth mock load.
Every mapping proposed with a confidence score, and flagged where the agent cannot decide.
Automation handles the structural and rule-based work well. It does not settle a disagreement between two plant managers about which costing method survives consolidation. Those decisions still need an owner and a meeting.
What this looks like when it goes wrong
On one manufacturing ERP implementation, the item master sailed through every sample test we ran. Then we loaded the full file and found that the plant had been encoding a secondary unit-of-measure conversion inside a free-text description field for products that shipped in both cases and pallets. It was not in the documentation. It was not in any of the records we had sampled, because those were all the high-volume items that only shipped one way. We found it three weeks before cutover, and correcting the conversions by hand across the affected catalog cost the program most of a month of float it did not have.
Nothing about that problem was technically difficult. It was expensive because of when we found it.
| Approach | Timeline risk | Exception discovery |
|---|---|---|
| Sample testing | High | Late in project |
| Full manual testing | Medium | Mid project |
| Automated pre-load validation | Low | First week |
Proving the data works before cutover rather than after is the discipline at the center of every successful ERP implementation. Everything else in the data workstream is execution.
Frequently Asked Questions
How long does an ERP data migration take?
Six to twelve months is typical for a mid-market implementation, with multi-entity and multi-country programs running longer. The single largest driver of variance is the number of load-and-fix cycles required, which commonly falls between four and eight. Programs that validate against target rules before loading run fewer cycles. Programs that discover rules from load failures run more.
How much does ERP data migration cost?
Most mid-market and enterprise programs fall between roughly $250,000 and $1.5 million or more, depending on data volume, source system count, and how much cleansing the legacy data needs. Labor for repeated test loads and exception handling is the dominant cost, not tooling licenses. The line is frequently underquoted in implementation SOWs because integrators price the mapping and absorb the iteration as change orders. Ask any vendor how many reload cycles their number assumes.
How much historical data should we migrate?
Migrate what the business needs to transact on and archive the rest. Two to three years of transactional history in the live system is a common landing point, with older records kept in an archive or the decommissioned source. The right answer depends on your reporting needs and on legal or tax retention requirements, so decide it with finance and legal rather than defaulting to everything.
Who is responsible for data migration in an ERP project?
Accountability splits: the business owns what the data means and IT or the integrator owns how it moves. Each major data object needs a single named business owner who can sign off on definitions and survivorship rules. Programs that leave ownership diffuse end up with mapping decisions made by whoever is available, which is usually the person least equipped to make them.
Can we do the ERP data migration ourselves?
Many organizations can, particularly with a single source system and clean master data. The constraint is rarely skill and usually capacity, because the people who know what the data means are the same people running the business during the implementation. Assess it honestly against your reload cycle count: if you cannot staff four to eight full passes of load, triage, and fix, you will need help.
What is the difference between an ETL tool and a data migration platform?
An ETL tool moves and transforms data on a schedule and assumes you already know the rules. A migration platform is built for the one-time problem of discovering rules you do not yet know, which means profiling, exception surfacing, iterative staging, reconciliation, and audit trail. You can build a migration with ETL tooling, but you will build the discovery and validation layer yourself.
Bringing it together
ERP data migration fails on the last ten percent of records, not the first ninety. The work that determines whether you go live on schedule is finding those exceptions early enough that fixing them is cheap, which means validating full volumes against target rules in the first weeks rather than learning the rules from mock load failures in the last ones.
If you are scoping the data workstream on an upcoming ERP implementation, Settle can validate your legacy data against the target's rules on day one and deliver a verified cutover as a priced engagement. Book a scoping call.