ERP Data Migration Done Right: A 12-Week Framework for Zero Downtime

Why ERP Migrations Fail — and Why They Don't Have To

ERP data migration is widely cited as one of the riskiest IT projects a business can undertake. The statistics are grim: industry analysts estimate 50–75% of ERP projects run over time or over budget, and data migration failures are among the top three causes.

The consequences aren't just technical. A failed ERP data migration UK business attempts can mean weeks of parallel manual operation, corrupted financial records, inability to invoice customers, stock discrepancies, and — in the worst cases — regulatory reporting failures.

Yet this doesn't have to be the outcome. The difference between a successful and a failed ERP data migration almost always comes down to process discipline in the first four weeks, before a single record moves.

This article outlines the 12-week framework 2-IC DATA SYSTEMS uses for every ERP data migration UK engagement. It's based on projects covering SAP, Microsoft Dynamics 365, Sage, Oracle EBS, and a range of sector-specific ERPs.

Weeks 1–2: Discovery and Scope

Stakeholder Mapping

ERP systems touch more of the business than almost any other platform. Finance, operations, logistics, HR, procurement, and IT all have data stakes. Before you do anything technical, identify every stakeholder group and map their data dependencies.

For each stakeholder group, document:

• Which modules they use
• Which data they create and consume
• Their tolerance for downtime and data unavailability
• Any regulatory obligations (e.g., Finance's VAT reporting, HR's payroll obligations)

Source System Inventory

ERP databases are typically large, denormalised, and filled with years of accumulated data. Run an automated schema inventory to identify:

• All tables with record counts
• Tables containing personal data (for GDPR purposes)
• Orphaned or deprecated tables (often many in mature ERP deployments)
• Custom developments (Z-tables in SAP, extensions in Dynamics) that won't exist in the destination

Flag any tables with more than 1 million records immediately — these require specific migration strategies (chunked extraction, delta loads) to avoid performance issues.

Define Migration Scope

Not everything migrates. Define three tiers:

1. 1.Full migrate: active master data and recent transactional data (typically last 2–3 years)
2. 2.Archive migrate: historical transactional data loaded to a read-only archive
3. 3.Do not migrate: deprecated data, test records, duplicate entries

A common ERP data migration UK mistake is attempting to migrate all historical data into the live production system. This bloats the destination, degrades performance, and increases project risk. Archive historical data separately.

Weeks 3–4: Data Quality Assessment and Cleansing

Automated Profiling

Run automated data profiling on your extraction:

• Null rates per field
• Duplicate key analysis
• Referential integrity checks (foreign key violations)
• Value distribution analysis (to spot anomalies)
• Date range validation

The results will be sobering. Almost every legacy ERP has integrity issues — orphaned purchase orders, vendors without addresses, stock items with negative quantities. These all need to be resolved before migration.

Business Rules Documentation

Data transformation isn't just technical — it requires business input. Who decides:

• How to consolidate duplicate customer accounts?
• What the correct opening balance is for partially reconciled GL entries?
• Whether to migrate open purchase orders from three years ago or close them out?

Document every business rule explicitly. Get sign-off from the relevant stakeholder. These decisions must be reversible and auditable.

Cleansing Operations

Address data quality issues in the source system, not the migration layer. Changes in a transformation script are invisible to the business; changes in the source system are visible, reviewable, and owned. Common cleansing tasks:

• Deduplication of customer/vendor/employee master data
• Address standardisation (Royal Mail PAF for UK addresses)
• Product code normalisation
• Closure and write-off of aged open items

Weeks 5–6: Field Mapping and Transformation Design

Object-by-Object Mapping

For each source object, produce a mapping specification:

• Source table and field
• Destination table and field
• Data type (with explicit conversion rules where types differ)
• Transformation logic (lookups, concatenations, splits, calculations)
• Validation rule (what constitutes a valid migrated record)
• Owner (who reviews exceptions for this object)

This document becomes the migration bible. Every developer, tester, and business stakeholder works from the same spec.

Handle Structural Differences

ERP systems from different vendors have fundamentally different data models. Moving from SAP to Dynamics 365, for example, involves:

• Different chart of accounts structures
• Different customer/vendor numbering conventions
• Different handling of intercompany transactions
• Different approaches to cost centre and profit centre hierarchies

These aren't just technical problems — they require accounting decisions. Involve finance throughout the mapping phase.

Cutover Strategy

Define your cutover approach now, not at the end:

• Big bang: single cutover on a defined date, all users switch simultaneously
• Phased: module by module (Finance first, then Procurement, then Logistics)
• Parallel run: both systems live for a defined period, with daily reconciliation

For most ERP data migration UK projects, a phased approach with a defined parallel run period per module is the most risk-managed option. It extends the project timeline but dramatically reduces the risk of a catastrophic go-live failure.

Weeks 7–9: Build, Test, Iterate

Migration Script Development

Build extraction, transformation, and loading scripts against the mapping specification. Use a repeatable pipeline:

1. 1.Extract from source to staging area
2. 2.Apply transformation rules in staging
3. 3.Validate against business rules
4. 4.Load to destination test environment
5. 5.Run automated reconciliation reports
6. 6.Generate exception report for business review

The pipeline should be fully automated and runnable on demand. You'll run it dozens of times during testing — it must be reliable and fast.

Unit Testing

Test each object in isolation before testing end-to-end:

• Does the Customer object load with correct field values?
• Are all referential relationships preserved (Customer → Address → Contact)?
• Do calculated fields produce correct outputs?

Integration Testing

Test the migrated data in the context of the destination system's business processes:

• Can Finance close the period with migrated GL data?
• Can Procurement raise a PO against a migrated vendor?
• Can Logistics fulfil an order against migrated stock?

This is where migration issues that aren't visible in reconciliation reports surface. Budget significant time for this phase.

Weeks 10–11: Rehearsal and Sign-Off

Dress Rehearsal

Run a complete end-to-end migration rehearsal against the test environment, simulating the production cutover:

• Extract from a recent copy of the source data
• Apply transformation pipeline
• Load to destination
• Run all reconciliation and business process tests
• Measure elapsed time — is the cutover window achievable?

Ideally, run two or three rehearsals, incorporating fixes from each run. Each rehearsal should be faster and cleaner than the last.

Business Sign-Off

Before you can go live, key stakeholders must sign off:

• Finance: opening balances, GL structure, customer/vendor master
• Operations: stock, open orders, BOM
• HR: employee master (if in scope)
• IT: security, user access, integrations
• Legal/Compliance: DPA, ROPA update, GDPR documentation

No sign-off, no go-live. This isn't bureaucracy — it's the mechanism that prevents someone discovering a data error after you've decommissioned the source system.

Week 12: Cutover and Go-Live

Pre-Cutover Checklist

• Source system freeze point confirmed with all stakeholders
• Final delta extract scheduled and tested
• Support team briefed and on standby
• Rollback plan documented and tested
• Hypercare team rota agreed

Cutover Execution

Execute the migration plan as rehearsed. Don't improvise. If an unexpected issue arises, invoke your decision tree: is this a blocker (roll back) or can it be resolved post-go-live?

Hypercare Period

The two weeks post-go-live are hypercare. Your migration team is on elevated response — data issues found in this period are resolved same-day. Daily reconciliation reports run for the first week, weekly for the second.

By the end of hypercare, the destination ERP should be fully trusted and the source system ready for decommission.

The 12-Week ERP Data Migration UK Timeline at a Glance

Getting Started

The 12-week framework works because it front-loads risk — the discovery, cleansing, and mapping phases are where most ERP data migration UK failures originate, and they're all resolved before any data moves to production.

If you're planning an ERP migration and want a fixed-price proposal built around this framework, book a free scoping call. We'll review your source system, define the scope, and give you a firm timeline and price within 48 hours.