ERP Data Migration: A Step-by-Step Plan for Clean Cutover
By Apex Horizon Digital
ERP migration fails quietly when teams treat it as a one-time export and import. The visible load may succeed while duplicate customers, invalid units, incomplete opening balances, and unowned exceptions damage the first weeks of operation. A clean cutover needs a migration workbook that connects business scope, source fields, transformation rules, validation evidence, and accountable sign-off. It also needs repeated trial loads using production-like volumes. The objective is not merely to move every row. It is to start the new ERP with the right records, balances, relationships, and audit evidence.
Key takeaways
- Define migration scope and business ownership before extracting data.
- Use repeatable mappings, cleansing rules, trial loads, and reconciliations instead of manual last-minute fixes.
- Set cutover gates, rollback criteria, and signed acceptance for every critical data domain.
1. Inventory sources and decide what should move
Create a source inventory covering applications, spreadsheets, shared folders, databases, and manually maintained lists. For each source, record its owner, extraction method, date range, volume, encoding, identifiers, known defects, and legal retention needs. Classify data as master, open transaction, balance, history, reference, attachment, or configuration. The business owner must decide whether it belongs in the new ERP, an archive, or neither.
Avoid importing history simply because it exists. Determine which historical detail users need for operations, audit, warranty, service, or comparison. Older closed transactions may remain in a read-only archive if access and retention are controlled. Define the cut-off date and the system of record for the transition period so teams do not continue editing both systems without a reconciliation method.
- Named source and business owner
- Data class and retention decision
- Extraction method and cut-off
- Target, archive, or exclusion
2. Map fields, keys, transformations, and dependencies
Build a mapping workbook with one row per target field. Include source field, target entity, target field, data type, required status, transformation, default, lookup, validation, and owner approval. Document how source identifiers become stable target keys. Customer names are not safe identifiers, and spreadsheet row numbers should never become permanent business keys. Preserve a cross-reference table so migrated records can be traced back to their origins.
Sequence dependencies explicitly. Units, currencies, tax codes, warehouses, account mappings, and users may need to exist before products or transactions can load. Define how composite records and many-to-many relationships are assembled. If several sources claim to own the same field, select an authority and write a conflict rule. Mapping decisions should be versioned and executed by repeatable scripts or controlled jobs.
- Source-to-target field map
- Stable key and cross-reference
- Transformation and conflict rule
- Dependency and load sequence
3. Clean data with measurable acceptance rules
Profile each domain for missing required values, duplicates, invalid formats, orphaned references, impossible dates, inconsistent units, and inactive records still used in open transactions. Agree on matching rules before merging duplicates. A customer with a similar name may be a branch, a separate legal entity, or a true duplicate. Business stewards should review ambiguous matches and record the surviving identifier.
Turn quality expectations into counts and thresholds. Record total rows, accepted rows, rejected rows, corrected rows, duplicate groups, and unresolved exceptions. Do not hide failed records by dropping them from the load. Give every exception a reason, owner, due date, and disposition. Freeze cleansing rules before final rehearsal so a late change does not alter balances unexpectedly.
- Required-field completeness
- Duplicate and matching rule
- Referential integrity check
- Exception owner and disposition
4. Rehearse full loads and reconcile business totals
Run at least one end-to-end trial using production-like volume and the same tools planned for cutover. Measure extraction, transformation, loading, indexing, validation, and recovery time. Test reruns so the team knows whether a failed batch can resume safely or must be rolled back. Capture logs and rejected records in a location accessible to both technical and business reviewers.
Reconciliation must operate at several levels. Compare record counts and control totals, then verify financial balances, inventory quantities and values, open order totals, receivable and payable aging, and sampled record relationships. Validate representative edge cases, not only the largest totals. A successful technical load is not acceptance until domain owners sign the evidence and explain every material difference.
- Production-like rehearsal
- Runtime and rerun behavior
- Counts, control totals, and balances
- Sample checks and signed variance
5. Execute cutover with gates, ownership, and rollback criteria
Write a minute-by-minute cutover runbook with task, predecessor, owner, expected duration, evidence, and go or no-go gate. Include source freeze, final extraction, backup, load, reconciliation, integration activation, user access, smoke tests, communications, and hypercare. Confirm how transactions received during the freeze will be queued or entered later. Keep business decision makers available, because only they can accept explained variances.
Define rollback triggers before cutover begins, including maximum delay, critical reconciliation failure, missing data domain, or unsafe integration behavior. Assign authority to call rollback and rehearse the recovery path. After launch, monitor data-quality exceptions, interface failures, duplicate creation, and opening-balance adjustments daily. Close migration only when owners sign the final workbook and remaining issues have controlled resolutions.
- Timed runbook and dependencies
- Evidence-based go or no-go gates
- Pre-agreed rollback triggers
- Hypercare metrics and final sign-off