ERP Data Migration Without the Go-Live Surprises

What ERP Data Migration Actually Means

ERP data migration is the structured transfer of master data (customers, products, vendors), open transactions, historical records, and configuration from one or more legacy systems into the data model of a target ERP. It is not a file copy. Done properly, it is a sequence of extraction, cleansing, transformation, loading, and reconciliation steps that preserve accuracy, completeness, and referential integrity so the new system can transact on day one.

Practitioners often use ERP data conversion as a near-synonym. Conversion emphasizes reformatting and transforming values (chart-of-accounts rollups, unit-of-measure crosswalks, tax codes); migration is the broader program that includes conversion plus scoping, governance, trial loads, cutover, and sign-off. When search or RFPs say "data conversion," they almost always mean this full workstream.

Migration is also where most ERP implementations get into trouble. Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, and as many as 25% will fail catastrophically, with data risks (inaccuracy, redundancy, and loss during legacy migration) identified among the key implementation roadblocks. A separate McKinsey analysis found that roughly three-quarters of ERP transformations fail to stay on schedule or on budget. The data layer is the single largest controllable variable behind those numbers.

For SMEs, the stakes are concentrated. A mid-size business running one chart of accounts, one inventory ledger, and one customer list does not have margin for reconciliation breaks on day one. Whether you are moving into Microsoft Dynamics 365 Business Central, Dynamics 365 Finance & Operations, or Odoo, the migration pipeline is the same shape; only the tooling and entity model differ.

The Seven-Stage ERP Data Migration Pipeline

Every credible migration runs an enhanced ETL pipeline that ends in cutover and hypercare—not just a one-shot load. Microsoft formalizes the strategy side in Success by Design; Odoo partners follow the same sequence when loading master data via the built-in importer. Treat the pipeline as iterative: you will loop through cleansing, mapping, trial loads, and validation several times in a sandbox before the final cutover.

Teams that estimate cutover duration from a tiny sandbox extract almost always underestimate. Operations that dominate the weekend window—index rebuilds, conversion scripts, full validation passes—do not scale linearly with row count. Rehearse at production-like volume so the go/no-go decision is a measurement, not a guess.

1. 01
   1. Plan, assess, and audit

   Inventory every source system, classify data into master, reference, document, and transaction buckets, and define scope and quality thresholds. Decide now how much history you will migrate (typical SME practice is 1–3 years of transaction detail, sometimes 3–5 for operational reporting, extended only for audit or tax). Assign Data Owners (senior business leaders accountable for a domain) and Data Stewards (subject-matter experts who execute governance day-to-day) before any data moves.

2. 02
   2. Extract

   Pull data via ETL tools, vendor APIs, SQL queries against the source database, or structured exports. For Dynamics 365, exports from AX, GP, NAV, or SL can later feed the Data Management Framework or the Business Central Cloud Migration tool. For Odoo, exports include an External ID column so records are addressable on import.

3. 03
   3. Cleanse

   Legacy systems routinely carry null names, invalid emails, orphaned foreign keys, duplicate masters, and even negative prices that "worked" for years in the old UI. Deduplicate against surviving keys, standardize formats (dates, currencies, phones), fix missing required fields, and resolve orphans before mapping. Industry analyses from Panorama Consulting repeatedly flag data quality as a leading cause of migration overruns. Cleansing is the most labor-intensive and frequently underestimated stage—never use the new ERP as the cleansing tool.

4. 04
   4. Map and transform

   Build field-to-field schema maps between source and target, with business-rule conversions (chart-of-accounts rollups, unit-of-measure translations, tax-code crosswalks). Document mapping type (direct, lookup, consolidated, conditional) and require business owner sign-off per entity. This is where source semantics get reconciled to the target ERP's entity model.

5. 05
   5. Trial load (sandbox, multi-pass)

   Bulk-import into a non-production environment first—ideally three full-volume rehearsals: practice, UAT, then production cutover. In Dynamics 365 Finance & Operations, the Data Management workspace uses Data Entities with sequencing (execution units, levels, sequence numbers) to respect dependencies. In Odoo, the importer uses External IDs for idempotent create-or-update behavior. Measure elapsed time, exception rates, and reconciliation gaps after every pass.

6. 06
   6. Validate and reconcile

   Compare row counts, hash totals, and checksums. Run full trial-balance reconciliation, match every open AR/AP and inventory item to legacy, test relationship integrity, and execute end-to-end process tests (order-to-cash, procure-to-pay). Penny-perfect financial tie-out beats "record counts look close." Sign-off is a business gate, not an IT checkbox.

7. 07
   7. Cutover and hypercare

   Freeze the legacy system on a planned cut-off (prefer month- or quarter-end), run the final extract and load, smoke-test, open the new ERP, and staff a hypercare window (typically 2–8 weeks) with clear SLAs for P1 data defects. Archive legacy access for audit after stability; do not leave dual entry open indefinitely.

What to Migrate: Master Data, Open Transactions, and History

Scope creep is one of the most common single causes of ERP project failure. Deciding mid-project to migrate 10 years of closed history instead of 3, or adding entities and custom fields without change control, drives timeline slips and cost overruns. Lock scope before extraction begins.

A practical framing used by migration specialists in 2025–2026 is a four-bucket model: (1) migrate live and structured into the production ERP, (2) migrate as summary balances for comparative reporting, (3) archive in a queryable store outside the live ledger, and (4) do not migrate (test data, voids, expired drafts, pure junk). Microsoft’s own GP and QuickBooks migration paths are selective by design—masters, open documents, on-hand inventory, beginning balances, and optional chosen history—not a blind copy of every legacy row.

The recommended SME pattern is clear: migrate clean master data and open transactions (unfulfilled orders, open AR/AP, current inventory balances, and the trial balance / opening balances), keep a bounded window of detailed history when reporting requires it, and archive the rest in a read-only legacy system or data lake. Compliance retention (often discussed as a multi-year or ~7-year practical safe harbor for financial records) usually requires accessibility, not that every closed invoice lives inside the new cloud ERP. Data migration workstreams are frequently under-resourced relative to cleansing, mapping, and multiple validation cycles—treat data as a first-class stream with a dedicated lead, business stewards per domain, and a technical analyst for mapping.

• →Prefer month-end or quarter-end cut-offs; mid-month freezes force partial-period splits and harder reconciliation.
• →For open AR/AP, migrate open documents (not a single balance-forward journal) unless the business explicitly accepts loss of invoice-level continuity.
• →Archive older history in a read-only backup or warehouse so auditors can query without polluting the new ledger.
• →Define history depth per object (GL, AR, AP, inventory, fixed assets, attachments)—never as one vague SOW line called "historical data."

Validation Checks That Gate Cutover

Validation is not "did the import finish without errors." It is proving that the new system is financially and operationally trustworthy before users transact. Build a validation dashboard or reconciliation pack before the final load: if numbers do not match exactly on critical controls, nothing ships.

Run the same pack after every trial load. Finance owns trial balance and aging sign-off; operations owns inventory quantities and open order fidelity. IT owns row counts, referential integrity, and load logs.

Inventory, Lot/Serial, and Open Transactions: What Breaks Cutover

Practitioners consistently rank data quality above tool choice, and two domains punch above their weight at go-live: open subledger documents and inventory that is lot- or serial-controlled. A migration that finishes “without import errors” can still strand warehouse picks, break invoice matching, or misstate inventory valuation if these objects were treated as simple quantity dumps.

On-hand conversion is not only qty-on-hand as of the freeze date. Infosys’ on-hand conversion guidance for ERP transformations stresses four practical co-dependencies: inventory aging and consumption history (for reserves and obsolescence), co-conversion of open PO receipts (goods received not invoiced / GRNI) and open work orders with WIP material issues, cost attributes that match the target cost method (standard vs actual/average receipt layers), and lot or serial control at item level with correct tags on physical stock. Loading all inventory as “zero-age” on cutover date can satisfy valuation totals while destroying aging-based reserves and FIFO/layer logic.

Open transactions are the other classic killer. Open AR and AP must usually land as documents (invoice/bill level), not a single balance-forward journal, if collections, payment applications, and aging buckets must continue without a hard break. Open sales and purchase orders need valid item, customer/vendor, tax, and warehouse masters already present. Open WIP needs material issued to the job kept distinct from free on-hand so you do not double-count stock. In-transit inventory and receipt accruals need explicit ownership rules so the first post-go-live physical receipt does not double-post.

For lot- and serial-controlled items, rehearse the full path in a sandbox with production-like volumes: item control flags, lot/serial attributes on on-hand, warehouse location tags, and any lot-level cost. Enabling lot control for the first time in the new ERP is a warehouse labeling project as much as a data project—physical tags must match system tags before pick/pack starts. Industries that value inventory at lot or serial level (precious metals, life sciences, high-value chemicals) cannot treat lot history as optional fluff; valuation layers ride on those identifiers.

• →Agree whether on-hand loads include or exclude quantities already on open PO receipts—ambiguity here is a reconciliation trap.
• →Match cost method early: standard cost can load qty with standard independently; average/actual needs receipt-layer costs from legacy.
• →If you turn on lot/serial control at go-live for the first time, budget warehouse tagging time inside the cutover runbook, not as an afterthought.

Assess Fitness With the DAMA-UK Data Quality Dimensions

Before you migrate, score source data against the six dimensions defined by DAMA-UK (the Data Management Association UK working group) in its Six Primary Dimensions for Data Quality Assessment, and adopted across DAMA-DMBOK, the UK Government Data Quality Hub, and industry practice. These are vendor-neutral and apply equally to Dynamics 365 and Odoo.

Gartner consistently identifies data risks among the key roadblocks to ERP success, noting that migration from legacy systems can cause data inaccuracy, redundancy, or loss. Poor source quality causes reconciliation failures, broken processes, bad reporting, and user distrust—trust that is lost in a week and rebuilt over months. Scoring against these dimensions turns that risk into a measurable, assignable workstream.

• →Accuracy: the data correctly represents reality (a customer's actual address, a product's real cost).
• →Completeness: all required fields are populated (no missing tax IDs, no empty posting groups).
• →Consistency: data is uniform across systems (the same customer record does not differ between CRM and legacy ERP).
• →Validity: data conforms to formats and business rules (postal codes match country patterns, account numbers respect the chart of accounts).
• →Uniqueness: each entity is represented once, with duplicates merged to a survivor record.
• →Timeliness: data is current and available when needed (open balances reflect the latest sub-ledger close).

Data Governance: Owners, Stewards, and MDM

Migration success depends on governance assigned before day one, not after the first reconciliation break. Per DAMA-DMBOK, a Data Owner is a senior business leader accountable for a data domain (defining policies, access, quality thresholds), while a Data Steward is a subject-matter expert who executes governance day-to-day (maintaining definitions, monitoring quality rules, resolving issues).

Gartner defines Master Data Management (MDM) as a technology-enabled business discipline in which business and IT work together to ensure the uniformity, accuracy, stewardship, governance, semantic consistency, and accountability of the enterprise's official shared master data assets. For SMEs, a formal MDM platform is rarely required, but the discipline is: pick one source of truth per master entity before you migrate, and route every duplicate to a survivor.

That survivor is the golden record: the single authoritative customer, vendor, or item profile that wins when duplicates merge. Decide merge rules in writing (which address, which payment terms, which tax ID, which credit limit survives) and re-point open documents to the golden key before trial load. Leaving three spellings of the same vendor with different bank details is how AP pays the wrong account on week one.

Freeze new custom fields and ad-hoc master attributes once mapping starts. Every late field is built, tested, and reconciled twice—once in legacy cleanup and once in the target—and is a classic timeline killer. Controller or finance lead involvement from cleansing—not only from UAT—is a recurring pattern in successful Business Central migrations: tax IDs, RFC-style identifiers, and posting group gaps surface earlier when finance owns quality gates.

Dynamics 365 Migration: Configuration Packages and the Data Management Framework

Microsoft splits migration tooling by product line.

In Business Central, RapidStart Services evolved into the Configuration Packages feature. Packages are applied via a Configuration Worksheet that bundles setup tables, master data (customers, vendors, items), posting groups, and number series. Packages are strong for setup and moderate master volumes; partner guidance in 2025–2026 still treats them as a poor sole tool for large related datasets because parent/child failures can leave orphans if relationships are not carefully sequenced and validated. Many SME projects combine Configuration Packages (or RapidStart-style loads) for masters and setup with API, Azure Data Factory, or scripted loads for open documents and history. Watch for silent package failures—imports that appear complete while some tables never applied—and always reconcile row counts and sample records after every package apply.

For supported legacy sources, the built-in Cloud Migration tool replicates SQL data to BC online. Microsoft documents that Dynamics GP (2015 and later) and Dynamics SL (2015 and later) are directly supported; Dynamics NAV is not directly supported and must first be upgraded to Business Central on-premises before replication to BC online. From Business Central on-premises version 25 and later you can migrate directly online; versions 15–24 must upgrade on-premises to at least 25 first. For BC 14, Microsoft also documents a reimplementation path that migrates essential master data, opening balances, and setup without a full on-prem upgrade first. Configuration packages exported between companies still require matching schema (same table/field structure and package version alignment with the target environment).

In Dynamics 365 Finance & Operations, the Data Management workspace is the central UI for the Data Management Framework (DMF), which replaced the legacy AX 2012 DIXF. DMF uses Data Entities as the reusable abstraction. Entities are de-normalized business-object views over underlying tables, categorized by data type for sequencing: Parameter (functional settings), Reference (lookup data such as units and tax codes), Master (customers, vendors, products), Document (orders and journals with header plus lines), and Transaction (posted operational data, often summarized or excluded in migrations).

F&O configuration data templates provide predefined, sequenced entity lists per module (Financials, Supply Chain, and so on). Entities must be sequenced by execution units, levels, and sequence numbers to respect dependencies: system setup and global address book before the general ledger, before master data, before documents and opening balances. Staging tables let you preview, clean, and fix errors before the target load.

For large F&O migrations, Microsoft's official optimization guidance is explicit: disable change tracking where possible, enable set-based processing, use dedicated migration batch groups, tune threads and thresholds per entity, minimize validations during bulk load (and re-enable them after), clean staging tables, update statistics, and chunk files. Microsoft's Success by Design framework includes a dedicated Data Migration Strategy workshop that prescribes phased migration with sandbox testing and mock cutovers.

Odoo Migration: External IDs, the Built-in Importer, and OpenUpgrade

Odoo's migration model centers on External IDs (also called XML-IDs): stable, human-readable identifiers stored in the ir.model.data table. The built-in importer (list view, then Actions, then Import records) supports CSV and Excel files and ships with ready-made templates that always include an External ID (ID) column. Odoo's documentation states this column should never be removed, because it enables idempotent imports: new records are created, existing matching records are updated.

The recommended pattern for migrating from third-party systems is to use legacy unique keys as External IDs (prefixed to avoid collisions, for example legacy_customer_123) and to reference related records via the Field/External ID column pattern. This gives you create-or-update behavior so the same file can be re-imported safely as you iterate on cleansing. Imports must follow dependency order: parents and reference data before children. For large volumes, chunk files (for example a few thousand rows per batch) and validate each batch before the next.

For Odoo major version upgrades, the official Enterprise path is the Odoo Upgrade Service at upgrade.odoo.com: request a test upgraded database, validate it, then request the production upgrade. The Community Edition alternative is OCA's OpenUpgrade, the primary open-source tool for Odoo database upgrades. OpenUpgrade contains openupgrade_framework (a server-wide module), openupgrade_scripts (per-module analysis and migration scripts), and the openupgradelib Python helper library. OpenUpgrade requires version-by-version migration; you cannot skip major versions, and the process tends to surface data issues that older versions tolerated.

For developer-loaded data, Odoo XML data files use <record id='...' model='...'> with ref='module.id' for relations, and CSV data files use id as the first column; noupdate='1' protects records from overwrite on upgrade. Most SME migrations use the importer with External IDs for master data, write custom Python against the Odoo ORM (via odoo-bin shell or XML-RPC) for complex transforms, and reserve OpenUpgrade for version jumps.

Cutover Strategy: Big Bang vs Phased, Freeze, and Downtime

For ERP cutover, a Big Bang approach (single cutover date) offers a faster timeline but the highest risk, while a Phased approach (by module, site, or function) reduces per-phase risk but extends the timeline and requires dual-system operation. A third pattern—dual-run or parallel period—keeps legacy and new ERP live for a defined window (often weeks to a few months for finance) so outputs can be reconciled before the legacy is locked read-only. SMEs with clean data and simple operations often choose Big Bang; multi-warehouse or regulated businesses tend to favor Phased; mission-critical or low-trust-data environments use dual-run when the business can absorb double entry or invest in temporary dual-write/integration.

Regardless of approach, industry best practice is to run multiple full test migrations in a sandbox with production-like volumes before cutover, and to mock the cutover itself end to end. Skipping full-volume mock runs is a leading cause of cutover duration overruns—the classic failure is a short test on a tiny extract that becomes a multi-hour outage in production. Practitioner guidance in 2026 is blunt: if your rehearsal used a small fraction of production volume, your cutover duration estimate is a guess, not a measurement—index rebuilds, conversion scripts, and validation passes do not scale linearly with row count.

Write a cutover runbook before dress rehearsal: named owners, minute-by-minute swimlanes, freeze rules, reconciliation gates with exact queries and tolerances, communication cadence, and a rollback decision owner with a clear point of no return. Plan the freeze explicitly: process pending bank recs, payment runs, and journals before hard freeze; export the golden trial balance on the freeze date; run final extract → transform → load → validate within the agreed downtime window. Post-cutover reconciliation techniques should be planned before cutover, not after: row counts, checksums, full trial balance on day one, open-item match for AR/AP and inventory, relationship integrity, and end-to-end process tests.

How Long ERP Data Migration Takes for an SME

There is no honest one-size number, but ranges help leadership plan. The data workstream typically runs in parallel with configuration and often consumes a large share of calendar time—partner and practitioner guides commonly place data-related effort in the range of roughly 40–60% of migration project timeline when cleansing is non-trivial.

For a single-entity SME with one legacy ERP and moderately clean masters, expect multi-week data audit and cleanse (often on the order of 4–8 weeks of focused work when quality issues are material), then iterative map → trial load → validate cycles before a planned cutover weekend. Multi-source landscapes, heavy customization, multi-currency, or regulated industries stretch that into months. Always schedule at least two full-volume rehearsals plus a dress-rehearsal cutover before go-live.

What stretches the schedule: late scope adds ("bring 10 years of history"), no data owners, cleansing only discovered in UAT, and cutover estimates based on tiny extracts. What compresses it: locked entity list and history window, early profiling, idempotent loads (External IDs / DMF re-runs), and a written validation pack with named owners.

• →Simple single-company, clean masters: data workstream often fits inside a 3–4 month overall implementation with continuous cleansing.
• →Typical mid-complexity SME: plan months of parallel data work with 2–3 full mock loads before cutover.
• →High complexity (multi-entity, multi-legacy, deep history): treat data as a multi-month program with formal change control on every new entity.

Common Failure Modes (and How to Avoid Them)

Most migration failures fall into a small number of recurring patterns. Naming them early is the cheapest way to avoid them.

• →Dirty data loaded unchecked: nulls, orphans, negative prices, and duplicates that "worked" in legacy. Cleanse before mapping; score all six DAMA-UK dimensions on every master entity; merge to golden records.
• →Scope creep on history: lock the entity list and history window before extraction. Any addition goes through formal change control.
• →Open AR/AP as balance-forward only when the business never needed invoice-level continuity—otherwise collections and cash application break.
• →Lot/serial and on-hand treated as simple qty dumps: warehouse picks, GRNI, open WIP, and cost layers fail after go-live even when GL totals match.
• →Under-resourcing the data workstream: staff a dedicated data lead, business stewards per domain, and a technical analyst for mapping from day one.
• →Sandbox-only volume testing: a small extract that finishes in minutes can become hours of downtime at full volume. Rehearse at production-like scale.
• →No reconciliation plan on day one: define row counts, checksums, trial-balance match, open-item match, and process tests before cutover, not after.
• →Ignoring sequencing and dependencies: in F&O, system setup and global address book before GL before master before documents; in Odoo, parents and reference data before children.
• →Trust left to training: if finance and operations do not trust balances in week one, adoption stalls. Prove integrity at cutover, visibly, with signed reconciliation packs.

Frequently asked questions