Introduction: “Migration Complete” does not mean “Business Ready”
A legacy ERP migration rarely fails due to a single dramatic error message. More often, it fails quietly: an item loses its unit-of-measure conversion, an opening balance no longer reconciles, an old dimension becomes invalid, or a custom field disappears from the target system.
That is because ERP data is highly interconnected. Customers, vendors, products, inventory, dimensions, tax structures, warehouses, ledgers, and transactions all rely on rules defined elsewhere in the system.
Microsoft distinguishes between configuration data, such as currencies and tax codes, and migrated data, including master data and open transactions. In Dynamics 365 Finance & Operations, data entities provide a structured way to migrate relevant master data and open transactions. Following a structured helps technical teams define staging environments, field mappings, and validation scripts early in the project lifecycle. Business Central has its own supported migration paths and tools.
A migration therefore succeeds when finance can close the books, operations can process orders, and users can trust the information from day one.
Here are five common breakpoints and the controls that help prevent them.
1. Master data loses its meaning
Legacy ERP systems often contain years of inconsistent data for customers, vendors, products, items, addresses, units of measure, and payment terms. Simply loading these records into the target system can replicate those inconsistencies in a newer environment.
Consider three legacy item codes for the same sellable product. Importing all three may preserve the source data while creating unnecessary duplication in the target ERP.
Before migration:
- Profile and cleanse master data.
- Define rules for duplicates and obsolete records.
- Map legacy identifiers to target identifiers.
- Standardize units, currencies, tax registrations, and addresses.
- Have business owners approve critical records.
- Load reference data before dependent master data.
F&O data entities are designed around business data rather than direct database-to-database copying, which makes target-system mapping an important part of the exercise.
The objective is not to move every record. It is to establish a trusted definition for every record the business intends to use.
2. Financial balances and open transactions do not reconcile
Finance is where a migration can appear successful yet produce a serious business problem.
A general ledger trial balance may match, while customer aging does not reconcile with receivables. Inventory quantities may be correct while valuation, costing, location, or batch information is wrong. Open sales and purchase orders can also lose information required to complete fulfillment.
Microsoft specifically identifies open sales orders, open purchase orders, stock on hand, and open balances as migration data for .
A reconciliation-first approach should include the following:
- Establish a clear accounting cutover date.
- Decide what historical data stays in the legacy system.
- Reconcile subledgers to the general ledger before extraction.
- Validate opening balances by legal entity and currency.
- Compare inventory quantities and values.
- Check customer and vendor aging.
- Review open order counts, values, and statuses.
- Obtain formal finance and operations sign-off.
The import job saying “success” is not a financial validation. The numbers still have to agree.
3. Configuration dependencies break
ERP data depends on configuration. Financial dimensions, posting groups, tax codes, warehouses, currencies, payment terms, number sequences, and inventory settings determine how records behave once transactions begin.
Loading data in the wrong order can therefore produce records that look correct but fail when users try to transact. For example, Microsoft notes that dependent configuration entities must be imported in the appropriate sequence, including tax codes before tax groups in relevant F&O scenarios.
A useful migration catalog should record the following:
- Source object and target entity
- Required configuration
- Transformation rule
- Load sequence
- Business owner
- Validation method
- Exception process
For F&O, this means careful selection and sequencing of data entities across finance and supply chain. In Business Central, dimensions, posting groups, extensions, and table mappings can influence what moves and how they behave.
Configuration is the grammar of ERP data. If the grammar is wrong, valid-looking records can still produce incorrect results.
4. Customizations and workarounds disappear
Years of ERP use often produce custom fields, reports, workflows, integrations, attachments, and workarounds that are never included in the standard migration inventory.
Before migration, catalog:
- Custom tables and fields
- Reports and workflows
- Integrations and batch jobs
- Attachments and document references
- Spreadsheet-based processes and side databases
Then classify each as retire, replace, redesign, migrate, or archive.
This does not mean preserving every historical customization. It means understanding why it exists before deciding its fate. For example, Business Central requires legacy C/AL customizations to be converted to AL extensions for supported NAV-to-online migration scenarios, and extension data has its own migration requirements. Partnering with experts for a ensures bespoke C/AL code is refactored into modern AL extensions without losing custom business logic.
Preserve the business capabilities and information that still matter, rather than automatically preserving every piece of legacy complexity.
5. Cutover fails under real conditions
A migration that works in testing can encounter very different conditions during production cutover. Data volumes, integration traffic, processing time, permissions, and the final transaction delta can all expose weaknesses that were invisible in earlier rehearsals.
A practical cutover runbook should cover:
| Step | Cutover activity | What to confirm |
| 1. Freeze transactions | Stop new transactions in the legacy ERP at the agreed cutoff time and communicate the change to users. | No new transactions are being created in the legacy system after the cutoff. |
| 2. Pause legacy integrations | Suspend interfaces, scheduled jobs, and other processes that could continue writing to the legacy environment. | No automated process can create or modify records during the migration. |
| 3. Extract the final data delta | Capture transactions and data changes made since the last migration rehearsal or extraction. | The final extract covers the agreed period and passes basic completeness and integrity checks. |
| 4. Load data in sequence | Import configuration, master data, and open transactions according to the approved dependency sequence. | Each migration stage completes successfully, and exceptions are reviewed before proceeding. |
| 5. Reconcile critical totals | Compare financial and operational results between the legacy and target environments. | General ledger balances, receivables, payables, inventory, open orders, and other agreed measures reconcile within defined tolerances. |
| 6. Test end-to-end processes | Run representative business scenarios through the target ERP. | Critical processes such as order-to-cash, procure-to-pay, inventory movements, and financial posting complete as expected. |
| 7. Confirm access and integrations | Validate users, security roles, reports, interfaces, and connected applications. | Users have the appropriate access and dependent systems can exchange data with the target environment. |
| 8. Obtain go-live approval | Present migration results, exceptions, reconciliation reports, and test outcomes to the relevant stakeholders. | Finance, operations, IT, and the programme sponsor formally approve the transition. |
| 9. Retain the legacy environment | Place the legacy ERP into the agreed read-only or retention state. | Historical data remains accessible in accordance with business, audit, and retention requirements. |
| 10. Monitor early operations | Track transactions, integrations, user issues, and migration exceptions after go-live. | Issues are logged, prioritized, and resolved through an agreed hypercare process. |
can be performed in multiple iterations, with migration status tracked in a table; Microsoft also documents prerequisites, extension considerations, and performance planning for larger migrations.
The final migration should serve as the last rehearsal with production data, rather than the first test of whether the plan works.
Conclusion
The five things that break during ERP migration are rarely just data objects. They are data relationships, financial meaning, configuration dependencies, custom business logic, and operational continuity.
A disciplined migration makes each of these visible before go-live. Clean master data, reconciled balances, dependency-aware sequencing, a clear customization inventory, and repeated cutover rehearsals give finance, operations, IT, and program leaders a common basis for validation.
For organizations moving to F&O or Business Central, Microsoft’s migration tools are valuable, but they do not replace business ownership and validation. An experienced such as LevelShift can bring those disciplines together across data mapping, integration, testing, and cutover planning. The result is a migration that does more than preserve the past; it provides the organization with a cleaner foundation for future operations and growth.
FAQs
- What is the biggest risk in a legacy ERP migration?
Financial or operational data may appear correct even as important relationships, configurations, or business rules are lost. - Should all historical ERP data be migrated?
No. Decide which history is required for operations, reporting, audit, and compliance, and archive the remainder where appropriate. - How should master data be prepared?
Clean and standardize it before extraction, resolve duplicates, map legacy identifiers, and obtain business owners’ approval for critical records. - Why are open transactions important?
Open invoices, orders, balances, and inventory represent work that remains to be completed. Losing their context can disrupt business operations after go-live. - How many migration rehearsals should an organization perform?
There is no universal number. The key is to repeat the migration process until data reconciliation, cutover timing, integrations, permissions, and business validation have all been demonstrated under realistic conditions.