ERP Data Migration Survival Guide

Data migration is where ERP projects go to die. According to Bloor Research, 83% of data migration projects either fail or exceed their budget and schedule^[1]. The reason is not technical complexity alone. It is that companies underestimate the gap between how data looks in the source system and how it must look in the target system, and the business logic encoded in that gap.

This guide provides a practical framework for migrating data between ERP systems in a Nordic manufacturing context, where regulatory compliance, multi-country operations, and decades of accumulated business rules create unique challenges.

Phase 1: Data Discovery and Assessment

Before writing a single migration script, you need to understand what you are migrating. This is the most commonly shortcut phase, and skipping it is the primary cause of migration failure.

Inventory every data entity. A mature ERP installation typically contains 300 to 800 active database tables^[4]. Not all need to be migrated. Classify each as: must migrate (master data, open transactions), should migrate (historical transactions for compliance), nice to have (archived data), or do not migrate (temporary, obsolete, or corrupt data).

Map data dependencies. ERP data is deeply interconnected. A sales order references a customer record, which references a price list, which references a currency table. Migrating sales orders without their complete reference chain produces broken records. Build a complete dependency graph before starting.

Identify hidden business logic. This is the killer. Every ERP accumulates business logic in places that are not obvious: validation rules, default values, automatic number sequences, conditional field visibility, inter-table triggers, and scheduled jobs. A Finnish manufacturer we worked with discovered 147 custom validation rules in their Monitor ERP that existed nowhere in documentation. Every one had to be understood and replicated.

Phase 2: Data Mapping and Transformation

Create explicit field-level mappings. For every field in the target system, document where the source data comes from, what transformation is applied, and what the default value is when no source exists. This mapping document becomes the single source of truth for the entire migration.

Handle code translations. Every ERP uses internal codes for status values, categories, units of measure, and business classifications. These codes rarely match between systems. A status field containing "10, 20, 30, 40" in the source system might need to become "Draft, Confirmed, Shipped, Invoiced" in the target. Map every code value explicitly.

Address data quality issues proactively. Migration is the one chance to clean data. Duplicate customer records, orphan transactions, inconsistent unit-of-measure usage, and missing mandatory fields are all common. Build data cleansing into the migration pipeline, not as a separate post-migration project.

Preserve regulatory data. Finnish tax authorities require 6 years of accounting data retention^[2]. CSRD requires 5 years of sustainability data^[3]. Ensure that historical data migrates with sufficient structure and referential integrity to support regulatory queries in the new system. Do not flatten historical data into summary tables.

Phase 3: Migration Execution

Build migration pipelines, not scripts. A migration pipeline is repeatable, logged, and reversible. Each run produces a detailed log of records processed, transformed, loaded, and rejected. Reject handling is critical: every rejected record must be investigated, not ignored.

Execute iterative test migrations. Run the full migration at least three times against a test environment before the production cutover. Each run will reveal issues: missing mappings, data quality problems, performance bottlenecks, and sequence conflicts. The first test migration typically achieves 60 to 70% data acceptance. By the third run, this should be above 99%.

Validate with business users. Technical validation (record counts, referential integrity, null checks) catches structural errors. Business validation (can a sales manager find their top 10 customers and see correct order history?) catches semantic errors. Both are essential. Recruit key users from finance, production, sales, and logistics to verify migrated data against their daily workflows.

Phase 4: Cutover and Parallel Running

Plan the cutover window. For a Nordic manufacturer, the optimal cutover is a long weekend: Friday evening data freeze in the old system, Saturday migration execution, Sunday validation, Monday go-live. This minimizes business disruption but requires that the migration pipeline can complete a full run within 8 to 12 hours.

Run parallel operations. Keep the old system read-only for a minimum of 3 months post-cutover. Users will need to reference historical data that may not surface through normal workflows in the new system. Finance will need to reconcile period-end reports between old and new systems for at least one full quarter.

Have a rollback plan. If the migration fails catastrophically, you must be able to return to the old system within 4 hours. This means maintaining the old system in a ready state, not decommissioning it on day one. Document the exact rollback procedure and test it during the dress rehearsal migration.

The Business Logic Layer

The hardest part of data migration is not moving the data. It is preserving the meaning of the data. A number in a field is just a number until you understand the business rule that generated it, the calculation that derived it, and the process that depends on it.

Companies that build a vendor-independent business logic layer before migration have a significant advantage. When compliance rules, carbon calculations, and approval workflows exist outside the ERP, they survive the transition intact. The data moves; the intelligence stays.

References

[1] Bloor Research, “The Reality of Data Migration” (2023). Survey finding that 83% of data migration projects fail, exceed budget, or exceed schedule. bloorresearch.com.
[2] Kirjanpitolaki (Finnish Accounting Act) 1336/1997, §10 — accounting records must be retained for six years from the end of the financial year. finlex.fi: 19971336.
[3] Directive (EU) 2022/2464 (CSRD), Article 1(8) amending Directive 2013/34/EU — sustainability reporting data subject to audit and retention requirements. OJ L 322, 16.12.2022. EUR-Lex: 32022L2464.
[4] Panorama Consulting Group, “ERP Report” (2024). Analysis of ERP implementation complexity across manufacturing sectors, including typical database schema sizes for mid-market ERP systems.

Next step: De-risk your ERP migration by extracting critical business logic into a vendor-independent layer first. DWS IQ provides compliance automation, carbon tracking, and workflow orchestration that works across ERP systems. Start the assessment at dws10.com.