16. From Microsoft Dynamics AX 4.0/2009 only New hardware Bulk copy program (BCP) ~2500 target scripts Can upgrade into multiple partitions Fast database synchronization Source-to-target From Microsoft Dynamics AX 2012 only Existing hardware No BCP ~50 upgrade scripts Only upgrade into a single partition Longer database synchronization Upgrade in-place

17. Production Active on AX 3/AX 4 Production active on AX AX2009/ Ax4 Preprocessing Data Copy Post Processing Production Active on AX 2009 Production Downtime Upgrade operations 100% Upgrade operations 100% Downtime Single user processing Delta preprocessing Production active on AX 2012 Live on production Live on production Upgrade operations 80% Upgrade operations 80% Upgrade operations 20% Upgrade operations 20%

18. Create test system Create development system Upgrade customer model Test data upgrade Upgrade production system Duplicate existing production system to create the test system Run AX 2012 R2 setup on the test system and backup Duplicate test system to create the development system Import prepared R2 ISV models into development system Upgrade the code in other models for each higher layer Import upgraded model store into the test system Perform data upgrade on the test system Back up the database Upgrade the core production system Upgrade other server components and clients

20. Planning Technical upgrade with no functional analysis significantly increases project risk Merging companies or splitting data should be done separately before upgrade Downtime window requirements Hardware and database server review and optimization Functional specifications for moving/deleting/changing of customizations Metadata Always follow the checklist steps Never do preprocessing then import the AOD’s for code upgrade Never use xpo export/import for upgrades; if xpo absolutely required, make sure you keep IDs Never delete Data Dictionary elements; use SYSDeletedObjects If absolutely required only delete metadata on target SYSDeletedObjects62 is ONLY for In-place upgrade

21. Scripts for data upgrade How much upgrade script development is required? Consult with your VARs and ISVs to check if they have upgrade scripts in place As the overall project makes progress, code and data upgrade can complement each other Upgrading reports can be used as a data-validation exercise Data upgrade Always follow the checklist Perform Upgrade Readiness in production AFTER a successful complete end to end test run Use the State transfer tool to reuse work Run through cleanup routines in some Periodic menus and IDMF Several cycles to update the data: scripts for customized tables, unique data tuning, and repeating until the required time window

22. Performance Analyzer for Dynamics SQL Profiler and Microsoft Dynamics AX Performance Analyzer are useful for debugging performance slowdowns http://archive.msdn.microsoft.co m/DynamicsPerf License Existing Microsoft Dynamics AX 6.0/R1 license does not work in Microsoft Dynamics AX 6.2/R2 Data purging and archiving Do not purge/leave behind companies, upgrade all companies at once Purge and archive data via intelligent data management framework before upgrade Backups Back up database after each step!

23. User acceptance test Core business processes and key scenarios on upgraded database with your data and custom code in place Business scenarios that must be supported after the upgrade in order to make a go/no-go decision Trainings User trainings are very important steps and user acceptance tests can be used as part of that Multiple iterations Plan at least two full test runs that are successful prior to running the live upgrade Create a list of post-upgrade validation tasks and plan how they will be tested Security Additional time for designing and testing security setup

24. Post-upgrade tasks Static post-upgrade data analysis Rely on data upgrade test iterations to bring data forward to Microsoft Dynamics AX 2012 and test code upgrade Data verification Identify your key business processes/scenarios that must be supported by your Microsoft Dynamics AX 2012 instance All tests should have a high level of data validation testing Freezing Freeze for existing master data for preprocessing period is required Inventory dimensions and items need special attention

25. Check functional requirements Plan your upgrade project Analyze your source Check customer motivation Test the result Check and tune performance Make backups for every step Purge or archive historical data

28. Scoping and planning Proposals ranged from 12 to 16 weeks… … it took 9 months Waterfall vs. agile? We used scrum Risk management Size of the upgrade Work sequencing Testing Performance Context 60 users in accounting, finance and HR 260 GB database Trust process had the most customizations Change management User experience change Training and communications strategy Not a silver bullet Parallel testing Team and resources Hard to find the right resources. Requires lots of memory, disk space and processing power … more than we thought

29. Change Management The user experience change Training and communications strategy Not a silver bullet Parallel testing Team and Resources Not easy to find the right resources for an upgrade. The upgrade requires lots of memory, disk space and processing power … more than we thought

30. Change Management The user experience change Training and communications strategy Not a silver bullet Parallel testing Team and Resources Not easy to find the right resources for an upgrade. The upgrade requires lots of memory, disk space and processing power … more than we thought

33. Functional analysis Apples to apples upgrade. No process re-engineering Looked at new AX 2012 features that could result in less customizations Prepared training based on processes Technical analysis Engagement with the AX R&D team Decision matrix Infrastructure needs Iteration 0 Data upgrade Target schema Upgrade scripts development 5 initial iterations, then 7 more during parallel testing Smooth for the most part Code upgrade Code freeze struggles Followed best practice: EDTs and Base Enums -> Tables -> classes -> forms Had to rewrite all custom forms and all reports

34. Waves of testing, training, and then parallel testing Sunk cost on iteration 1 … bug in upgrade script Gotcha example – date effectivity example Some upgrade script recommendations: Changed standard upgrade script from row based to set based, reduced data migration duration from 55 hours to 5 hours Changed standard script to commit after every 1000 updates where while loops cannot be avoided

35. Benefits-based testing Prioritized on benefit and risk Plan for things to go wrong Discover rework early Invest in testing team and tools Performance testing Key processes performing slower in Microsoft Dynamics AX 2012 Performance review RDS versus Rich Client Going live Go live checklist Well versed in the process The first day in AX 2012 6 Weeks of stabilization Parallel testing Critical success factor All users completed their daily tasks on Microsoft Dynamics AX 2009 and Microsoft Dynamics AX 2012 7 full upgrades over 9 weeks

36. 127 steps, starting on a Wednesday preparing the upgrade and preprocessing and finished Sunday afternoon, ready for business

37. Day one, our servers crashed 30 minutes before the end of the day! Substantial memory leak bug forced us to restart servers by lunch time Performance of our business users better than ever

38. Conducted a performance review with Microsoft and implemented recommendations Shift from a value creation phase to value extraction phase Completed our upgrade to Microsoft Dynamics 2012 R2, which was a much smoother and smaller undertaking

39. Managing risks Engagement with Microsoft Dynamics AX R&D team Our planning Business buy in to the process Change management Parallel testing The checklist Access to resources