Dynamics AX vs. D365: The Differences Between Microsoft’s ERP Versions

Many organizations that are using Dynamics AX are considering an upgrade to Dynamics 365 for Finance and Operations (D365). If your organization is considering this upgrade, you may be interested in learning more about the differences between these two systems before you commit to an ERP project.

A Brief History of Dynamics

Originally developed in 1998, IBM Axapta was created through a collaboration between IBM and Damgaard Data to fulfill the need for a computer-based accounting program geared towards enterprise-level businesses.

A few years later, Damgaard Data merged with Navision Software A/S to create the company Navision A/S, which Microsoft later acquired. During this time, the ERP system was known as Axapta.

Over time, Microsoft further developed Axapta to cater to businesses across a variety of industries, including financial services, manufacturing and retail. Axapta then became known as Dynamics AX.

Several versions of Dynamics AX were released by Microsoft, each continuing to establish the ERP system as a contender in the market – from AX 4.0 to AX 2009 and finally AX 2012. The ERP system was widely adopted, and many customers are still using a version of AX as their means of operating their businesses.

Fast forward to 2019, and Microsoft is proudly marketing and implementing D365 as the greatest version of their ERP software to date. The transition started with moving AX into the cloud, allowing users to access the application via a browser. Briefly, the name of this version was AX7. Later on, when Microsoft was rebranding their product line, they changed the name to Dynamics 365 for Finance and Operations.

5 Differences Between Dynamics AX and D365

Although they are essentially two different versions of the same software, there are a few key differences between the two ERP systems. For the sake of this post, we will compare Dynamics AX 2012 to Dynamics 365 for Finance and Operations.

1. Infrastructure

The biggest difference between Dynamics AX and D365 is the infrastructure the systems are built on. When Microsoft committed to putting cloud technology first when CEO Satya Nadella took over in 2014, they moved the Dynamics family of products into the cloud, as well. This meant that Microsoft’s cloud service, Azure, would host D365 and any other applications from the Dynamics 365 suite of products. In contrast, Dynamics AX 2012 can still be run on-premise, meaning that customers can host the application on their own servers that are physically onsite.

Initially, there was some resistance to the cloud-driven model. Organizations were used to storing their production data locally and having the ability to access it at any time. For example, with an on-premise ecosystem, a system administrator could write a SQL query to view data in real-time.

Customers who had a production environment of AX did not want to host it in the cloud as they would have to request copies of their production database from Microsoft to pull from the cloud.

The process for code deployment to production was also changed in the cloud. System administrators could no longer promote code to production on-demand, and instead, had to schedule a deployment, which Microsoft would do on the customer’s behalf.

Despite the initial resistance, cloud-based infrastructure has become an accepted and, oftentimes, preferred method of managing an ERP system. Creating and maintaining an on-premise ecosystem is an administrative project on its own – you must acquire the necessary hardware, build the network in a way that allows employees around the globe to access it and plan for disaster recovery. All of this can be extremely costly and a headache to maintain.

With Microsoft Azure hosting your ERP system, these steps are done by Microsoft in collaboration with the customer, making environment management convenient and simple.

2. Custom Development

Another key difference between Dynamics AX and D365 is the method in which custom code is written and implemented.

With any ERP implementation, there is bound to be some software configuration or customization needed to meet specific business requirements. With Dynamics AX, custom development can be applied using the over-layering method. Over-layering is a concept that allows the core product, customer code and any value-added reseller (VAR) code to be separated from each other in different layers. The different sets of code are then layered on top of each other within the ERP system. Sometimes, when the code is merged, compatibility issues arise, and developers must adjust their code before it can be deployed.

D365 requires the use of the extensibility model as opposed to over-layering. This means the core code of the ERP system is locked down, not allowing any customizations. Developers must customize the software through built-in extension points.

Only objects that have extension points can be customized, but if a customer has a need for a new extension, they can request it from Microsoft. Microsoft often provides extensions directly to customers or includes them in future releases. When it comes to upgrading, the extensibility model is highly preferred as it causes significantly fewer compatibility issues than the over-laying method.

While Dynamics products are easier to customize than many other vendors’ products, it should be noted that extensive customization is a key failure point we see in many of our software expert witness engagements. We recommend that organizations carefully manage customizations by developing project governance and controls to ensure customizations are made only when absolutely necessary.

3. Upgrade Model

Upgrading to a newer version of Dynamics AX – like AX 2009 to AX 2012 – often requires a new implementation. Many AX customers considering an upgrade find that they first need to evaluate the business impact of the upgrade and improve their business processes. This requires a new implementation because new processes often require new configurations and/or customizations.

Other AX customers see the need for a new implementation when they realize that their custom code conflicts with the code delivered by Microsoft in the new software version. In these cases, developers must change and sometimes entirely rewrite their customizations.

Upgrades from AX 2012 to D365 can typically be done without a new implementation, depending on the amount of custom code involved. However, upgrades from AX 2009 to D365, require a new implementation since there is no direct upgrade path from one to the other.

With the move to the cloud came the opportunity for Microsoft to adopt a new upgrade model, similar to the upgrade model of modern applications consumers are familiar with today.

This model, used in D365, does not require a new software implementation. Instead, monthly updates are pushed out to customers on the ERP application. Large feature changes are delivered as parameters or configuration keys, allowing customers to decide if they want to turn on the new functionality. For customers with custom code, the chances of conflicts with the upgrade are drastically reduced.

4. User Interface

A very apparent difference between Dynamics AX and D365 is the user interface. With Dynamics AX, a user can launch the application from a desktop and perform their work within the program. Dynamics AX has the aesthetic of most ERP systems, which is, to be honest, a little out of touch with today’s typical ERP user.

With D365, a user can launch a web browser and enter a URL. Within the browser, the user can perform his or her work and open additional tabs if necessary. D365 can be launched from desktops and mobile devices alike – anywhere with an internet connection. The look and feel of D365 is more aligned with Microsoft’s branding and matches the style of other Microsoft products, like the Office 365 suite.

In Dynamics AX, the homepage defaults to an area called Role Centers. Here, users can create custom queues and links that make performing their daily functions easier.

In D365, the homepage defaults to an area called Workspaces. While similar to Role Centers, Workspaces are prebuilt queues, links, lists and graphics that are related to specific modules and security roles.

An unfriendly user interface can exacerbate the user adoption challenges inherent with ERP implementations. When organizations experience user adoption issues – user interface-related or otherwise – they often seek guidance from ERP consultants. If user adoption issues are severe enough, this can be considered an ERP failure. ERP consultants, like Panorama, have extensive experience recovering ERP implementation failures caused by variety of factors.

5. Navigation

Navigational differences, though minor, are worth noting.

A common theme across ERP systems is that certain screens can be launched from several different places in the system. In Dynamics AX, a user must know the menu path to a specific screen. For example, to create a new sales order, a user can navigate to Sales and marketing > Sales orders > All sales orders. However, this is not the only place to launch the sales order screen, which makes it difficult for users to memorize any particular path.

In D365, a new search capability was added to allow users to type in the name of the screen they are looking for and click from the results to launch the page.

Should You Upgrade Your AX System?

Now that you know the basic differences between AX and D365, you may be more confident that you need to upgrade to D365. This is a wise decision for organizations seeking a more manageable production environment, easier customizations and upgrades, or an improved user experience.

However, an upgrade from AX to D365 is no easy task. Our ERP consultants can help you understand the business impact of an ERP upgrade. We will guide you through organizational change management activities and other essential project activities that make upgrades smoother and more beneficial to your bottom line.