Traditionally MS support upgrading to a new version from the two previous versions. So you can go upgrade to Ax2012 from Ax4 and Ax2009.
MS seriously focussed on minimizing the time-frame the Ax live system is unavailable by introducing a wel-considered upgrade procedure. Bear with me while we go through the concept:
- The upgrade process is partly executed on the old (current live) system, partly on the new (future live) system.
- The old system is checked for upgrade readiness: potential upgrade issues are detected. Some of them are show-stoppers and need to be resolved before upgrading can continue, some of them have an advisory goal. Showstoppers could be missing data conversion scripts for custom tables. Activating or adding performance boost scrips could be advisory items in the output list.
- The principle of using attributes in the upgrade classes makes is possible to easily define relations between different upgrade classes. So you can actually decicde exact where to anchor your classes in the existing upgrade order.
- Still in the old system, the application data is prepared for preprocessing. This means the current data is made ready for upgrade, or basically: a number out-of-the box classes handle the differences between Ax4/2009 and Ax2012 and makes sure the 'old' system gets all dressed up to smoothen the data conversion. Think for example of preparing currencies for upgrade, preparing financial dimensions, … or make sure the old datamodel is extended so that converting the data to the new system will be a smooth as possible.
- Preprocessing the actual data on the old system would be the next step. This requires a separate set of tables is created (in the AxDB) to pretty up the live data in order to ease the data copy later on. This is not touching the live data or affecting the availability of the live system. Shadow tables are added for the actual data-copying to expose all required data for the Ax2012 system.
- An important advantage here is that the workload of the preprocessing can be contolled: preprocessing tasks can be paused during office hours and continue at night for example. Another interesting thing is the concept of delta processing.
- Data needs to be preprocessed at once. You can plan this up front: let's say the weekend before the go-live-date the data is preprocessed. During the actual go-live-weekend, only the data that was touched since the previous preprocessing run is taken into account.
- During all the above actions, the old (current live) system stays online and available for users to work in, a large number of upgrade-task can be executed simultaniously (in parallel)
- Only the last step require a single-user-mode approach (downtime).
So the upgrade model of Ax2012 supports
- parallel execution of (pre)prosessing tasks,
- delta processing of data,
- up-front checks to make sure the source system reaches a full upgrade readiness
- a flexible way of adding in new custom upgrade classes
which all results in a minimum down time.
No comments:
Post a Comment