Wednesday, March 15, 2017

D365 Tech: AX 2012 Upgrade Path

By far, the most informative session I attended was about the AX 2012 Upgrade Path. This hasn't really made the rounds yet and it's still pretty high level, but the plan seems solid and was very encouraging!

IMPORTANT TO NOTE: The upgrade tools won't be available until July 1, and will start with AX 2012 R3 and move backwards to include functionality for AX 2012 R2 and then AX 2012 RTM.

As of right now, the informally named Upgrade Analyzer is the core of your upgrade from AX 2012. This product effectively helps to analyze, execute, and validate the code and data that you wish to migrate from your 2012 environment through an LCS diagnostic service. The nice thing about it is that it can be used on a backup of your database at any time, so if you want to analyze your data to see what kind of issues may lie ahead, it will be available for you to use!

Getting Started

In order to get started with this process, you need a few prerequisites. You will need to have a VSTS account and a LCS account. So, what does that mean? VSTS is the Visual Studio Team Services. You can sign up for an account through LCS is Lifecycle Services. This might be something that you have heard of since this is how Microsoft handles any communication with you regarding your environment such as hotfixes and cumulative updates. Basically, this is where you manage the lifecycle of your Dynamics products! You can find LCS at

Once those accounts are set up, upload a copy of your model store to the LCS code upgrade tile. This will generate a massive excel report with hundreds of tabs with plenty of information. Basically, you will see a tab for every bit of functionality in the system and the code that is included in that functionality.

For more information, go to


The Upgrade Analyzer is supposed to be able run on the copy of your model store and give you some really great info and suggestions for some improvements to make to your AX 2012 environment prior to your upgrade. Examples of the analysis that will occur include the following:

Data clean up

In Dynamics 365, database storage is going to be allocated based on total amount of users. If you go over that limit, you will incur a subscription cost. This tool will show you what can be deleted and how much space can be saved, helping you to save money and upgrade downtime.

SQL configuration

The upgrade analyzer will review your SQL configuration and recommend environment optimizations that your DBA can make prior to your upgrade process.

Deprecated features

This one kind of hurts... but it's also kind of beautiful. The upgrade analyzer will identify which features will not be available moving forward, giving users an earlier view of gaps that might be missing when the upgrade process begins.

Pre-upgrade checklist

A pre-upgrade checklist will be generated giving users tasks to complete in order to have a successful upgrade. This may include installing hotfixes and adding UPN (domain suffix) to user accounts.


In the next steps, you will begin to execute the plan that was made from the analysis of the data in the previous steps. You can begin by deploying a sandbox in Azure through LCS and working through the clean up tasks. Some important pieces of information I picked up from this were:


Ignore any information that comes through the analysis stage from your ISVs (Independent Software Vendors). Request a new version for Dynamics 365. There is no point in trying to upgrade what you currently have installed as it will be difficult to transition. Most ISVs already have their offerings available for Dynamics 365. if you're not sure, just ask!

Work toward a successful compile

This one gave me a bit of heartburn, and I heard an audible groan in the room when this was announced. I am going to put the next sentence in bold so everyone understands. If there is a compile error, you WILL NOT be able to open Dynamics 365. Work toward an error free environment because a small error in code can take your entire environment down. Testing will be key in Dynamics 365.

Start at the bottom and work your way up

What this means is to start with the lowest package and work upwards. Start with the platform and foundation and just keep working through those compile errors because they all reference each other and this will be a better process for your environment.

Development tips

Understand the model split implications. This can cause extra work if you don't understand. Refactor all old code as extensions. This will save time and money in the future as code will then be upgradable in the future to newer versions of Dynamics 365.

Data upgrade process

There will be a deployable package for the data upgrade on the MajorVersionDataUpgrade framework. There will be no scripts in this package as those are ReleaseUpdate X++ classes.

Script process

Script execution work in a similar manner to previous upgrade versions. They will be done in batch which will figure out the script dependencies, run them in the right order, then give a pre-sync/sync/post-sync/sync of your environment.


There is a high probability that you will run into errors. Luckily, Microsoft has put together a wiki for this:


Obviously, validation is going to be a huge part of the upgrade process. There will be an upgrade validation tool to run that will perform an automated smoke test to help validate the success of the upgrade run by doing the following:

Smoke test examples

  • All servers started
  • All server components accessible
  • Review that expected data is there
  • General ledger reconciles to 2012
  • Inventory reconciles to 2012

From there, users can review the sandbox environment and if everything is running as expected, a cutover plan can be executed and Dynamics 365 can be deployed into a live production environment. Piece of cake, right? Only time will tell.


It sounds like Microsoft has a pretty solid plan for the upgrade process. It's going to have some pain points like any other upgrade, but they do seem to be actively working to make this as easy as possible on the users.

My favorite part is that I can run the upgrade analyzer on my model store prior to even making a decision. Thanks goes to Microsoft for that bit of functionality and allowing the users to have some insight into how easy or difficult our upgrade path will be. I am encouraged by the path this is taking, Remind me of this after I run the upgrade analyzer.


  1. What about companies trying to upgrade from AX 2009? Has Microsoft outlined what would be the recommended path for them?

  2. For 2009 only data migration is supported

    1. Laze is correct. I did not go to any sessions for 2009 since I'm using 2012, but I did ask around and was told it's only data migration for 2009 users.