What happens to your data when you migrate from Dynamics AX?

When you migrate from Dynamics AX, your data is extracted from the legacy system, transformed to match the structure of your new platform, and loaded into the target environment. Not all data makes the journey. Decisions about what to migrate, cleanse, or archive are made before the migration begins, and those decisions directly affect how useful your new system is from day one. This article walks through what actually happens to your data at each stage, where the risks sit, and how to make sure what arrives in your new system is accurate and complete.

What actually happens to your data during a Dynamics AX migration?

During a Dynamics AX migration, your data goes through three core phases: extraction from AX, transformation to match the data model of your target system, and loading into the new environment. Each phase involves technical processing, data mapping decisions, and quality checks that determine whether records arrive intact, correctly structured, and usable.

The extraction phase pulls data from your AX database, which may span multiple modules including finance, supply chain, inventory, and HR. Because AX uses its own data model and table structures, raw data cannot simply be copied across. It needs to be mapped to the fields and formats of the new system, whether that is Dynamics 365 Finance and Supply Chain, SAP, or another ERP platform.

During transformation, records are cleansed, deduplicated, and reformatted. This is where inconsistencies surface. Duplicate vendor records, incomplete customer data, and outdated cost centres all become visible at this stage. Addressing them before loading protects the integrity of your new system rather than importing problems you already had.

The loading phase moves the cleansed, mapped data into the target environment. This typically happens in multiple iterations, starting with a full test load, followed by refinement cycles, and finishing with the final production load at cutover. Each iteration is an opportunity to catch errors before they affect live operations. A structured data migration management approach treats these iterations as checkpoints, not just technical runs.

Which data gets migrated and which gets left behind?

Not all Dynamics AX data is worth migrating. The general approach is to migrate master data and open transactional data into the new system, while historical transactions are either archived or kept accessible in a read-only AX environment for reference and compliance purposes.

Typically migrated:

Master data: customers, vendors, items, chart of accounts, cost centres
Open transactions: open purchase orders, sales orders, invoices, and work orders
Balances: financial balances, inventory quantities, and outstanding amounts as of the cutover date
Configuration data: payment terms, tax codes, warehouse structures, and other setup records

Typically left behind or archived:

Closed historical transactions (completed orders, paid invoices, settled entries)
Legacy data that has no equivalent field or structure in the new system
Duplicate or inactive records identified during cleansing
Data that fails validation and cannot be corrected before go-live

The decision on what to migrate is not purely technical. Business and legal teams need to confirm retention requirements, and finance needs to agree on the cutover date balances. These conversations are part of the As-Is and To-Be analysis that shapes the migration scope. Getting alignment early avoids rework later.

What are the biggest risks to data integrity during an AX migration?

The biggest risks to data integrity during a Dynamics AX migration are poor data quality in the source system, incomplete field mapping between AX and the target platform, and insufficient testing before the production load. Any one of these can result in records that load incorrectly, fail validation, or cause processing errors after go-live.

Dynamics AX has been in use at many organisations for over a decade. That means the data it holds has accumulated inconsistencies over time: fields populated differently by different teams, records that were never closed properly, and configuration data that no longer reflects how the business actually operates. Migrating this data without cleansing it first transfers the problem rather than solving it.

Field mapping is another common source of errors. AX data structures do not map one-to-one to Dynamics 365 or other modern ERP platforms. Where a direct equivalent does not exist, decisions must be made about how to handle the gap. If those decisions are not documented and tested, the transformation logic breaks down in ways that are difficult to trace after the fact.

Finally, organisations that underinvest in testing cycles often discover data errors after go-live, when the cost of correction is highest. Multiple test loads with structured validation against business rules are not optional steps. They are what separates a controlled migration from a reactive one. We use rigorous testing procedures specifically to catch these issues before they reach production, not after.

How do you validate that migrated data is correct before go-live?

You validate migrated data by running structured reconciliation checks that compare record counts, financial balances, and key field values between the source AX system and the target environment after each test load. Validation is not a single check at the end. It runs iteratively across multiple migration cycles before the final production load.

Effective validation covers several layers:

Volume checks: Confirm that the number of records loaded matches what was extracted. Missing records are flagged immediately.
Balance reconciliation: Financial balances in the new system must match agreed cutover figures from AX. Any discrepancy needs a root cause before go-live proceeds.
Field-level checks: Key fields such as payment terms, tax codes, and unit of measure are verified against source values to confirm mapping was applied correctly.
Business process testing: Users run real transactions in the new system using migrated data, such as processing an open order or posting a journal entry, to confirm the data behaves correctly in context.
Exception reporting: Records that failed transformation rules are reviewed, corrected where possible, and either re-migrated or formally excluded with sign-off.

The people doing this validation matter as much as the process. Business users who know the data need to be involved, not just technical teams. A record may load without errors but still be wrong in a way that only someone from finance or supply chain would recognise. You can review our full range of services to see how test management and data migration work together in a structured programme.

What happens to your Dynamics AX data after the migration is complete?

After the migration is complete, your Dynamics AX data typically remains accessible in the legacy system for a defined period, either as a read-only archive or through a decommissioning process that preserves records for audit and compliance purposes. Your live data now lives in the new system, but AX is not immediately switched off.

Most organisations keep AX available in read-only mode for three to twelve months after go-live. This gives finance, legal, and operations teams time to retrieve historical records, respond to audits, and resolve any discrepancies that surface in the new system. The exact retention period depends on regulatory requirements in your industry and geography.

Over time, AX is decommissioned. Before that happens, a formal data archiving process should capture any historical records that need long-term retention. These are typically stored in a data warehouse, a compliance archive, or a structured export format that can be retrieved without maintaining the full AX infrastructure.

The period immediately after go-live also requires close attention to the data that is now live in the new system. Errors that were not caught during validation tend to surface in the first weeks of operation, when users encounter records that do not behave as expected. Hypercare support during this window allows issues to be resolved quickly before they affect operations or reporting.

How Optinus helps with Dynamics AX data migration

We manage Dynamics AX data migrations end-to-end, from the initial As-Is analysis of your current data structures through to post-go-live hypercare. Our approach is built around preventing data loss and errors, not reacting to them after the fact.

As-Is and To-Be analysis of your AX data model to define scope, identify gaps, and agree migration rules before any technical work begins
Data cleansing and transformation to resolve quality issues in the source system before they reach your new platform
Rigorous testing cycles with volume checks, balance reconciliation, and business process validation across multiple iterations
Cutover planning and execution to manage the final production load with minimal downtime and full operational continuity
Hypercare and aftercare to support your team in the weeks after go-live, when data issues are most likely to surface

Our consultants have worked on real ERP migrations at leading multinationals, which means we know where Dynamics AX migrations break down and how to prevent them. If you are planning a migration or want to understand what it involves for your organisation, get in touch with our team or learn more about what we do.

home|

blog|