ERP data migration: how to prepare your data for go-live
In almost every ERP project, ERP data migration sits on a single line in the project plan: “Migrate data to the new system.” In practice that line takes more hours than all the technical configuration combined. Project leads who know this upfront plan differently. Those who do not, find out three months before go-live.
This article covers what an ERP data migration involves, which mistakes cause the most delay, and how sector-specific data challenges shape your approach. It speaks to IT managers and project leads responsible for the technical side of an ERP programme.
Why data migration is more than moving records
The name suggests a transport problem: data sits in system A and must arrive in system B. Technically that is correct. The real question is the quality of what you move.
Every ERP system stores data in its own way. Customer records have a different structure in the next platform. Article codes that were unique in your current environment collide in the new system with existing records. Currency symbols, date notations, decimal separators: in fifteen years of seemingly stable data, inconsistencies surface that no one remembered.
ERP data migration makes visible how coherent your processes actually are. What lived in operations as scattered exceptions appears during migration as a pattern. Organisations running the same ERP for twenty years have built data that mirrors their growth: acquisitions, restructurings, departments that were merged or dissolved. Those changes left traces, and you need to find them before you migrate.
ERP Company supports organisations as an independent consultancy. With 265+ specialists active in manufacturing, wholesale and services, we see that data problems are almost always visible earlier than go-live but only get taken seriously when the date approaches.
Sector-specific data challenges: what to expect
Data migration challenges are not the same everywhere. Your sector largely determines which data quality problems you face and how much time the preparation takes.
Manufacturing
In manufacturing, data quality issues sit mostly in article master data: bills of material, routings and production orders. Article codes have grown inconsistently over the years, kept in Excel alongside the ERP, or split across sites with their own numbering. Historical inventory data needs attention too: manufacturers often want years of stock movements available for analysis, and the question is which records are reliable enough to migrate.
In our experience at a manufacturer with multiple production sites, the inventory revealed that around one in five active article codes was effectively dormant. Cleaning before the migration saved more than a month of test work. Inactive bills of material stay on the books for years and add complexity without business value. For a structured approach, our data management and migration services starts from this baseline.
Wholesale and distribution
Wholesale companies typically have a large article catalogue and complex relationships with suppliers and customers. The challenge sits in the data quality of customer and supplier records: duplicates, outdated addresses, customers inactive for years. A recurring problem is the customer pricing structure: discount agreements and price lists are partly in the ERP and partly outside the system, in Excel or in verbal sales arrangements.
In our experience at a distributor, the first cleansing round revealed that between twelve and fifteen per cent of customer records were duplicate or inactive, often through acquired customer groups that had never been tidied up. Only after the merge could the pricing structure in the new system become manageable. Logistics data such as locations, routes and batches deserves extra attention when the new ERP uses a different location structure.
Services and maintenance
For services and maintenance organisations the challenge sits less in the article catalogue and more in project history and contract data. Long-running service contracts, SLA agreements per customer, billing arrangements: data rarely uniform in existing systems. Decide early which historical project data moves forward; projects closed five years ago are no longer operationally relevant.
For maintenance organisations, machine cards and service history are business-critical and often the most polluted data in the system. In our experience at a maintenance organisation, around one in three machine cards had incomplete service history because field technicians had kept paper notes for years. Mapping that gap before the migration made the difference between a working service operation on day one and weeks of repair work.
Master data or transactional data: which goes first?
Master data is the structural backbone: customers, suppliers, articles, general ledger accounts. It does not change with each transaction. An error in a customer record carries through into every invoice afterwards. If the foundation is wrong, nothing downstream is right.
Transactional data is the historical events in your ERP: orders, invoices, stock movements, payments. On day one after go-live these are less critical for operations, but valuable for analysis and customer queries about old orders.
Master data you migrate early, so it is available during the test phase. Transactional data you migrate just before go-live, as recent as possible. Master data you validate at every test migration; transactional data once on volume and sampling. A common pattern: master data runs late, the test phase slips, and the go-live slips with it. The rule: master data first, transactional data later, validation continuous.
The four phases of a successful ERP data migration
An ERP data migration that finishes on time and with clean data has always followed a structured approach: four phases running in sequence.
Phase 1: inventory
Map which data sits in your current system, which sources exist, and which data is relevant for the new system. Ask per source: is this data current? Has it grown historically without a clear owner? Which department holds responsibility for the quality? In this phase you formally assign data ownership, so the cleansing work in phase 2 does not get stuck on departmental debates. The data management and migration approach at ERP Company always begins here. The output is a documented overview of all data sources, the record counts per entity, and an initial estimate of the data quality issues.
Phase 2: measure and improve data quality
Run a data quality analysis: how many records are empty, duplicate or inconsistent? Based on the analysis, decide which data is cleansed before migration and which does not move forward. Data cleansing is time-consuming work that should not be underestimated. Read how data cleansing in ERP migrations works in practice. Organisations that allocate too little time end up migrating their problems forward.
Phase 3: transformation and loading
The cleansed data is converted to the format of the new ERP and loaded into the test environment. Mapping questions appear almost every time: how does the old data model relate to the new one? Which fields are mandatory in the new system but optional in the current one? Run test migrations multiple times; each round produces findings that you resolve before the next. Plan at least two or three test migrations, and a closing run just before go-live.
Phase 4: validation after go-live
After go-live the validation phase begins. Run sampling checks on customer records, supplier data and open positions. Verify that transaction history has landed correctly, and set up a protocol for business reports about data issues in the first weeks. Data problems discovered only after go-live are more expensive to fix. Plan a second validation round after four weeks, when the first month-end close brings less visible errors to the surface.
How long does each phase take?
The lead time for data cleansing is, in our experience, two to three times the time teams budget at project start. The technical migration is usually the smaller part of the work; preparation and validation are the bulk. The split below is indicative; ratios shift with organisation size and data quality.
| Phase | Indicative share of effort |
|---|---|
| 1. Inventory | ~10% |
| 2. Data quality analysis and cleansing | ~40-50% |
| 3. Transformation and test migrations | ~25-30% |
| 4. Validation after go-live | ~10-15% |
Halving the cleansing budget to make “room” for configuration only relocates the work to just before go-live, at the worst moment.
Who is responsible for which data?
Unclear data ownership is a recurring cause of delay. Project teams that discover in phase 2 that no one owns the article master data lose weeks to alignment. A compact RACI matrix in phase 1 prevents that.
| Data entity | Responsible (R) | Accountable (A) | Consulted (C) | Informed (I) |
|---|---|---|---|---|
| Customer records | Sales ops | CFO | IT, Marketing | Operations |
| Article master data | Product manager | COO | Procurement, Production | Sales, Finance |
| Supplier records | Procurement | CFO | Finance, Quality | Operations |
| General ledger accounts | Finance controller | CFO | IT, Audit | Management |
| Inventory and transaction history | Operations | COO | IT, Finance | Sales |
This table is a starting point, not a prescription. Role distribution varies per organisation; the discipline to sign off the matrix before the inventory is what delivers the time saving.
Five mistakes that delay ERP data migrations
Most delays trace back to a limited set of mistakes. Project teams that recognise them in time can prevent them.
Failing to assign data ownership. Without formal assignment, data quality work becomes a departmental debate rather than a structured task.
Starting data cleansing too late. Teams that start in the final two months before go-live have too little time to process findings. On a twelve-month programme the analysis ideally starts in the first three months.
Running too few test migrations. One test migration gives a first picture but does not solve the problems. Plan multiple rounds and reserve time to process the results.
Not involving the business in validation. IT can check whether data has been loaded technically correctly; whether the content is right, the business knows. Involve department heads and key users.
Taking too much historical data forward. Outdated records, inactive customers and discontinued articles add complexity and startup time without payoff. Decide upfront which historical data is operationally relevant.
How long does an ERP data migration take on a twelve-month programme?
On a twelve-month implementation, data quality analysis starts in the first three months, in parallel with configuration. On shorter or longer programmes, the blocks shift proportionally.
| Period | Main data migration activity |
|---|---|
| Month 1-2 | Inventory, data ownership formally assigned |
| Month 3-6 | Data quality analysis and cleansing, in parallel with configuration |
| Month 7-9 | First test migrations, mapping findings processed |
| Month 10-11 | Second and third test migration, fine-tuning |
| Month 12 | Final transactional migration and post-go-live validation |
In-house or outsourced: what fits your organisation?
Choose on real capacity and knowledge, not on principle. In-house works well when you have a team that knows the current system inside out, has enough capacity alongside ongoing project work, and has previous experience with data migrations. External support is useful when the migration requires specific knowledge of the new platform, when time pressure is high, or when the data quality issues turn out larger than first estimated.
ERP Company offers independent support on data management and ERP migration, from inventory through to post-go-live validation. As a platform-independent partner, we work with most common ERP platforms without a stake in any specific tooling.
The link with ERP implementation and change management
Data migration is not a separate track alongside the implementation; it is a critical path within the programme. The availability of clean data at the right moment determines whether your test phase can start, whether training can run with realistic data, and whether your go-live date is achievable.
It is also a human question. Employees who work with incorrect test data develop a distorted picture of the new system, with consequences for adoption. Read how ERP change management connects to the technical migration. For organisations also considering a cloud migration, critical success factors for an ERP cloud migration covers the additional steps.
Frequently asked questions about ERP data migration
How long does ERP data migration take?
An ERP data migration typically consumes between 30 and 50 per cent of total implementation time, depending on data volume and the quality of the starting position.
In our experience the data quality analysis and cleansing take more time than the technical migration itself. On a twelve-month implementation the analysis starts in the first three months, in parallel with configuration. Teams that start later risk a slipped test phase and a delayed go-live.
Should all historical data move to the new ERP?
No. Only historical data that is operationally relevant or analytically valuable moves forward; the rest you archive or leave behind.
Master data always moves. For transactional data, make a deliberate choice per category: open orders and outstanding positions are essential, while orders from five years ago can often stay in an archive. More data means more migration complexity without proportional benefit.
What is the biggest risk in an ERP data migration?
The biggest risk is that data problems only become visible after go-live, when processes have already run on the wrong data.
Correction in a live system is, in our experience, a multiple of the cost of prevention. Multiple test migrations with business validation, combined with clear data ownership, are the most effective way to contain that risk.
How do I involve the business in data quality improvement?
Assign a business owner per data entity, and tie that role to the validation of every test migration.
IT guards the technical process; the business decides whether the data is correct in substance. Use a RACI matrix to set out the roles before phase 2 begins. Owners assigned only in phase 3 run behind from the start.
ERP data migration is not work you can catch up on afterwards. The quality of your data on go-live day shapes how your start unfolds: smoothly, or with repair work. Start early, assign ownership clearly, and treat data cleansing as a craft. Organisations that do, start on a foundation that holds. Want to know what a sound data migration approach looks like for your programme? Get in touch with ERP Company for an exploratory conversation.
Further reading: Want the complete approach? See our complete implementation playbook.