Häufig gestellte Fragen
Which data must be transferred in an ERP data migration?
As a rule, the active master data must be transferred – such as articles, customers, suppliers and accounts – along with open transaction data such as open items, running orders and current stock levels, because the new system would otherwise not be operational. Completed historical documents, by contrast, are often not carried over into production but retained in the legacy system or in an archive, frequently going back several years. Narrowing the migration scope in this way significantly reduces effort and sources of error, because not every outdated or inactive record has to be transformed and checked. Which data is actually needed should be defined by the business departments for each data domain, not by IT alone.
How long must old ERP data and documents be retained after a migration?
In Germany, documents relevant for tax and commercial law are subject to retention obligations under the Fiscal Code (Abgabenordnung, AO) and the Commercial Code (Handelsgesetzbuch, HGB), which run for six, eight or ten years depending on the document type. With the Fourth Bureaucracy Relief Act (Viertes Bürokratieentlastungsgesetz), the retention period for accounting records was shortened from ten to eight years as of 1 January 2025, while ten years continue to apply to books, annual financial statements and inventories. If documents are digitised during the migration or transferred into the new system, they must be archived in an audit-proof, unalterable and machine-analysable manner in accordance with the GoBD. In practice, completed legacy documents therefore often remain available read-only in the legacy system or in a GoBD-compliant archive rather than being transferred into the new ERP for production use.
What is the difference between big-bang and phased data migration?
With the big-bang approach, the transfer takes place on a fixed cut-over date on which the company switches completely from the legacy system to the new one, often over a weekend with a short downtime window. The advantage is a clean break without prolonged parallel operation; the disadvantage is the higher risk, because if problems occur the entire company is affected and a rollback may become necessary. In a phased migration, data and functions are transferred in stages, so the legacy and new systems run in parallel for a time – this reduces the cut-over risk and allows a gradual fallback, but increases effort and complexity through duplicated data maintenance. Which variant fits depends on the industry, company size, downtime tolerance and the complexity of the customising.
How are the completeness and accuracy of the migrated data verified?
Verification usually combines a technical and a functional validation: on the technical side, record counts are reconciled between the source and target systems, totals are compared (such as balances or stock values) and mandatory fields are checked for completeness. On the functional side, key users spot-check individual records – for example a selection of customers, articles or open orders – against the legacy system for content. This final comparison, often referred to as reconciliation, ensures that no data has been lost or incorrectly assigned. Proven practice is to run several test migrations in a sandbox and only go into production after documented functional sign-off.
Why do so many ERP projects fail because of data migration?
Data migration is considered one of the most critical sub-steps of an ERP implementation and is a frequent reason for delayed go-live dates, because poor data quality often only becomes apparent once the migration is already under way. Widely circulated industry analyses – frequently attributed to Gartner or Bloor Research – have for years cited high failure and budget-overrun rates for data migration projects, with duplicates and outdated or inconsistent records regularly identified as the main cause. A typical mistake is treating the migration as a purely IT task instead of involving the business departments, who can judge which data is really needed. Early data cleansing, a binding target model and several test runs are therefore regarded as the most effective countermeasures.
When should data cleansing take place in the migration project?
Proven practice is to schedule data cleansing as early as possible and not push it to the end of the project, because faulty data would otherwise persist permanently in the new system. In practice, duplicates are consolidated, outdated records removed and inconsistent values standardised before the actual transfer – for example inconsistently assigned article numbers or suppliers recorded twice. Clean master data maintenance up front noticeably reduces the later migration effort and lowers the number of errors that surface in test runs. Clear responsibilities per data domain and a documented mapping help make the cleansing traceable and repeatable.