Architecture differences to consider
Finance and operations is a reimagined ERP application that is designed for cloud deployment, meaning that you will find significant differences in the architecture if you are upgrading from AX 2012. As your organization begins upgrading to Dynamics 365, you need to understand these architecture differences so that you can make decisions that will help the upgrade be as seamless as possible.
Finance and operations apps run on a significantly new platform that enables you to be cloud ready. Keep in mind that some features have been deprecated or have been refactored with feature adds. Additionally, all language translation for the user interface will ship with most of the regulatory localizations for over thirty countries or regions.
The following list reviews key architecture differences between AX 2012 and finance and operations apps, and is shown in the following diagram.
Tools – Developers now use Visual Studio to develop for Dynamics 365.
Note
Virtual machines that are deployed on version 10.0.13 (Platform update 37) or later contain Visual Studio 2017. Version 10.0.16 (Platform update 40) is the final release with support for Visual Studio 2015. Virtual machines with only Visual Studio 2015 will not be able to update to version 10.0.17 (Platform update 41). For more information, see Removed or deprecated platform features.
AX MorphX development tools are no longer used. Developers now work in their own developer environment. All tools that a developer needs to extend the application to fit the needs of your organization are available in Visual Studio. Azure DevOps is used for source and version control. It is important that you consider licensing for Visual Studio for your developers when you are upgrading to Dynamics 365.
Client – Dynamics 365 runs on an HTML 5 thin client. Therefore, you will no longer use a rich client like the one that was used in AX 2012. Additionally, Enterprise Portal on Microsoft SharePoint or SharePoint Modern Apps no longer exist. Everything for the application can be accessed in the thin client through a web browser. You can also access the Dynamics 365 app on iOS and Android devices.
Data management services – Data management services are in place for integration scenarios to support your business. The data management framework supports the use of data entities in the following core data management scenarios:
- Data migration
- Setting up and copying configurations
- Integration
For more information, see Work with data management in finance and operations apps.
Application server/cloud platform – When upgrading from AX 2012, you will no longer be using Windows Server; Dynamics 365 uses Azure compute. The System Center Operations Manager management pack has been transformed into telemetry enablement, which gives you and Microsoft the ability to track bugs and issues with the application quickly and then resolve them in a quick and transparent manner. Application Object Server (AOS), AX client, and Business Connector have been combined into a Common Runtime that enables REST and OData capabilities. Additionally, AX application code has been transformed into an application stack that’s been split into several packages, including Application Suite, Application Foundation, and Application Platform, and many more.
Data – A major change in data from AX 2012 is that you will no longer use SQL Server 2014 for your data. Dynamics 365 uses Azure SQL and Microsoft Azure Storage (blob storage that can be used to develop documents and manage unstructured files), along with SQL Server Reporting Services (SSRS) and Power BI.
Identity – In AX 2012, identity is managed with Active Directory. With Dynamics 365, identity is managed through Microsoft Entra ID. Essentially, Microsoft Entra ID is an active directory that is managed in the Azure cloud.
Logical architecture
As mentioned, Microsoft Entra ID and Azure SQL are two main components of cloud-hosted Dynamics 365. The following list reviews the databases for Dynamics 365.
Primary DB (AXDB) – This database is your primary database and where your production data lives for the application.
Secondary DB (AXDB) – Data from your primary database will be replicated to the secondary database for disaster recovery purposes. With Azure, you can stand up your databases in different regions. The data replication is happening within seconds.
Entity store (AXDW) – You can have aggregated data, such as aggregated measures and dimensions, and move that data to the AXDW Entity store. This database is optimized for data analytics.
Management reporter (MR) – This database is used for Management reporter data if you are using financial reporting in Dynamics 365. (Management reporter is now named Financial reporting in Dynamics 365.)
Bring your own database (BYOD) – This database is not managed by Microsoft. The BYOD function allows administrators to configure their own database and then export one or more of the data entities that are available in Dynamics 365 into the database.
Compute – All your application components, including AOS, Batch, and SSRS, run on Azure compute.
Lifecycle Services – A collaboration portal that provides an environment and a set of regularly updated services that can help you manage the application life cycle of your implementations. For more information, see Get started with Lifecycle Services for finance and operations apps .
Finance and operations apps Connector – Allows Microsoft Power Automate, Power Apps, data integrator, and Azure Logic Apps to integrate with finance and operations. An external application can use the available trigger and actions to integrate with them.
Finance and operations app – This includes the Platform for Dynamics 365, and the Application, which allows you to use the cross-application functionality and to use other Dynamics 365 apps like Dynamics 365 Commerce and Dynamics 365 Supply Chain Management. The Third Party Models feature might include other ISV solutions that help you enrich the product to work for your business. The Customer models feature includes customer-specific customizations. More specifically, customer models are extensions of the application. This information will be covered in a later module.
Runtime architecture
Now that you have learned about the main architectural differences, you can learn about the runtime architecture differences between AX 2012 and finance and operations apps.
AX 2012 – rich client
AX 2012 uses a rich client that uses Windows Server. A high latency occurs between the logical control and the AOS, and a low latency occurs between the physical and logical controls. X++ runs on both tiers (client and server) and forms the state of the client. Additionally, the terminal server supports wide area network (WAN) usage.
Finance and operations – browser client
With finance and operations apps, you are running on a thin client that you access through a web browser. The thin client contains a low latency between logical control and the AOS, and a high latency between the physical control and logical control. X++ runs solely on the server tier, and the form application state is also stored on the server. Deltas keep control state in sync, and the webserver supports WAN usage.
