This article includes insights from Kevin Howes II, Director ‑ AX/Finance & Operations at GraVoc.
Kevin helps organizations plan successful transitions from Dynamics AX to Dynamics 365. With hands‑on experience across AX 2009, AX 2012, and Dynamics 365 FSCM, Kevin leads clients through upgrade and reimplementation strategy and post–go‑live stabilization.
Most Dynamics AX users already know it’s time to move. Microsoft ended all mainstream and extended support for Dynamics AX 2009 and 2012, leaving businesses fully on the hook for securing and maintaining the legacy platform. Now, for businesses, the natural next step is researching what a migration to Dynamics 365 Finance & Supply Chain Management (FSCM) involves, and what tends to go wrong.
Having led several Dynamics AX to Dynamics 365 upgrades and reimplementations, we’ve seen the same challenges businesses face repeatedly. These include improperly migrated data, customizations that are difficult to rebuild because Dynamics 365 replaces Dynamics AX’s over-layering model with extensions, and not enough user training to drive adoption. In fact, a lot of the projects that land on our desk are ones that have already stalled over these problems, and nearly all of them could have been avoided with better upfront planning.
Here, we break down the most common Dynamics AX to Dynamics 365 migration challenges, and the questions you should be asking before your project begins.
New to this? Before you tackle these migration challenges, it helps to know whether an upgrade, reimplementation, or hybrid approach fits your business. Our Dynamics AX Migration Guide walks through all three options and how to choose. It's a good place to start if you're still weighing your move.
Migrating too much legacy data from Dynamics AX
After 10 or 15 years on Dynamics AX, businesses assume every historical transaction needs to make the jump to Dynamics 365. We always tell the clients we work with that bringing over decades of transactional history into a new environment adds cost, slows performance, and clutters the system you are trying to modernize.
- Overestimating historical data: Our best recommendation is that not all data needs to come over. Use the migration as an opportunity to start fresh and get rid of any bad data. A good approach is to migrate core master data and open transactions, then archive legacy transactional data for audit and compliance. For one of our manufacturing clients upgrading from Dynamics AX to Dynamics 365, we archived legacy transactional data for compliance while master data like customers, vendors, parts, BOMs, and routings was cleaned, validated, and migrated into Dynamics 365.
- Lack of data ownership going in: When no one owns the data, no one is accountable for its quality. Someone on the business side needs to own decisions about what's accurate and what stays.
- Duplicate and conflicting master data: Very often, we see systems with duplicate vendors, conflicting customer records, and part numbers that no longer agree. If you don't rationalize these before migrating, you carry the mess into your new Dynamics 365 system. This is why we build data cleansing and validation into the project up front rather than treating it as a go-live afterthought.
Trying to 'lift & shift' Dynamics AX customizations in Dynamics 365
This is where we see a lot of Dynamics AX migration projects stall. Businesses spent years building custom code in Dynamics AX, so the instinct is to rebuild all of it in Dynamics 365. But Dynamics AX and Dynamics 365 FSCM treat customizations differently, and many teams don’t understand the challenges of recreating custom code as extensions in the new ERP.
- Trying to bring all custom code forward: The goal shouldn't be to replicate Dynamics AX, it should be to modernize. When we planned the migration roadmap for our manufacturing client, cutting down customizations was one of the top priorities. Over 80% of their Dynamics AX 2009 customizations were eliminated or replaced with native Dynamics 365 capabilities, and lightweight extensions were handled with Power Platform tools instead of deep custom development.
- Not checking whether Dynamics 365 already covers the gap: Every customization should be evaluated against standard Dynamics 365 features before anyone writes code. Many legacy gaps have since been closed by Microsoft, and using native functionality means you benefit from future updates without the maintenance burden.
- Underestimating the effort to refactor to extensions: Dynamics AX's over-layering model doesn't carry into Dynamics 365, which uses an extensions model. Converting custom code to extensions is not as straightforward as it seems, and teams that don't scope it properly get surprised mid-project. This is one of the biggest reasons we recommend a code and customization review before committing to a timeline.
Not re-evaluating your third-party ISVs
Third-party ISV products are often overlooked until they break something.
- Dynamics AX ISVs may not exist or better options do: Some Dynamics AX add-ons were not rebuilt for Dynamics 365, and in other cases a Dynamics 365-native option is better. Every third-party dependency should be re-evaluated to see if it truly needs to be brought over.
- Functional overlap with Dynamics 365 standard: Businesses often keep paying for an ISV that duplicates something Dynamics 365 now does out of the box. A migration is the right time to audit that overlap and cut what you no longer need.
- Data model differences: ISVs store and structure data differently, which complicates mapping during migration. Where a third-party product remains essential, it typically needs a secure, rebuilt API-based integration.
Skipping testing & end-to-end validation
Because a migration changes so much, most teams tend to cut back on testing when timelines stretch.
- Insufficient regression testing: The sheer volume of changes across data, customizations, and integrations means small issues can easily slip under the cracks. Prioritize iterative testing, mock migrations, and automated reconciliation dashboards that compare source-versus-target record counts and key financial totals, so nothing slips through.
- Not validating processes end to end: Confirming a single screen works isn't the same as confirming a full order-to-cash or procure-to-pay process works with actual business data. Make sure end-users verify migrated data by using it for transactions before sign-off.
Underestimating change management & user training
The most underestimated challenge is user adoption.
- Expecting Dynamics AX behavior in a Dynamics 365 world: Dynamics 365 has a modern interface and different workflows, and users accustomed to Dynamics AX often expect it to behave the same way. Make it clear to users that this is a new system, not a refurbished version of Dynamics AX.
- Underinvesting in training: Give your teams role-specific, hands-on training so they get comfortable with the new interface and workflows in Dynamics 365. When training gets shortchanged, users default to manual workarounds or try to force old Dynamics AX habits into a new system, and that's one way to lose your ROI.
Key takeaways
Migrating from Dynamics AX to Dynamics 365 is mostly derailed by insufficient planning around data, customizations, ISVs, testing, and adoption.
Here's what to keep in mind:
- Don't migrate all your historical data. Move core master data and open transactions, and archive the rest for reporting and compliance.
- Clean up duplicate and conflicting data before you migrate, and assign clear data ownership going in.
- You can't lift and shift customizations. Much of what Dynamics AX needed custom code for is now standard in Dynamics 365, and any custom code has to be refactored to the extensions model in Dynamics 365.
- Re-evaluate every Dynamics AX ISV. Some won't exist in Dynamics 365, and others are replaced by better native functionality.
- Don't skip regression and end-to-end testing.
- Invest in training and change management. Adoption is ultimately what protects your ROI.
Questions to consider while planning your move:
- Are you trying to replicate Dynamics AX or transform the business?
- What percentage of your current system is custom vs. standard?
- How clean and trusted is your data today?
- Do you want to adopt Microsoft's roadmap or maintain your legacy design?
- What ISVs are truly differentiators vs. just filling historical gaps?
- How important is speed vs. long-term scalability?
- Do you need full historical data, or just operational continuity?
The bottom line: Get clear on your data, customizations, ISVs, testing, and adoption plan before you start, and you'll avoid the most common, and ultimately costly, migration challenges.
