Data Migration
Data migration is the planned, one-off transfer of data from a legacy system into a new system – for example during an ERP rollout. Master and transactional data are extracted, cleansed, remapped and moved into the structure of the target system.
Data migration is the planned, usually one-off transfer of data from a legacy system into a new target system – classically when switching or first introducing an ERP system. Unlike an ongoing data exchange, it is a self-contained project with a defined cut-over date: the data is extracted from the legacy environment, cleansed, adapted to the data model of the new system (transformed) and finally loaded into it. The goal is for the new system to work with correct, complete and consistent data at go-live.
The data affected is above all the master data (products, customers, suppliers, accounts) and, depending on scope, also open items, stock levels and historical transactional data such as orders or invoices. Because legacy stocks almost always contain duplicates, typos, dead records and inconsistent formats, the real challenge is rarely the technical transfer but the upstream data cleansing and clean mapping of the fields. A poorly prepared data migration merely shifts old baggage into a new, more expensive system – a good one creates the foundation for reliable processes and reporting.
At a glance
- One-off, project-based transfer of data from a legacy into a target system
- Core steps: extract, cleanse, transform/map, load, validate (ETL)
- Affects master data, open items, stock levels and, where applicable, historical documents
- Success factor no. 1: data quality – "garbage in, garbage out"
- To be distinguished from ongoing data import/export and interface integration
How a data migration works
A data migration usually follows the ETL pattern: extract, transform, load. First the data is extracted from the legacy system – via database export, API or a standardized CSV/Excel extract. It is then transformed: cleansed, deduplicated, reformatted and mapped to the field and value structure of the target system. Only after that does the loading into the new system take place, followed by a validation that checks whether counts, totals and field contents are correct.
In practice, a migration is not put live in one go but tested iteratively. Several test runs ("test migrations" or "migration trials") with real data expose mapping errors, missing mandatory fields and format problems before they reach live operation. Shortly before go-live, a final cut-over date is set at which the current data state – in particular open items and stock levels – is frozen and transferred.
Field mapping and re-keying
Field mapping defines which field in the legacy system corresponds to which field in the target system – for example "customer no." to "debtor number" or a free-text country to a standardized ISO country code. Values often have to be re-keyed in the process because the new system expects different keys, number ranges or mandatory fields. A well-documented mapping is the heart of every migration: it makes decisions traceable and test runs reproducible.
Big bang vs. phased migration
In a "big bang", the entire dataset is transferred on a cut-over date and the legacy system is switched off – clean in one cut, but riskier. In a phased (staged) migration, the legacy and new systems run in parallel for a while, and data areas are transferred one after another. This lowers the risk but increases complexity, because both systems have to be kept in sync temporarily.
Why data quality decides success
The principle "garbage in, garbage out" applies especially to data migration. If faulty or duplicate records are transferred unchecked, they propagate into every document that later references them – and undermine users' trust in the new system from the outset. That is why data cleansing belongs, in business terms, before the technical transfer: merge duplicates, weed out dead records, standardize formats and add missing mandatory details.
It has proven effective to measure data quality early and to involve owners from the business departments, because only they can judge whether a record is still needed or a value is correct. Typical checkpoints are completeness of mandatory fields, uniqueness of numbers, validity of formats (such as IBAN, VAT ID or postal code) and the resolution of duplicates into a single record. The migration is often deliberately used to declutter legacy stocks – for example not carrying over inactive products or customers with no revenue. Fewer but clean records are almost always more valuable than a complete but polluted legacy stock.
Data migration in the ERP project
In an ERP rollout, data migration is regularly the most demanding and delicate sub-area – and a frequent reason for postponed go-live dates. It should therefore be run as a self-contained sub-project with its own schedule, responsibilities and test concept, not as a side task of the software rollout. Scope and objectives ideally belong in the requirements specification, so that it is clear which data is transferred and to what depth.
A central decision is how to handle history: do ten years of invoice history have to go into the new system, or is it enough to migrate open items and current master data and archive the legacy system in an audit-proof way for evidence purposes? The latter is often cheaper and, from a GoBD perspective, sufficient, provided the records subject to retention remain available unalterably in the legacy system or archive.
Distinction: migration vs. import/export vs. integration
Data migration is a one-off, project-based process with a cut-over date. Data import/export, by contrast, denotes recurring bulk transfers during ongoing operation – such as the regular import of a price list. Integration, in turn, is the permanent, often automated exchange of data between productive systems via APIs or interfaces, for example between ERP and online shop. Migration is thus the one-off transfer, integration the ongoing synchronization.
Typical risks and how to control them
The most common mistakes are underestimated data volumes, unclear responsibilities for the cleansing, missing or too-late test runs and a mapping that has not been agreed on in business terms. Semantic differences are particularly treacherous: if a field means something different in the legacy system than in the target system, a purely technically correct mapping still leads to wrong results.
The risk becomes controllable through a repeatable approach: documented mapping, several test migrations with real data, defined acceptance criteria (record counts, control totals, samples) and a rollback plan in case the final load run fails. Just as important is a realistic time buffer around the cut-over date, because the final transfer often has to take place in a tight maintenance window in which day-to-day business is paused. Anyone who works through these points in a disciplined way turns the supposedly risky data migration into a plannable, reproducible step – and thereby lays the foundation for a smooth go-live.
Example
Example: ERP switch at a multichannel retailer
A retailer with around 12,000 products and sales via its own shop and marketplaces switched from a grown siloed solution to an integrated ERP. The legacy stock contained numerous duplicates in the customer base, inactive products and inconsistent country codes. Instead of transferring everything, the team defined clear rules in the pre-project: customers with no revenue in the last three years were dropped, products were normalized to unique numbers, countries mapped to ISO codes.
In three test migrations, mapping errors and missing mandatory fields were uncovered and corrected. At the cut-over date at the end of the month, only current master data, open items and stock levels were loaded live; the complete document history remained audit-proof in the archived legacy system. The result: a go-live with clean data, reliable stock on day one and a significantly smaller but correct dataset – the effort was almost entirely in cleansing and mapping, not in the actual load process.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about Data Migration in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.