Upgrading to the Next Version of Dynamics Ax

We are all faced with doing an upgrade to the next version of Ax and when faced with this we have to review all of the customizations having been done to upgrade / change / remove them depending upon their relevance.



This part of an upgrade project can from experience take between 10% of initial development effort all the way up to and including 100%+ of the initial dev effort depending upon what and how modifications were done.



The 100%+ example list of do not do's are :



-:

Changes to std BaseEnums sequence and related code, f.ex. I had a customer / consultant precede me on a case where they decided it would be a good idea to change the salesorder type enumerated type and add some new types in the middle of the list :-(. Upgrading this was an unnecessarily big job if they had just created them at the end with a big gap in the enum it would have been much less of an issue anyhow.



-:

Duplication of classes and calling these duplicated classes instead of the standard class, the problem here is that the layers mechanism of resolving / helping upgrade is negated and one is forced to export the class and do a manual external comparison.



-:

Writing code in unusual places, that is in screen buttons, on the datasource of screens, in the datasource fields on screens.



-:

Changing the standard data structure relationships in data as well as classes.

Partial list ends here TBC

Take Care

Sven