An ERP lives on data quality. Whoever imports stock levels, customer masters, and open orders unchecked digitizes inconsistencies. Migration is not a pure IT topic and not a side step on go-live weekend. It is a joint task for business departments and the project team: define scope, clean up, map, test, approve. Whoever only starts shortly before go-live risks that the new system merely makes old data problems visible faster.

Why unchecked migration endangers projects

Legacy systems often store decades of edge cases: duplicates, dead items, outdated addresses, inconsistent codes. In daily work, Excel and manual rework hide many of these errors. In the new ERP they become the rule. Planning works with wrong stock levels, sales with duplicate customers, finance with unclear account assignments. The result is distrust of the system, dual maintenance, and resistance after go-live.

Data migration therefore belongs among the classic implementation mistakes when it is supposed to “just run along somehow”. The link to scope, involvement, and planning is described in Common ERP implementation mistakes. Conversely: whoever runs migration as its own work package with clear acceptance criteria noticeably relieves go-live.

Which data must really be there at start

Not everything must sit in the new system on day one. A deliberate scope makes sense:

1. Go-live critical: entities without which the pilot process cannot run (for example items, customers, open orders of the core process).
2. Can follow later: history, archive data, rarely used master data that can be imported later or provided read-only.
3. Deliberately not migrate: dead records, duplicates, obsolete variants. Deleting or archiving before import saves more effort later than any after-the-fact cleanup.

This separation is a business decision, not a technical one. Departments know which records are still commercially relevant. IT knows which fields and codes can be transferred mechanically. Both belong together. Whoever sets “take everything over” as the default maximizes effort and error risk without clear benefit.

Which steps make migration plannable

A reliable migration flow follows recurring steps:

1. Define scope: which entities, which time ranges, which systems as source?
2. Clean up: resolve duplicates, outdated items, and dead customers before import. Document in writing who decides.
3. Document mapping: fields and codes between old and new system. Make edge cases and default values explicit.
4. Test migration: repeatedly, with real volumes, not only with demo excerpts.
5. Spot checks: after each test run, verify business-critical records. Departments confirm, IT documents deviations.
6. Rollback plan: what happens if a run fails? Which source remains leading until approval stands?

Migration is iterative. A single export on go-live day is not a plan, it is a risk. Between runs there is time to correct mapping and source data quality.

Who carries business ownership

Nuclos provides import and migration tooling. What remains decisive is business ownership: departments know edge cases that no generic mapping covers. IT can map fields and steer runs. Whether an item is still active, whether two customers are the same company, or whether a stock value is correct is decided by the business department. Without that role clarity, blame games follow after go-live: “The migration was wrong” versus “The business data was already wrong”.

What helps is named accountability per entity (for example item master maintenance, receivables) plus a joint acceptance protocol after the last test migration. That makes quality measurable before you switch to production.

How migration fits process rollout

Migration in parallel with a process-oriented implementation reduces load: core master data for the pilot process first, the rest step by step. That fits delivery models with clear scope. Nuclos Enterprise delivers productive ERP in 30 days on agreed scope. Extensive legacy data migration is often its own work package or phase 2, not a silent appendix in week four. Whoever limits data scope before contract start protects timeline and fixed price.

Context on the system core and typical entities: ERP core system. For entry paths and scope clarity before the large project: Which Nuclos entry path fits your situation?.

Next steps

• “Project mistakes and countermeasures: Common ERP implementation mistakes”
• Understand system core and entities: ERP core system
• Clarify goals and scope before migration: How do you define ERP goals and scope before choosing software?