10 risks to plan for when migrating from Dynamics AX or SAP ECC to Dynamics 365

The ten risks that most often derail a move from Dynamics AX or SAP ECC to Dynamics 365 are choosing the wrong migration route, carrying old custom code across unexamined, underestimating the data model translation, moving poor quality data and the wrong amount of history, rebuilding integrations on retired patterns, forgetting reports and third party add ons, misjudging the licence model, running two systems for longer than planned, going live without a rehearsed cutover, and treating user adoption as a training session at the end. None of them is caused by Dynamics 365 itself. Each one starts in the source system, in decisions made ten or fifteen years ago, and each one becomes expensive only when it is discovered late.

That is why the order of work matters more than the size of the budget. A company that first establishes what its AX or ECC landscape actually does can price these risks honestly; a company that starts with configuration pays for the same problems twice, once to find them and once to fix them under deadline pressure. For each risk, this guide gives the early warning sign a steering committee can watch and the mitigation that works, and shows where it differs for AX and for SAP ECC.

Key facts at a glance:

• AX support. Extended support for Dynamics AX 2009, 2012 and 2012 R2 ended in April 2022, and for AX 2012 R3 in January 2023, according to Microsoft's lifecycle notice.
• SAP deadline. Standard maintenance for SAP ECC ends at the end of 2027, with paid extended maintenance available until the end of 2030.
• Route constraint. A technical upgrade to Dynamics 365 is only possible from AX 2012 R2 or R3; AX 2009 and SAP ECC always need a new implementation with data migration.
• Code. Dynamics 365 does not accept over layered X++ or ABAP modifications, so every customisation is refactored, replaced by standard functionality or retired.
• Timeline. Most migrations take six to eighteen months, set by code, data and integrations rather than by configuration.
• First step. A fixed price environment assessment of three to five weeks settles the route, cost and main risks before any licence is bought.

‍

Why AX and SAP ECC migrations fail in different places

A company leaving Dynamics AX and a company leaving SAP ECC are heading for the same platform, but they start from very different distances. AX is the direct ancestor of Dynamics 365 Finance and Supply Chain Management, so much of the vocabulary, the data structures and the process logic will look familiar. That familiarity is itself a risk: teams assume the move is an upgrade and underestimate how much of fifteen years of over layered X++ code cannot come across, how many integrations rely on the retired Application Integration Framework, and how different the browser based system feels to users who know the old Windows client. The danger in AX migrations is complacency.

SAP ECC carries the opposite danger. Nothing is familiar, so the scale of the change is visible from the start, but the effort is spread across areas that are hard to estimate: rebuilding years of ABAP custom code, translating the SAP data model into a different one, and keeping SAP and Dynamics 365 running side by side for months. Commercial timing adds pressure. The Register reported that 68 percent of members of the German speaking SAP user group DSAG were still running ECC or Business Suite, which means migration capacity will be contested as 2027 approaches. The ten risks below apply to both journeys, but their weight differs, and the first table shows where.

‍

The ten risks in detail

1. Choosing the wrong migration route

The first decision sets the cost of everything that follows. For AX 2012 R2 or R3 with moderate customisation, a technical upgrade converts the whole database and keeps the full transaction history. For AX 2009, heavily modified AX 2012 and every SAP ECC system, the route is a new implementation with migration of master data, balances and open items. The risk is choosing on habit or on a partner's preference: an upgrade that drags fifteen years of technical debt into the new system, or a new implementation that throws away history the business still needs. Be wary of any proposal that names a route before analysing your code and data. The mitigation is an environment assessment on a copy of your database that compares both routes on cost, time, risk and history before the contract is signed. ANEGIS settles this with a fixed price environment assessment of three to five weeks for AX, and a free comparative analysis for SAP ECC, both completed before any licence is bought.

2. Carrying old custom code across unexamined

Dynamics 365 does not support over layering, so modifications that changed standard AX classes cannot move as they are, and ABAP code has no path into Dynamics 365 at all. The risk is treating every customisation as a requirement. In most mature systems a large share of custom code is no longer used, duplicates functions that today's standard covers, or exists only to work around a process that could be simplified. The warning sign is an estimate based on the number of objects rather than on their purpose. The mitigation is to classify each modification as refactor into an extension, replace with standard or an AppSource solution, or retire, and to ask the business owner, not only the developer, whether it is still needed. ANEGIS classifies every modification as refactor into an extension, replace with standard or an AppSource solution, or retire, and keeps the refactored code under version control.

3. Underestimating the data model translation

On an AX upgrade the database is converted by Microsoft's tools. In every other case, and always for SAP, the business has to decide how its old structures map to new ones. SAP company codes become legal entities, profit and cost centres become financial dimensions, and material masters split into products and released products. The risk is assigning this work to technical staff alone, when most of the decisions are about how finance and operations want to report in future. The warning sign is a mapping document with many open questions three months into the project. The mitigation is to make the chart of accounts, dimensions and product structure early design decisions, owned by named finance and operations leads, and frozen before configuration begins. ANEGIS maps the SAP data model to the Dynamics 365 model with profiling and cleansing up front, and reconciles balances at every stage rather than only at the end.

4. Moving poor data and the wrong amount of history

Old systems hold duplicate customers, inactive vendors, inconsistent units and open items that nobody has reconciled for years. Moving them unchanged gives the new system a bad start and undermines trust in its reports from the first week. Equally costly is migrating a decade of transactions when balances, open items and audit access would do. The warning sign is a first trial load with thousands of errors, or no trial load at all by the midpoint of the project. The mitigation is iterative migration through several environments, with balances, counters and key reports reconciled against the old system after every run. History that does not need to live in the new ERP can move to an archive or an analytical layer, where it remains available for reporting and audit. ANEGIS runs the migration several times through development, test and production environments, reconciling balances after each run, and moves older history to an archive or a Microsoft Fabric analytical layer.

5. Rebuilding integrations on retired patterns

Most AX 2012 integrations were built on the Application Integration Framework, direct database access or flat files, and most ECC landscapes rely on IDocs and remote function calls. None of these carry over. The risk is rebuilding each interface quickly in whatever way works, producing a new mesh of point to point links that breaks with the next update. The warning sign is an integration list without owners, volumes or error handling, or interfaces still being discovered during testing. The mitigation is a complete inventory at the start, a supported pattern for each interface, such as OData, business events, the Data Management Framework or Dataverse, and, where many systems are connected, a central integration layer such as Azure Integration Services. ANEGIS inventories every integration and rebuilds it on OData, business events, the Data Management Framework or Azure Integration Services, tested before the dry run cutover.

6. Forgetting reports and third party add ons

Reports and add ons are easy to overlook because they sit around the ERP rather than inside it. An AX system may carry hundreds of SSRS reports and several independent software vendor solutions; an ECC landscape often feeds a business warehouse that finance depends on every month. The risk is finding, a few weeks before go live, that a regulatory report, a pricing add on or the management pack has no equivalent in the new system. The warning sign is a scope document that lists processes but no reports. The mitigation is to treat every report and add on as a decision: keep operational documents in the ERP, move analytical reporting to Power BI on shared data, check whether each vendor has a Dynamics 365 version, and retire what nobody uses. ANEGIS keeps SSRS only for operational documents, moves analytics to Power BI on data shared through Fabric Link, and checks each add on for a Dynamics 365 version, a standard replacement or retirement.

7. Misjudging the licence model

Moving from AX perpetual licences with an enhancement plan, or from SAP licences with annual maintenance, to a per user subscription changes how cost is counted. The risk runs both ways: buying full licences for users who only approve or read, or underestimating the number of full users once roles are mapped properly. Since January 2026 Microsoft has enforced that assigned licences match the privileges each user holds, so a careless security design now leads to blocked access as well as higher cost. The warning sign is a licence quote produced before user roles have been analysed. The mitigation is to map every role onto the right licence type during the assessment, including lighter Team Members and Activity licences, and to check whether Microsoft migration programmes for customers with an active AX enhancement plan apply. ANEGIS maps existing roles to Dynamics 365 licence types during the assessment, including lighter Team Members and Activity licences, and checks which Microsoft migration programmes apply.

8. Running two systems for longer than planned

Every migration involves a period when the old and new systems coexist, either because the move is staged by entity or because the first go live slips. The risk is that this period stretches. For AX customers it means paying an enhancement plan of roughly 16 percent of licence value a year for a system that will never gain a feature. For ECC customers after 2027 it means SAP's extended maintenance premium on top of existing fees. The warning sign is a plan without firm decommissioning dates, or a staged rollout where later waves have no budget. The mitigation is to define coexistence deliberately: which entities move when, how master data and consolidation flow between systems in the meantime, and the date each legacy component is switched off. ANEGIS phases migrations entity by entity or country by country, and for SAP supports a two tier model in which head office stays on SAP while subsidiaries move first.

9. Going live without a rehearsed cutover

The cutover weekend compresses every earlier risk into a few days: final data loads, balance checks, integration switches and the first transactions in the new system. Without a rehearsal, timings are guesses and failures surface at the worst moment. The warning sign is a cutover plan written as a list of tasks without timings, owners and go or no go criteria. The mitigation is a dry run at production data volume a few weeks before launch, in which every step is timed and every deviation recorded, followed by a go live with a fallback plan that keeps the old system ready to return to until balances and integrations are confirmed. With a rehearsal behind it, the launch becomes a repeat rather than a premiere. ANEGIS replays the whole launch at production volume weeks in advance, times every step, and keeps AX ready to return to until balances, counters and integrations are confirmed.

10. Treating adoption as a training session at the end

Users who have worked in AX for a decade know its Windows client by heart; users who grew up on SAP GUI know its transaction codes. Dynamics 365 runs in the browser, with a different layout and new ways of working, and the change feels larger to users than it looks to IT. The risk is leaving adoption to a week of classroom training before go live, after which people return to spreadsheets. The warning sign is key users who are too busy to attend design workshops or test cycles. The mitigation is to involve key users from the first workshop, let them test in every migration iteration, train end users by role on their own data, and plan several weeks of close support after launch. ANEGIS involves key users in deciding which customisations stay, trains every role on the client's own data, and provides hypercare of typically six to eight weeks after launch.

‍

How to read these risks as a steering committee

Not every risk deserves the same attention at the same time, and a steering committee that tries to watch all ten equally usually ends up watching none of them well. The useful distinction is between risks that are cheap to remove early and expensive to fix late, such as the migration route, custom code and the data model, and risks that need continuous management until the end, such as data quality, integrations and parallel running. The first group should be closed by decisions in the opening weeks; the second group should appear on every steering committee agenda with a named owner and a measurable indicator, for example the error rate of the latest trial load or the number of interfaces still untested.

Ownership matters as much as scoring. Risks owned by the partner alone tend to be reported as green until they turn red, while risks owned jointly by a business lead and the partner surface earlier, because the business sees the consequences first. The register below shows how the main risks typically score for a midsize migration and who should own each one. The scores are indicative and should be replaced by your own assessment once the environment has been analysed.

Three questions help a steering committee test whether these risks are under control at any point in the programme:

• Do we know what we are moving? A current inventory of code, integrations, reports and add ons, each with a decision.
• Have we proven it works at volume? Reconciled trial loads and a timed cutover rehearsal, not only functional tests.
• Do we know when the old system ends? A dated decommissioning plan and a budget for every remaining wave.

‍

How ANEGIS reduces migration risk

ANEGIS is a Microsoft Solutions Partner for Business Applications that has worked on the Dynamics platform since the Axapta era, with teams in Poland and the UK. Every Dynamics AX to Dynamics 365 migration starts with a fixed price environment assessment of three to five weeks, carried out on a copy of the AX database without a Dynamics 365 licence, which compares an upgrade with a new implementation and ends with a customisation map, a phased plan, a risk register and a cost estimate. Data moves iteratively with balance reconciliation after every run, the cutover is rehearsed at production volume, and AX stays ready to return to until the launch is confirmed. For SAP ECC migrations, ANEGIS offers a comparative analysis before any licence decision, phased delivery and coexistence with SAP, and moves ECC history into a Microsoft Fabric analytical layer for audit and reporting.

The approach is visible in completed projects. For BUUK Infrastructure, a UK provider of last mile utility networks, ANEGIS moved an on premises Dynamics AX system to Dynamics 365 in the cloud after an analysis phase from November 2021 to May 2022 and a 14 month implementation, going live on 3 July 2023. For a global advertising holding, it upgraded Dynamics AX 2009 to Dynamics 365 while keeping finance processes in London and New York compliant with SOX. ANEGIS also takes over migrations that have stalled with other partners.

Plan the migration before it plans you

If you are leaving Dynamics AX or SAP ECC and want the route, cost and main risks on paper before committing a budget, Contact ANEGIS to book a free consultation or a fixed price environment assessment.

‍