Data migration from AX 2012: keeping historical balances intact

The question every finance lead asks about an AX 2012 upgrade is “will our numbers still tie out?” The answer is yes, if the migration is run as a repeatable process with reconciliation at each run, and if the decision about how much history to bring is made early and deliberately. This article covers both.

Decide the history scope first

There are three common positions, and each is defensible:

  1. Balances only. Opening balances per account, dimension and subledger as at the cutover date, plus open items. Simplest and fastest. History stays in a read-only AX 2012 environment or a reporting database.
  2. Balances plus recent detail. Opening balances, plus two or three years of posted transactions for comparatives and audit trail. The usual compromise.
  3. Full history. Every transaction since go-live of AX. Longest migration, largest data volume, and rarely needed in the live system. Reporting tools can read history from the old database.

The decision shapes the plan, the duration and the testing. Make it in the planning phase, with the auditors’ requirements written down.

What gets migrated, in order

GroupExamplesReconciled against
ConfigurationChart of accounts, dimensions, posting profiles, number sequencesConfiguration checklist
Master dataCustomers, vendors, items, employees, bank accounts, fixed assetsRecord counts and key field samples
Open transactionsOpen customer and vendor invoices, open purchase and sales orders, on-hand inventoryAged balances, inventory value by site and warehouse
BalancesTrial balance by account and dimension at cutover, fixed asset net book valuesAX 2012 trial balance to the cent
History (if in scope)Posted ledger, subledger and inventory transactions for the chosen periodPeriod-end balances per month

Run it more than once

A migration run is not a weekend event. The first trial load finds mapping issues: a dimension that does not exist, a vendor group with no posting profile, an item with a costing method that changed. Each issue is fixed at the source or in the mapping, and the run is repeated. By the third or fourth run the reconciliation reports show zero differences, and the final run on cutover weekend is a rehearsal that has already succeeded three times.

Reconciliation reports that finance signs

  • Trial balance comparison: AX 2012 vs Dynamics 365, by account and dimension, difference column
  • Customer and vendor aged balances, totals and by customer
  • Inventory value by site, warehouse and item group
  • Fixed asset register: cost, accumulated depreciation, net book value
  • Open order counts and values

Each report is signed by the finance owner after each run. The signatures are the evidence that the system is ready.

Common causes of differences

  • Inventory costing: a different closing or recalculation state between the two systems on the comparison date
  • Rounding on foreign currency balances revalued at different rates
  • Dimension defaults applied on import that did not exist on the source transaction
  • Transactions posted in AX 2012 after the extract was taken

A migration run, step by step

  1. Extract from AX 2012 at a known point in time, with the ledger closed for the period being compared
  2. Transform through the agreed mappings: chart of accounts, dimensions, item and customer groups, posting profiles
  3. Load into a Dynamics 365 sandbox using data entities, in dependency order
  4. Reconcile with the standard reports listed above, and record every difference with a cause
  5. Fix at source or in the mapping, never by hand in the target
  6. Repeat until the reports show zero differences, then sign

The rule in step five matters. A difference corrected by typing in the target system reappears at the next run. A difference fixed in the mapping is gone for good.

Dimensions deserve their own paragraph

AX 2012 dimension structures and Dynamics 365 financial dimensions are similar but not identical. Decide early whether the dimension set stays the same, is simplified, or is extended. Every historical transaction carries dimension values, so a change in structure is a mapping on millions of rows. Agree it with finance, document it, and test it on the first trial run, not the last.

Cutover weekend, when it is done right

By cutover, the migration has run three or four times with signed reconciliation reports. The weekend plan is a checklist: freeze AX 2012, take the final extract, run the migration, run the reconciliation reports, finance signs, users are switched to Dynamics 365. Rollback criteria are agreed in advance: if a report does not tie out and the cause is not found by a set hour, the switch is postponed and AX 2012 is unfrozen. The plan has rarely been needed when the trial runs were done properly, which is the point of doing them.

Need your balances to tie out on the first day? See the upgrade service or book a consultation.

Frequently asked

Do we have to bring all our history into Dynamics 365?

No. Many organisations migrate balances plus a few years of detail and keep AX 2012 read-only for older history. Auditors generally accept this when it is documented.

How many migration runs are normal?

Three or four trial runs before the final cutover run. Each run has reconciliation reports; the goal is a final run with no surprises.

Who signs off the migration?

The finance owner, on the reconciliation reports after each run. The project team prepares them; finance approves them.