# Planning an AX 2012 to Dynamics 365 Finance and Operations upgrade

> Source: https://netray.co/erp-help/dynamics-ax2012-to-d365fo-upgrade-guide
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

Moving from AX 2012 to D365 F&SCM is a platform change, not a version bump: X++ customizations go through a code upgrade to the new extension/overlayering model, and data moves through a structured data migration, both coordinated as an Upgrade project in Lifecycle Services (LCS). Plan it as a project with its own testing cycle, not a routine patch.

## Kind

advanced

## System

dynamics

## Erp

Microsoft Dynamics AX 2012 / Dynamics 365 Finance and Operations

## Module

Upgrade / migration

## Query

AX 2012 to D365 finance and operations upgrade process

## Alternate Queries

- how to upgrade from Dynamics AX 2012 to D365
- AX 2012 code upgrade to D365FO steps
- AX 2012 data migration to D365 F&SCM

## Applies To

Dynamics AX 2012 R2/R3 moving to Dynamics 365 Finance and Operations (Finance, Supply Chain Management), on-premises or cloud target.

## Steps

### Run the upgrade at a high level

**Items:**

Create an Upgrade project in Lifecycle Services (LCS) and register the source AX 2012 environment and target D365FO environment against it.

Inventory existing customizations: identify what is layer-based (ISV, VAR, USR layers) versus core, and classify each as still needed, replaceable by standard D365FO functionality, or genuinely custom.

Run the code upgrade tooling against the AX 2012 codebase to convert layer-based customizations into the D365FO overlayering-free extension model; expect manual rework for anything that touched restricted or heavily refactored kernel areas.

Rebuild or replace ISV solutions with their D365FO-compatible equivalents rather than force-upgrading old binaries; many ISVs ship a dedicated D365FO version rather than a straight port.

Plan the data migration separately from code: map AX 2012 tables to D365FO data entities (many differ structurally), and use the Data management framework / Data Migration tooling with staged, validated loads rather than a single big-bang import.

Stand up a full test cycle (unit, integration, UAT with real business processes) against the upgraded environment before cutting over; treat this as equivalent in scope to a new implementation's test phase.

Sequence cutover around a defined data freeze window, run the final incremental data sync, and validate opening balances (GL, inventory, AR/AP) before go-live.

## Sections

### Why this is not a simple in-place upgrade

**Body:**

AX 2012 and D365 F&SCM run on different application platforms - D365FO moved to a model-driven, extension-based customization approach and a different deployment and data model. There is no single automated button that turns an AX 2012 environment into a D365FO one; Microsoft's tooling assists the code and data conversion, but architectural decisions (what to keep, what to rebuild as an extension, what to retire) require real analysis.

Because of this, most AX 2012 upgrades are scoped and estimated closer to a re-implementation with migration assistance than a technical patch, even though a meaningful amount of business logic and configuration can be carried forward.

### Code upgrade: what survives cleanly and what doesn't

**Body:**

Customizations that used standard extensibility points (event handlers, standard table/field extensions in later AX 2012 patterns) tend to convert more predictably than deep overlayering of kernel objects, which by design is no longer supported the same way in D365FO's extension model.

Heavily customized modules (pricing engines, custom workflow logic, bespoke integrations) usually need a design review during the upgrade rather than a mechanical conversion - this is where most upgrade project time and cost actually goes, not the tooling run itself.

### Data migration realities

**Body:**

Table structures changed between AX 2012 and D365FO in many modules (e.g. inventory dimensions, financial dimensions), so a straight table-to-table copy is not possible; migration goes through data entities designed to absorb the structural differences.

Historical transactional data (especially years of GL, inventory, and production history) is often only partially migrated by design - many upgrade projects bring forward open balances and a defined trailing window of detail, archiving the rest, to keep the migration and go-live testing manageable.

## Pitfalls

- Underestimating the effort as "just run the upgrade tool" instead of budgeting real analysis and rework time for customizations.
- Trying to force-migrate every historical transaction instead of agreeing an open-balance-plus-archive approach with the business early.
- Not engaging ISVs early enough to confirm whether a D365FO-compatible version of a bolt-on even exists.
- Skipping a full UAT cycle on the assumption that "it worked in AX 2012" is sufficient proof it works after the platform change.
- Leaving security role and workflow redesign until late - D365FO's role-based security model differs enough from AX 2012 that a straight carry-over rarely fits well.

## Ai Angle

SyteRay-style grounded agents (applied here to the AX/D365 codebase and data dictionary rather than SyteLine) can accelerate the inventory phase - scanning AX 2012 customizations layer by layer, flagging which touch deprecated APIs or restricted objects, and drafting a first-pass classification of keep versus rebuild versus retire, which is normally the slowest manual step in scoping the upgrade.

## Faq

### Is there still a supported automated in-place upgrade path from AX 2012 to D365FO?

**Answer:** Microsoft provides tooling (via LCS Upgrade projects) to assist code and data conversion, but it is an assisted, project-based migration, not a one-click in-place upgrade; expect a genuine project with analysis, rework, and testing phases.

### Can we keep our AX 2012 ISV modules as-is in D365FO?

**Answer:** Generally no - most ISV solutions need their own D365FO-compatible build using the extension model. Confirm with each ISV whether a D365FO version exists before assuming the upgrade will carry the module forward.

### How much historical data should we migrate?

**Answer:** Most projects migrate open balances and a limited trailing window of transaction detail, archiving the rest in a queryable read-only copy of AX 2012, since migrating every historical transaction significantly extends testing and go-live risk for limited business benefit.

### Do security roles carry over automatically?

**Answer:** No - D365FO's role-based security model is structured differently from AX 2012, so roles and duties typically need to be redesigned and re-tested rather than copied across.

## Search terms

AX 2012 to D365 upgrade, AX 2012 code upgrade, D365 finance operations migration, LCS upgrade project, AX 2012 data migration D365, AX 2012 customization upgrade, Dynamics AX to D365 reimplementation, AX 2012 D365 cutover plan

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json