Microsoft Dynamics Technical Conference, 2016 / Day 3 Session 4

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

1. Understand code migration approach for Dynamics AX and beyond
2. See a real solution being migrated
3. Discover how to prepare for Dynamics AX
4. 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

1. Stop development on trunk\main
2. Run VSTS migration
3. Integrate from releases\version => trunk\main
4. Complete trunk\main upgrade
5. 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!