Our Blog

where we write about the things we love



Microsoft Dynamics AX (“AX7”) upgrade

Microsoft has released its latest update to its flagship ERP solution Dynamics AX in March, 2016, taking the opportunity to rebrand it as simply ‘Microsoft Dynamics AX’, dropping version numbers altogether. In any case the product fraternity sometimes still refers to Microsoft Dynamics AX as ‘AX7’.

Upgrade vs re-implementation

Ideally a Dynamics AX upgrade would involve two activities:

  • Code upgrade: This is the process through which you upgrade your business logic or ‘code’ in technical parlance.
  • Data upgrade: This is the process through which business data is upgraded to the new data model.

We say "ideally" because Microsoft has not released a Data upgrade service yet, which we expect to be available by end of 2016.

The first alternative that comes to mind is re-implementation, which is similar to a full implementation and requires the new version to be deployed from scratch, necessary business logic applied and opening balances and master data uploaded.

Somewhere between these two options lies a third alternative which takes elements from each. This approach involves doing a code upgrade but going with the opening balance and configuring the master data.

The important thing to note here is that Microsoft has a well-defined code upgrade service and a comprehensive and well tested approach to upload data in Dynamics AX. This makes this third approach an attractive option to consider. 

Supported upgrade paths

Microsoft provides an upgrade patch from AX 2012 to Dynamics AX. The code upgrade service currently accepts a model store file as input which essentially means that you can upgrade anything AX 2012 to Dynamics AX. However, this process works best for AX 2012 R3 CU8 onwards. The reason for this being that the Dynamics AX CTP5 code base was based on AX 2012R3 CU8 so chances of automatic merging of code is much higher in versions post CU8.

Microsoft however does not currently provide upgrade path for AX 2009 or AX 4.0 to Dynamics AX. What does it mean if you are a running AX 2009 or AX 4.0 instance? Chances are you would be tempted to do a re-implementation. With so many new features, such a cool UI and the investment Microsoft has done in this platform, it is totally worthwhile. But just in case you want to wait or would not like to go for a re-implementation, our recommendation would be to upgrade to AX 2012. It is a time tested upgrade path and you could be ready with an upgraded AX 2012 application, ready to take things to the next level with Dynamics AX. We hear Microsoft has offered some good concessions to existing AX 2009 customers in terms of Licensing should they wish to move to AX 2012. So take this opportunity and be ready.

Pre-requisites and considerations

This is where it gets really interesting. Let’s tackle pre-requisites first. The code upgrade is done as a service exposed through Lifecycle Services or LCS. So you need a LCS project to start with. If you don’t have this enabled, ask your partner to enable this for your organisation.

As mentioned earlier you need a model store file (not model database) from any AX 2012 version. If you are not evaluating your application for a prospective upgrade and is really into the upgrade mode, you must have a Visual Studio Team Services (VSTS) project created to manage the upgrade process. Again your partner will be able to set this up for you, if they haven’t already.

VSTS has a whole lot of other functionality and is the “Go to” ALM/Version control solution for Dynamics AX. It’s a wonderful tool to manage your Dynamics AX journey and allows collaboration between the project team and the client stakeholders in efficient and transparent manner.

Now the hard part: what to consider before you take the plunge. We will list a few items that we feel are most important:

  • You should consider to remove any unnecessary models that you may have in your model store. These may be test models, conflict models that get generated when you import hotfixes or any other model which has features that you don’t use. The less the number of models you have the easier the upgrade process and chances are a majority of the code will be auto upgraded leaving you with minimal manual effort.
  • Also make sure that the model store you upload is fully compiled and there are no errors.
  • Another consideration is the presence of ISV models in your model store. Check with your ISV whether they already have a Dynamics AX compatible version for the solution.
  • If they don’t have or you have customised the ISV solution heavily to fit your needs, it might be a good idea to include your ISV model as part of the upgrade process. The upside is that you don’t have to re-write all the ISV specific customisations you have done in Dynamics AX, while the downside is that all your ISV code gets over-layered to the Platform, Foundation and Application Suite packages. This will potentially increase the complexity of patching and servicing your Dynamics AX solution in future.

On the other hand, if your ISV has a certified Dynamics AX solution, you have two options. Both essentially involve similar amount of effort, so no clear favourites here:

  • You can remove your ISV models from the AX 2012 Model store, resolve all the compilation errors and then start the upgrade process. This will ensure only core customisations will be upgraded and much less effort will be required to resolve this. After the upgrade process the Dynamics AX ISV models/packages can be re-applied and you can perform any ISV specific customisation in Dynamics AX.

The other approach is to go with the AX 2012 ISV model files as part of your model store. The process will upgrade this to their individual models but due to over-layering they will be part of the Platform, Foundation and Application Suite packages. You can now delete these models as you already would have a separate Dynamics AX package from you ISV. This will also save you the additional work of resolving conflicts on the upgraded ISV models.

As mentioned earlier whichever approach you take there is no clear winner here. If you have not customised your ISV solution much, the first approach might be a cleaner way of doing things.

Tools available for upgrade

As we have mentioned previously Microsoft provides a code upgrade service through LCS. There is no data upgrade tool available at the moment, so the standard way to load master data and opening balances is through the data entity framework. This is a great way to upload your data and is much more advanced than the existing data upload capabilities of AX 2012.

Key concepts and process

The LCS code upgrade service runs based on intelligent algorithms that does a lot of things automatically for you. The figure below describes the process that happens under the hood when the code upgrade service is run.

Dynamics AX models

We have tried to explain these steps below:

  • Convert AOT artefacts to XML files – In Dynamics AX, all AOT artefacts such as tables classes and forms are xml files, so this is one of the first things that happen.
  • Re-baseline model store – The model store is now split into individual packages. This is known as model split and essentially is the process of rearranging legacy metadata into package based structure of Dynamics AX. Dynamics AX contains three core packages Application Platform, Application Foundation and Application Suite. Most of the Microsoft code that resides in sys, syp layers of previous versions gets re-arranged into these three packages, while the rest of unsupported code is removed.
  • Auto-migrate via code upgrade rules (mostly over-layering) – The upgrade service mostly follows the over-layering principle to migrate code. This is to reduce complexity and to ensure that maximum amount of legacy code can be auto migrated. However wherever possible extensible principles have been applied. To know more about over-layering and extensibility refer here.
  • Auto merge to Dynamics AX – The upgrade service algorithms try to auto merge code between the versions. According to Microsoft the success rate of this process is 95% for code. From our experience, we found this to be pretty accurate with about 80% success rate for custom code and 95+% success for system code. To give you an idea, our model store had about 40% customisation and an ISV solution when we ran the upgrade service. Considering this, the results were very encouraging.
  • Generate conflicts and TODOs – It is a reality that the upgrade service can’t resolve all the code merge scenarios and will generate code conflicts that will be neatly flagged with TODO tags and comments that help you to resolve them later. In our upgrade scenario, 10-15% of non-Microsoft code generated a conflict. About 20% of this came from ISV models. The ISV models could be easily stripped off before or after the upgrade completes, if your ISV has a new Dynamics AX version. In summary, if you consider starting off with a 40% customised model store, we only had to manually merge about 10% of the customisations. This we believe is a great result considering the complexity and how far apart the architectures of the two versions are. So kudos to Microsoft.
  • Create estimates and task lists – A brilliant feature of the upgrade service is the analysis it does on the uploaded model and details out the tasks that need to be complemented manually to complete the upgrade. The level of detail in this report is great for Developers and technical consultants and Microsoft even provides an approximate estimate of the effort required to manually resolve the conflicts. You can generate this report even without actually upgrading you model store, just to get an idea of the work involved. Isn’t that a great feature, we think it is and have attached a sample of one such report below.

Dynamics AX migration estimates and task list

  • Create migration overview report – This report downloadable as an excel file like the task list, details what was migrated and what couldn’t be migrated completely and requires manual conflict resolution. If you run the upgrade service on an “estimation only” mode, you will get this report and the task list as the two main artefacts. Based on this you can plan your entire upgrade without actually doing it.

Dynamics AX migration overview report

  • Create VSO solution with conflict projects – If you have done your estimation analysis and plan to run the actual upgrade process, a pre-requisite is to create a Visual Studio Online (VS Team services to be more specific) project and create necessary connections between Lifecycle services and this VSTS project. This is a one-time setup and helps to seamlessly manage your upgrade project. Once this link has been established, the upgrade project automatically creates a conflict project with all the relevant objects and checks the solution to VSTS. So whenever the developer wants to work on them, all they need to do is map their virtual machine to the VSTS project folder and get the latest source code. That’s it, they are ready to start working on the manual conflict resolution. Microsoft recommends to resolve conflicts in a specific order. Start by resolving conflicts in Application Platform, followed by Application foundation and Application suite.

Dynamics AX VSO solution with conflict projects

  • Create VSO solution with migrated metadata – Like the previous step, the code upgrade service also checks in the entire migrated metadata to a VSTS folder called ‘Release’. Developers can get the migrated source code when they map to this folder from Visual Studio in their VMs.
  • Auto check into to VSO with work items – The previous two steps make things very easy for developers to complete the upgrade. As a consultant or project manager however you can also track progress of the outstanding work. Once you link your VSTS project with LCS and complete the upgrade process, the service will create ‘work items’ in your VSTS project which details the work required to be done to complete the upgrade. You can then assign these work items to developers in your team and track and manage them efficiently. There are lot of good features in VSTS and you can leverage all of them for your upgrade project governance.

Dynamics AX VSO work items

Deprecated features and alternatives

If you are considering an upgrade, you should be aware that some things work differently in Dynamics AX and you might need to modify your code after you upgrade to make things work in the new world. Microsoft is here to help and have provided us with a detailed list here.

We will discuss a few common ones and suggest some alternatives. All in all, we think things have changed for the better and although it might result in some work upfront the new frameworks that has replaced the deprecated ones are much better and futuristic.

AIF – the AIF framework has been replaced by the Data management framework in Dynamics AX, so if you have legacy integrations that you have written using AIF, you will need to modify them to use DMF.

Cue – Cues have been replaced by Tiles in Dynamics AX. So if your AX deployment has lots of Cues configured for the uses, you might have to re-implement them using Tiles. These applies to only custom cues that you may have setup.

Data Partitions – This was available from AX 2012 R2 onwards, but Microsoft recommends not to use them in Dynamics AX. They are still present for internal reference but likely to be removed in a future update. Microsoft recommendation is to use separate instances of Dynamics AX in scenarios where partition was required previously. Microsoft is looking at the possibility of using different databases with the same AX instance as prospective replacement.

ActiveX and Manage host control – This has been discontinued in Dynamics AX in favour of Extensible controls which are based on Html, JavaScript and CSS and are much more flexible. So factor in some dev effort post upgrade if your application has many such controls.

GL SSRS reports – If you are not already using it, be prepared to use the Management Reporter aka Financial Reporting. The Traditional GL SSRS reports have all been deprecated, including Summary trial balance, Detailed trial balance, Chart of accounts, Audit trail, Balances, and Balance list. There is no actual effort involved and the new Financial Reports are much more configurable then the old ones.

Microsoft Outlook integration – This has been replaced by Microsoft Exchange server integration and there might be minor changes that you need to do post upgrade.

Product builder – Microsoft had already notified users that this would be deprecated when it released AX 2012. Product configurator was the replacement and it co-existed with Product builder. In Dynamics AX, there is only Product configurator.

Virtual company accounts – This has been traditionally the way data has been shared across companies. However, over time the AX data model has become too complex to implement virtual company shares correctly. Microsoft had hinted to deprecate this when it released AX 2012 and brought in the concept of Shared Tables. This concept has been extended further in Dynamics AX and virtual company has been deprecated altogether. You need to take this into consideration when you do the data upload to your upgraded Dynamics AX environment.

Enterprise portal – If you are reading this, chances are you probably know that in Dynamics AX we don’t have a separate Web and Windows client. The separate web client aka Enterprise portal doesn’t exist anymore and everything is now Web based. So if you have heavily customised your Enterprise portal, it might be a good idea to map similar functionality in the current Dynamics AX client and decide on what extra things you would need to customise.

Our recommendations

If you and your organisation are an early adopter of technology, we would strongly recommend to get on the bus with Dynamics AX - the benefits are immense. Let’s review some of the approaches that we can take with the resources and information that we have with us today:

Code upgrade: The code upgrade service has been already tested and used by 50+ ISVs to upgrade their legacy code to Dynamics AX. Microsoft mentions that it is likely to auto-migrate 80% of your custom code and about 95% of system code. Our experience regarding code upgrade has been very similar and you should be able to get over the line with minimal manual effort. Bottom-line is if you have an AX application which is 30-40% customised a code upgrade will require significantly less effort than re-implementing everything from scratch. The benefits of going through a code upgrade starts to taper off when you have more than 60% customisation and at 80% it might be easier to just go for a re-implementation. To accurately quantify the customisation level and arrive at a right approach contact us at Intergen.

If you are running a version prior to AX 2012 R2, this might be an ideal time to evaluate all of the above and arrive at a decision. If you are in the 30-40% zone, it might be a very good time for you to consider an upgrade to AX 2012 R3. That way you do the heavy-lifting upfront and when you are ready, performing code upgrade to Dynamics AX will be relatively easy. There is an important benefit to this approach. When you do the upgrade to AX 2012, you are able to weed out anything that is not supported in Dynamics AX making the later part of the upgrade much easier. So definitely consider this as an alternative if you are considering an upgrade in the near future, but not completely ready to go for a re-implementation.

Data upgrade: As per Data upgrade is concerned, at the moment, there is no standard way to do this. The AX data model has been normalised over the years and to write a custom tool is a considerable effort in itself. However, you have two options to accomplish this. Data upgrade is traditionally not the first thing that you begin with in an upgrade lifecycle and from what we hear Microsoft is most likely to release a standard tool for accomplishing this by the end of 2016. So our recommendation would be to line up the code upgrade process and be ready for the tool when it is released.

If you are working against a deadline though, the best bet would be to go with opening balance and re-configuration of Master Data. With the availability of tools like Data Management framework, it is much easier to upload data in Dynamics AX, then some of the previous versions. Also remember that Dynamics AX is now armed with 1700+ data entities so virtually all of your Data migrations needs are covered. What you might miss out is the ability to report on your legacy transactional data. But this is a trade-off which might not affect your business goals.


This blog post was authored by Ievgen Miroshnikov, Lead Developer Dynamics AX and Pathikrit Das, Lead Consultant Dynamics AX.

Posted by: Dynamics Team | 13 September 2016

Tags: Microsoft Dynamics AX, Consulting

Top Rated Posts

Blog archive

Stay up to date with all insights from the Intergen blog