Upgrading from Dynamics AX to Dynamics 365
We’ve recently done a couple of upgrades from AX 2012 to Dynamics 365 for Finance and Operations. I thought it might be beneficial for a quick synopsis of the different types we’ve encountered.
There really isn’t an “upgrade” from AX 2009 to D365. There is a data migration toolset provided by Microsoft that gets installed in AX 2009, but it’s primarily a backport of DIXF to AX 2009. It helps get your data aligned with the new schemas, but it still requires some hand-holding and manual intervention to do its job. It can handle custom fields, though, so that’s certainly a nice feature. As far as the code, there isn’t a toolkit for this. With all the development changes and the move to extensions, there’s a pretty significant manual effort required to get code up-to-date. We at DC like to recommend using this exercise to really examine what customizations are needed and getting rid of anything unnecessary. Since AX 2009, there’s been a substantial increase in features and it certainly seems like a good time to re-evaluate the options out of the box!
There is a true upgrade from AX 2012 R2 to D365. Basically, after some pre-upgrade scripts are run in 2012, the AX 2012 database is moved over to a D365 environment. From there, an upgrade script is run against the database to transform it to the new schema. Once this is completed, the environment is ready for some post upgrade work (enabling batch jobs, setting up print management, etc.) As far as the code, the codeset is run through an upgrade analyzer in LCS. This results in a bunch of tasks being created in VSTS (now called Azure DevOps) for processing by a development team. These tasks show modifications that need to be changed to fit new development patterns or will result in code being overlayered. The upgrade is pretty straightforward, but the R2 toolset is still in preview (and likely will be forever.) There are some bugs and quirks. Microsoft has done a good job supporting it, but it might be tough to stick to an estimated timeframe because you might run into something that requires a hotfix and you might be stuck waiting.
The process it he same as from AX 2012 R2 to D365, but the upgrade toolset seems to work better. We ran into considerably less issues with the out-of-the-box upgrade from R3 to D365 than we did on R2. The R3 to D365 upgrade seems to be more supported, too, with more examples of this being completed successfully than we found with the R2 upgrades. If you want some additional discussion on a recent upgrade from AX 2012 R3, check out http://dynamicconsulting.com/ax2012r3-d365-upgrade-findings/.
What does this all mean?
If you’re on 2009, you don’t have much of a choice. Since there are no in-place data upgrade scripts, you’ll have to “migrate” or “re-implement” (depending on what you want to call it.) This isn’t all bad, though. If your company is happy with the AX platform, this is great time to leave behind some legacy code and get onto an easier to upgrade path. If you’re on 2012 R2, there’s a case to be made for upgrading to R3. Is it worth it? Probably not. While the R2 scripts were kind of buggy and needed some additional support, they eventually worked. Every project is different, but it certainly seems to me that the incremental benefit to starting the upgrade from R3 vs R2 isn’t really worth it. Once you get on Dynamics 365, you get to deal with the world of continuous updates. Check out our post at Welcome to the New World of Continuous Deployment to learn about what this means. If you’d like to discuss more, ping me on LinkedIn or email [email protected]