The failure of most of the migration projects is not due to poor software. Their failure is due to one business considering a fundamental change in how operations were conducted as an IT upgrade.
In case you are considering switching to Dynamics 365 Finance and Operations and are running a legacy on-premises ERP, whether that is older Dynamics AX, MYOB Exo, Pronto, SAP, or something that has since been fully customised since 2008, this article goes well beyond the basics. It dwells on the migration realities that most vendors, partners, and the transformation journey that most articles ignore.
Why Australian Businesses are Migrating to Dynamics 365 Finance & Operations?
The migration toward Dynamics 365 Finance and Operations in Australia has been expedited due to legitimate reasons: the software is always up-to-date, the infrastructure of Microsoft is reliable, the integration of the Power Platform and Teams is comprehensive, and the end of long-term support of the legacy Dynamics AX environments. The lifecycle documentation that Microsoft has published confirms that the extended support of Dynamics AX 2012 R3 expired on January 10, 2023, and all the previous versions reached end-of-life even earlier than that date. No assisted line of action should be kept to stay on legacy Dynamics AX, and the migration becomes not optional but mandatory.
Research by McKinsey found that three-quarters of ERP projects fail to remain on time or within budget, and two-thirds of ERP projects produce a negative ROI. An independent analysis quoted in Gartner cited the failure rate of ERP implementation, as the inability to achieve original business objectives, as between 55 percent and 75 percent. Those figures are before adding the particular complexity of the Australian compliance environment. The product has never been the issue; the playbook is.
The Mistake That Dooms A Majority of Projects Before Implementation
The most hazardous supposition in any dialogue about an upgrade of Dynamics 365 is this: “We will lift and shift our current processes and clean them up later on”. That later will never come.
Archaeological sites are on-premises ERP systems, particularly those systems which have been live 8-15 years. Each customisation is a business choice of an individual who might not be employed in the same organisation anymore. There is a rationale behind every workaround.
When you move to D365 F&O without even interrogating those layers, you are incurring technical debt on a modern cloud platform at a very high cost. The companies that make clean migrations see the project as a process redesign project, which happens to have a technology deliverable, not the other way around.
What the Migration Process is Really About and Which Settlements are Complex?
Data migration is not a technical issue; instead, it’s a business one. As soon as you mention migrating payroll data, all project managers in the room start thinking about ETL tools, data mapping workbooks, and the number of rows. That’s wrong. It is not whether or not we can transfer the data, but whether or not this data will manage to survive the migration at all and in what form?
Gartner studies indicate that over 80 percent of data migration projects do not succeed or exceed budgets, cost overruns averaging 30 percent and time overruns averaging 41 percent.
In the Australian context, special attention should be paid to payroll migration. Now that Single Touch Payroll Phase 2 is law, starting 1 January 2022, with modern award interpretation, superannuation, and the intricacy of state-based payroll tax thresholds, your payroll setup is not a schema to copy anymore; you need to reassess everything.
The regulatory stakes are high. The right to unpaid or underpaid superannuation is an enforceable right under the Fair Work Act, which means that since 1 January 2024, employees can take court action under the Fair Work Act to recover unpaid or underpaid superannuation. Starting 1 July 2026, Payday Super will require employers to make superannuation contributions on each payday instead of quarterly, a fundamental change in the structure of payroll that must be designed into any new system at the outset and not retrofitted once go-live.
Also, since 1 January 2025, wage theft has become a crime. Such changes in legislation imply that any migration of a payroll system that does not include a full compliance audit against current ATO, Fair Work and state requirements is a liability, and not a project deliverable.
In short, payroll migration refers to the revalidation and not replication.
Importance of the Integration Map
On-Premises ERP systems have generally accrued integrations over the years with warehouse management systems, EDI platforms, eCommerce solutions, custom reporting databases, bank feeds and sometimes, ancient Access databases on which one finance person just needs the reconciliation.
Write an entire integration register before you and your implementation partner have even a single design session. Not a list of systems, a map of all the data flows, how often they occur, who owns them, and what would happen should it be interrupted during 72 hours. Microsoft’s own implementation guide specifically highlights this, stating that organisations must update existing integration and peripheral applications to be compatible with the cloud solution and that some of the components may need to be fixed or even replaced altogether.
When you are not yet familiar with your own system, and can not answer questions like what breaks and why, then you are not yet in a position to migrate your own system.
Do You Need Any Customisations During Dynamics 365 Upgrade?
Customisation was the order of the day in Dynamics AX and other legacy systems. The floor was the standard functionality and not the ceiling. The philosophy is reversed in D365 F&O. The platform does not over-layer but does support extensions, which means existing over-layered customisations will now need to be re-examined and potentially rewritten.
Audit customisation with a simple three-column framework:
- What is the purpose of this customisation? (Business rule, compliance requirement, workaround to missing native functionality)
- Is this now being managed by native D365 F&O? (More frequently than you’d think)
- Is it a process worth rebuilding or redesigning?
Most Australian organisations find that most of their legacy customisations can now be mapped to standard D365 F&O functionality. The rest will usually initiate a process-redesign discussion where a few may be completely eliminated. This trend will always lead to much easier support models in the future.
The Phased Migration Approach
A proposal of a big bang cutover, you go live on a fixed date, everything will switch, and the old system will be decommissioned, as suggested by many implementation partners. This is feasible in the case of small businesses with simple data models. It is high-risk for mid-market and enterprise Australian businesses.
Research carried out by the Cloud Security Alliance indicates that the average time to move ERP to the cloud is months. A staged plan can substantially mitigate that risk.
Phase 1: Discovery & Analysis
Compare current-state processes to D365 standard functionality and produce the gap analysis. Make Architectural decisions regarding extensions before any development. Complete your master data migration strategy: chart of accounts, cost centres, suppliers, customers, and items. This step is a precondition for any execution taking place.
Phase 2: Core Financial Go-Live
First, set up the financial management module, general ledger, accounts payable, accounts receivable, and fixed assets. Close one complete period with your legacy system. Unless it will cleanly shut in parallel, then you are not ready to fully cutover.
Phase 3: Operations and Payroll
Procurement, inventory, project accounting, and (managed independently, with special testing) payroll. A payroll migration should not be mentioned on the fringes of a larger project. Payroll errors have an impact on the lives of people and become the subject of regulatory attention. So, you need to treat it accordingly.
Phase 4: Decommission and Optimise
The retirement of the legacy system, the Power BI reporting buildout, user adoption tracking and the post-go-live process optimisation that your implementation partner will have moved on to, as long as it was not contractually scoped.
What No One Tells You about Dynamics 365 Upgrades?
- D365 F&O upgrades are more disciplined than most would anticipate. Microsoft releases four updates per year, with one or more being mandatory, and each update can affect customisations.
- Direct SQL reporting is not feasible and Power BI or Azure tools are required, which is costly and complicated.
- There is a robust Australian localisation but reforms such as Payday Super need to be planned.
- After all, the size of the partner firm is less important than the experience of consultants.
What Occurs After Go-Live Matters More
The biggest failure that Australian businesses make after go-live is to consider the project as completed. Dynamics 365 Finance and Operations is an ever-changing platform, where continuous innovation and AI functionality are included. Those organisations that can see real value in 24 months are the organisations that perceive migration as the beginning and not the end. Whereas others keep the old processes in a new system, the same workarounds, the same spreadsheets, but at a higher cost. So, don’t get stuck after migration; use it to create an operational base for the next decade.
Final Thought
The successful businesses do not consider Dynamics 365 Finance and Operations as a technology project. They view it as an operational reset, one that requires honest process audits, rigorous data cleansing, compliance revalidation, and a partner knowledgeable of Australian payroll law as much as they know the platform. The major part of migrations is not a failure due to bad software, but the inability to prepare. Those organisations which invest in the pre-work will migrate right and will build on a lasting foundation.
FAQS
The majority of Australian mid-market companies need to plan upto 18 months between initial scoping and full decommission of a legacy system. Organisations which hasten the schedule, especially by omitting parallel executions and data cleaning, continuously record cost overruns and disruption after go-live.
Migration of payroll data is not a simple transfer of information, but a compliance revalidation exercise. Before anything is transferred to the new system the Australian businesses have to audit their configuration against STP Phase 2, superannuation guarantee obligations, and modern awards.
According to the research conducted by McKinsey and Gartner, between 55% and 75% of the ERP implementations fail to meet their original business objectives. The most typical reason is that the project should be seen as an IT initiative, but not a business transformation, which needs process redesign.
Not automatically. Dynamics AX employed an over-layering model whereas Dynamics 365 relies on an extensions-based architecture, i.e. each customisation has to be evaluated separately. A significant percentage of legacy customisations that are present in many organisations have become unnecessary in the new platform.
Ask the partner to provide references of similar-sized businesses and test the partner’s knowledge of the partner in local payroll compliance, STP2, and interpretation of awards. The consultants that will be assigned to your project are much more important than the size or brand of the firm.
