Test Migration
A test migration is a trial run of the data transfer into a new system – the data from the legacy system is loaded fully into the target system, but not put into production. It surfaces mapping errors, format problems and data gaps before the real go-live happens.
A test migration is a complete trial run of the data transfer from a legacy system into a new target system, in which the transferred data is checked but not yet used productively. It is a central building block of every data migration during an ERP rollout: instead of loading the real data straight into the productive system on the first attempt, the entire extraction, transformation and loading process is first played through in a test or sandbox environment. This makes errors and gaps visible while they can still be corrected without consequences.
The purpose is simple: no migration concept survives first contact with real legacy data. Field mappings do not fit, mandatory fields stay empty, number formats or special characters break, totals do not add up. A test migration makes exactly these problems measurable and reproducible before they reach live operation. As a rule, testing is done not just once but across several runs, until the results are stable and complete – only then does the productive migration follow on the cut-over date.
At a glance
- Trial run of the data transfer in a test/sandbox environment, not productive
- Surfaces mapping errors, format problems, empty mandatory fields and total discrepancies
- Repeated iteratively until the result is stable and complete
- Basis for acceptance (validation) by the business department and key users
- Prerequisite for a clean cut-over and go-live
What a test migration is and what it is for
In a test migration, the entire sequence of a data migration – extracting from the legacy system, cleansing, transforming, field mapping and loading into the target system – is run through in full, but into a non-productive environment. The result serves purely for verification: did all records arrive? Are the counts, totals and field contents correct? Can the migrated data be processed correctly in a business sense in the new system, for example invoicing a transferred order or picking an item?
The test migration is therefore not a technical sideshow, but the most important quality assurance instrument of the data transfer. It turns a theoretical migration concept into solid findings and provides the factual basis for whether the real migration may even be risked. Without a documented, successful test run, a go-live is flying blind.
How a test migration works
A test migration follows the pattern of the actual migration, but is deliberately designed as an iteration. First, a realistic data extract is pulled from the legacy system – ideally a complete dataset, not just a sample, because it is precisely the special cases and dormant records that cause the errors. This extract runs through the defined transformation and mapping rules and is loaded into the test instance of the target system.
The evaluation follows: load logs and error lists are analysed, record counts reconciled, control totals (such as inventory values or open items) compared, and samples checked in a business context. Every error found leads to a correction of the mapping, the cleansing rules or the source data – after which the next run begins. This cycle repeats until the error rate approaches zero and the business department accepts the results.
Test migration and field mapping
The most common finding of a test migration concerns the field mapping: a field from the legacy system was assigned to the wrong target field, a mandatory field in the target system has no counterpart, or values have to be re-coded (for example free-text countries onto ISO codes). Because the test migration works with real data, these gaps emerge concretely and traceably – unlike a purely desk-based review of the mapping.
How many runs are needed?
There is no fixed number, but two to four runs are usual in ERP projects: a first technical run just to get data through at all, followed by business runs for content corrections and a final dress-rehearsal run as close as possible to the cut-over. The last test run should mirror the later productive run as exactly as possible, including the time required, so that the cut-over window can be planned realistically.
Why the test migration is decisive for go-live
Faulty data is one of the most common reasons for failed or delayed ERP rollouts. If a migration is run straight into production without sufficient testing, duplicates, incorrect stock or incomplete open items end up in the live system – and are often only noticed weeks later, once processes have already been built on top of them. The test migration shifts the risk forward, into a phase in which corrections are cheap.
At the same time, it delivers solid metrics for the go-live decision: error rates, completeness, required runtime. These figures feed into the release (acceptance) by project management and key users and make the cut-over plannable. A successful, documented test run is therefore a formal release criterion for the productive transfer in many projects.
Distinction: test migration vs. data migration and parallel operation
The test migration is a sub-step of the data migration, not a replacement for it. The data migration covers the entire process of the data transfer; the test migration is its non-productive trial run. After successful test runs, the actual, productive migration follows on the fixed cut-over date.
The test migration must also be distinguished from parallel operation: in parallel operation, the old and new systems run productively side by side for a time after go-live in order to compare results. The test migration, by contrast, takes place before go-live and is pure preparation. It differs from a simple data import routine in that it maps the complete migration process with the full dataset and is explicitly designed for verification and acceptance – not for ongoing operation.
Test migration in the ERP system
Many ERP systems provide a separate test or sandbox instance for test migrations, which technically resembles the productive system but is isolated. Depending on the system, the import is done via structured import templates (CSV/Excel), via an API or via specialised migration tools. It is important that the test instance has the same configuration state as the later productive system – number ranges, mandatory fields and customising must match, otherwise the test results are worthless.
In DACH projects, the verification of financially relevant data is especially important. Transferred open items, account balances and inventory valuations must be reconciled with the legacy system to the cent in the test run, because they later form the basis of accounting and thus of GoBD-relevant processes. The traceability of the migration itself – which record was transferred when and how – ideally belongs in the process documentation (Verfahrensdokumentation) as well.
Example
Test migration at a trading company
A mid-sized online retailer with around 18,000 items and 12,000 customers switches from an old inventory management system to a new ERP. In the first test run, all customers are loaded, but 640 records end up without a country, because the legacy system kept the country as free text and the target system expects an ISO code as a mandatory field. In addition, the transferred total inventory value deviates by 4,200 euros – the cause being items with negative stock that the new system treats differently.
The project team corrects the mapping rule for the country and defines a cleansing step for negative stock. The second test run completes cleanly, inventory value and open items match to the cent. Only after this accepted result is the date set for the productive migration – which is why the go-live weekend passes without nasty surprises.
Frequently asked questions
Related services
Sources
Questions about Test Migration in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.