My report from the technical conference.
For the last session in the conference 😦 , I went to Code Migration to the Latest Release of Dynamics AX with Kiril Val, Senior Solution Architect.
This was kind of a gimme for me. I had already been to Kiril’s five day code upgrade workshop given for ISVs in October. (Secret: The Seattle area photos I’ve put in a few of these blogs are actually from then. I didn’t get time to tourist this time.) I wanted to see how it came together, perhaps contribute, and note differences between a CTP and the RTW.
I noted that the last part, “What I wish I knew” is crucially important. These contain real pain points that were hit along the way.
Session Objectives
- Understand code migration approach for Dynamics AX and beyond
- See a real solution being migrated
- Discover how to prepare for Dynamics AX
- Learn developer’s tips and tricks for the code upgrade
Out of scope: Data upgrade
Data upgrade we hope to have available with update 2 perhaps 6 months. Also perhaps data migration from 2009.
How did we get here?
– AX 2012 Migration
- Challenging
- Dynamics AX goals
- Seamless, Easy, Predictable
- Existing Momentum
- Code migration started with partners March 2015
- Partner readiness well underway
“We are as close as it gets to a magic button”
Dynamics AX Code Migration

AX 2012 to current Dynamics AX
- All types convert as is, major exceptions:
- Enterprise Portal is not supported in current Dynamics AX and needs to be rewritten
- Custom client controls will not run in current AX
- Document Services are not supported in current AX
- Form parts are replaced by current AX form parts
- Cues
- Visual Studio Projects
Migration Process

Those steps are important
The manual part takes the most time
Q&A: Document services replaced with entities
2009 to AX7: Data migration is preferable to data upgrade
Demo
Export modelstore
Zip it
LCS > Create project > Project settings > Azure connectors
Connect lcs project to azure and vice versa using certificate
Connect Visual Studio Team Server account
VSTS > Profile > Security > Personal access tokens
Deploy environment, recommend Azure. Issues locally with multiple developers. D13 or D14 are good machines. Use V2 for dev machine. D4 for build machine
Code upgrade > create job. Estimate only does not check anything in to Visual Studio
You can’t upgrade only one project, one model – you must upgrade the entire modelstore
Build box will be connected to VSTS automatically
Build machine can be changed: continuous integration
Recommend upgrade from R3 CU10, but the tool will accept lower versions
VSTS > project > code
What’s really happening?
Model management is there

Auto-migration rules
How does auto migration work?
Best Practice Framework
What is auto-migrated?
- Renamed and deprecated APIs, metadata
- Apply form patterns
- Deprecated controls (e.g. Segmented Entry Control and Dimension Entry Control)
Manual Upgrade
Use LCS links within your project
- Unparseable files
- Conflicts
- Compile errors
- Package/Model split extensions, events and delegates
- Form patterns
- Modern reports and BI
Tip: Use LCS for whitepapers and patterns learning
Demo
Manage workspaces, get latest, 3 solutions. 1. unparseable, 2. code merge, 3. upgraded
Open code merge solution
Building from the solution won’t work the first time
Build from Dynamics AX one at a time bottom up
Am I done?
This is for solutions to be on the marketplace
How to make it a “Dynamics AX” Solution
- Build your workspaces
- Get 100% coverage of form patterns
- Build your entities
- Extend or create rich controls
- Extend base AX (where possible)
- Integrate rich BI scenarios
- Fix BP errors and TODOs
- Record your task guides
LCS Solution Overview

Dynamics AX to Dynamics AX upgrade
Goals
Automate build to build migration
Keep history (check-ins and work items)
Trunk/main is your primary development branch
Branch Management
- Stop development on trunk\main
- Run VSTS migration
- Integrate from releases\version => trunk\main
- Complete trunk\main upgrade
- Done!
Preparing for the upgrade

I wish I knew this before I started my upgrade…
- Run Visual Studio as Administrator
- Embrace and love extensions and delegates
- Build packages from AX7 menu – not build solution
- Do not import Microsoft hotfixes to AX2012 as XPOs
- Check full error log if an error does not make sense (the full error log is in the model folders)
- Save $$$ by using Azure Automation Runbooks to shut down development environment overnight
- Remember to “Add Solution to Version control” to ensure your new elements are added to VSTS
- Check-in “Descriptor” file for your model to VSTS else your automated build will fail
- Do not customize Microsoft report designs, copy them instead. When Microsoft reports are updated they will be reimplemented, losing your changes
- If unsure how to upgrade a pattern, compare Microsoft code of AX2012 and the new Dynamics AX
There are deprecated APIs including filesystem ones
Happy DAXing!