If you’re still using Microsoft Dynamics AX 2012, you’re not alone, but time’s ticking. Mainstream support for Microsoft Dynamics AX 2012 R3 ended in October 2021, and extended support ended in January 2023. This means no more security fixes, no compliance fixes, and a potential IT liability.
No better time is coming; it’s the time you get Dynamics 365. The point to question is that most businesses start this journey with a misconception. They’re approaching the implementation of Dynamics 365 Finance and Operations as an upgrade; well, it is a Dynamics 365 upgrade, but think of it as a transformation. It’s not the companies that don’t understand the technology that are going to get into trouble; it’s those that don’t understand what they’re getting into.
This is not a “10 steps to success” kind of checklist. In this blog, we are going to tell you the truth, including the things that regularly tank schedules and budgets, and the choices that can make or break your implementation, turning it from a success story to a case study.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Understand Your Current Process and Familiarise Yourself with the D365 Upgrade Journey
AX 2012 runs on-premises, whereas Dynamics 365 Finance and Operations (now Dynamics 365 Finance and Dynamics 365 Supply Chain Management) is in the cloud and SaaS. You’re not upgrading a system. You’re changing your operating model.
This is critical in how you plan, budget, and staff for the change. Microsoft’s own guidance states there’s no in-place upgrade; you are migrating data and reimplementing. What that means practically:
- Your AX 2012 customisations do not get imported. They need to be tested, rebuilt or decommissioned.
- Your data needs to be scrubbed, reconciled, and verified, not just imported.
- Your people need to be retrained, not just oriented.
- Your 3rd-party integrations ( payroll , CRM , eCommerce, banking) need to be re-developed.
The Dynamics 365 Upgrade Checklist: Phase by Phase
Phase 1: Business Case & Scope Definition
Before the technology kicks in, you will need to know why and what to expect.
How to start?
- Map the processes that you are changing, not just the modules.
- Understand which customisations in AX 2012 are important.
- Estimate the complete cost; the license cost is not everything. This should include implementation, data conversions, training, and change management.
- Confirm your Microsoft licensing model. Dynamics 365 Finance and Operations has a user-based subscription model rather than a perpetual licence like AX 2012. In Australia, this is the move from CapEx to OpEx, and it has tax and cash flow consequences, so you should talk to your CFO.
Where would you go wrong? Companies scope the project based on the current functionality of AX 2012, not what the company needs. They try to recreate a broken system (in a more costly environment).
Phase 2: Discovery and Gap Analysis
This is where most projects get it wrong. A good gap analysis report will answer: what do you have in your AX 2012 system, and what is available in Dynamics 365 Finance and Operations?
What do you need to do?
- Start with Inventory customisations. In most AX 2012 deployments, 30-60% of customisations are there due to functionality gaps that are now available in the Dynamics 365 upgrade. Turn these off before migration.
- Understand how your current chart of accounts, dimensions, and legal entity structure will fit in the Dynamics 365 model. This is not always simple and may require a finance team leader to be engaged from the start.
- Assess your integration environment. Payroll in most Australian businesses is not integrated with their ERP (such as Chris21, Micropay, or ADP). If you're expecting to create a payroll implementation checklist for this project, consider it a separate project byline, not something to be tackled as an afterthought.
- Evaluate data quality. Legacy ERPs are littered with years of data junk: duplicate suppliers, orphaned transactions, and inconsistent accounting codes. Importing poor-quality data into Dynamics 365 doesn't help; it means you start with a bad system.
What we are going to break to you is not in most articles: The gap analysis is not a technical study; it can uncover political problems, department heads who’ve become used to their workarounds, teams who don’t want their processes formalised, and finance teams who’ve built elaborate Excel connections that span the enterprise. These are the real risks.
Phase 3: Environment Build and Architecture
Dynamics 365 Finance and Operations is hosted in Microsoft Azure. You’ll need to make architecture decisions that will impact your system throughout its lifetime.
There are certain decisions you need to make:
- Decide how to deploy. Microsoft provides a cloud-hosted environment for development and testing, and production will run on Microsoft-managed infrastructure. Know your deployment before you start.
- Decide how often you will release. Microsoft has two major updates a year (this is known as a "wave"). You can't opt out of the new version, as you could with AX 2012. Work with your implementation partner to plan accordingly.
- Create your Lifecycle Services (LCS) project. This is Microsoft's deployment portal for Dynamics 365. It is used to manage deployments, upgrades, and support calls.
- Think about environment strategy: Number of sandbox environments you require i.e., development, UAT, and production, preferably a separate training environment from UAT.
Australian decision point: Data sovereignty is important. Ask your D365 implementation partner to ensure your Dynamics 365 tenant is hosted in Microsoft’s Australian data centres (Australia East / Australia Southeast in Azure). It’s a must for regulated industries like financial services, government, and healthcare.
Phase 4: Plan for Data Migration
Data migration is the most common implementation failure, not because of the wrong tools, but because of poor planning.
What do you need to do?
- Take the time to use the Microsoft-provided Data Migration Framework (DMF) and the data entities of Dynamics 365. Know what types of data are supported by an entity.
- Migration of open transactions and master data is a priority. Closed transactions (paid invoices, journals) can often be archived and, therefore, drastically simplify your project.
- Determine your cutover data plan: 3 years? 7 years? You need to be able to access 5 years of financial records for Australian tax purposes, but that doesn't necessarily mean in your ERP.
- Allow for at least two full test migrations. The first one will uncover issues. The second run checks your corrections. Not doing a mock run will haunt you.
So there’s a myth: Many companies think that, since the systems are both from Microsoft, the data migration is largely automatic. Well, it is not. AX 2012 and Dynamics 365 data models differ significantly, and so require extensive mapping and transformation to migrate virtually everything.
Phase 5: Customisation and Development
This phase is where you recreate anything that’s not included with Dynamics 365.
What do you need to do?
- Custom Development in Dynamics 365 Finance and Operations is done in X++ (the same language as used in AX 2012, but the system is very different). If you've developed X++ code in AX 2012, you'll need to learn new development patterns.
- Overlayering is no longer supported in Dynamics 365; use extensions, which means you can apply updates without breaking your code.
- Justify all your custom objects in documentation. If you can't explain why you need a customisation, you don't.
- Use Logic Apps, Azure Service Bus, or the Dynamics 365 data connector framework, not direct database queries. You could do that with AX 2012, but not Dynamics 365.
Phase 6: Testing
Testing is essential for a Dynamics 365 Finance and Operations implementation, and it cannot be rushed in the last two weeks.
How can you do it?
- Create a test plan that covers unit testing, system integration testing (SIT), user acceptance testing (UAT), and performance testing.
- Leverage Microsoft's Regression Suite Automation Tool (RSAT) to do regression testing. This is especially important for the update process; you want to validate each Microsoft update.
- Include end users in UAT, not IT impersonating end users. End users will identify problems that IT won't.
- Payroll Implementation checklist: Thoroughly test your payroll integration. Post-go-live payroll bugs are not just bugs; they affect staff salaries, run the risk of breaches of the Fair Work Act, and undermine staff confidence.
Phase 7: Training and Change Management
This is the area that most commonly receives the shortest funding in ERP projects, and it’s the phase that defines whether the system will be adopted or not.
What to do?
- Don't go for vendor training. Dynamics 365 Finance and Operations is a big system; teach your staff the processes and features they will be using, not everything.
- Create champion users (super users) in each division. These individuals will be your go-to technical support after go-live.
- Get your teams ready for the UX change. Dynamics 365 Finance and Operations uses a modern web-based user interface, compared to a Windows client for AX 2012. It's a substantial change for people who've been using AX 2012 for 10+ years.
- Update your SOPs for the new system.
Phase 8: Go-Live
Go-live is the phase where most problems are detected.
How can you detect them?
- Create a cutover plan with minute-level detail. What, who, when and how.
- Stop transactions in AX 2012 at a certain point in time. You can't migrate data when there are still postings going on in the old system.
- Have go/no-go criteria in place for cutover week. Understand what issues should be blockers and which issues can be fixed post go-live.
- Provide hypercare support for at least 4-6 weeks. The first month-end close in the new system will identify issues not identified in UAT.
Hard Truth About Upgrading to Microsoft Dynamics 365
1. The partner matters more than the product.
There are not many people in Australia with D365 F&O experience. 50 Business Central go-lives aren’t included. Ask about Finance and Operations go-lives, Australian reference customers, and turnover.
2. Forced upgrades are a serious thing.
Unlike AX 2012, you can’t stay on a version. Microsoft delivers updates twice a year, and they’re mandatory. This is great for security and new functionality, but you must have a process to test each update. Many companies don’t plan for this, and it causes panic.
3. Finance will be the most affected.
D365 AP workflows, month-end close, fixed assets, they’re not the same as they seem. If the finance team hasn’t been involved in implementation, they will want to revert. Don’t wait for UAT to get your finance lead involved.
4. "We'll fix the data later" never happens.
Every team says it, but no team does it. Cleanse before go-live, there’s no choice
How to Know if You're Ready to Begin?
Ask yourself these questions:
- Have you got executive support? Not just sign-offs, but involvement from a C-level or GM sponsor who will be involved in decision-making.
- Have you allocated a realistic budget? A good rule of thumb for mid-market Australian businesses (50-500 users) is: between $500K and a few million AUD for implementation. If you’re budgeting just the software licensing cost, you’re off the mark.
- Do you have staff to spare? You won’t be able to implement Dynamics 365 Finance and Operations while your team is doing other work. Business and IT resources will need to be set aside.
- Do you have a qualified Microsoft Dynamics 365 implementation partner? Ask for references from Australian customers with similar complexity and interview these clients away from the partner.
- Have you thought about the time between go-live and stabilisation? The first 3-6 months after go-live are more challenging than the project. And productivity will likely decline before it rises.
If you have “yes” for all the above, you’re ready. If not, take this time to prepare; don’t start a project that you can’t finish.
Final Thought
This is not your average upgrade; it’s a critical technology investment that will shape your business for years to come. The companies that succeed take a pragmatic approach: they know the technology is as good as the people that implement it, that the human side is just as important as the tech side, and that 90% of the destiny is written before the code. Do the gap analysis first, clean up your data, select your partner wisely and build your business case on realistic numbers. If you do that, Dynamics 365 will be a true competitive advantage.
FAQs
No. There is no direct upgrade path from AX 2012 to Dynamics 365; it’s a reimplementation with a data migration. It’s a greenfield implementation, not an upgrade.
It varies and depends on company size. A medium-sized Australian company can expect 9-18 months. This can be faster if you have a relatively straightforward data environment, but slower for highly customised AX 2012.
You continue to operate, but there are no more security fixes, no compliance changes, and increased audit and cyber risk. Cyber insurance companies also don’t cover unsupported ERP systems.
Not necessarily. Dynamics 365 Finance and Operations doesn’t include a payroll system that can handle Australian payroll, so most companies retain a payroll system and integrate it. Think this through early in the process.
