Best practices for development releases in AX 2012?

I’m an all around AX newbie and have been tasked with coming up with the formal processes and procedures for rolling out development projects into AX 2012. I am neither a developer nor AX professional so any assistance would be really appreciated even if it’s just steering me in the right direction. What do you even call such processes? Release change management? Development change workflow? I have tried researching the topic, but I’m starting to be convinced that I’m not even looking in the right places.

To break it down, these are the kinds of questions I need to answer. Which process do YOU follow from the start to finish of a project?

  • How do you manage and document projects? Every project will be required to have some sort of knowledge-base which explicitly explains what changes were made and why. This documentation will be necessary for auditors.
  • Where do you store this documentation? SharePoint? Some other collaboration site?
  • How and where do you document your AX projects?

Additional info
We have 3 AX environments. Development, Testing, and Production. Needless to say, the changes start from development, proceed to testing, then end in production. The issue is how these processes are managed and documented!

Thanks in advance for anyone willing to help!

I am pretty new with AX as well. We have the same structure in terms of environments (DEV/TEST/PROD).

Requirements document

  • I use a template change-request document that gives all the details my company needs. ie - state of the project (planning/in development/released/etc), details of mods/new items, business rules, etc. This should probably include everything that you would need for auditing.


  • We use shared network drives as well as Sharepoint. Sharepoint can be nice when working in teams to collaborate. You can integrate some kind of version control so you don’t have multiple people modifying a single document at a single time.


  • We use the requirements documentation (change request) to record our proposed changes and our actual changes. This can include as much info as you need, though the more info the harder to keep organized.
  • In AX we make sure that anything we change goes into an AX project. The icon to access them is next to the AOT icon in the top menu bar. You can add groups to organize items changed and you can simply drag and drop or create new objects to change/create. This way you don’t forget anything that you may have changed in the AOT (there are a TON of objects and its really easy to loose track). This makes exporting and import changes into environments very easy and modular and easy to track/document (name the projects something meaningful).

I hope this helps. Bottom line: Requirements doc/change request doc, and AX Projects. These are easy ways to keep track of the endless number of changes you can make in AX

Hi … Just some interesting reading for you that may be of use. Not aimed at AX specifically, but in general terms.

Google this - waterfall development, and this - waterfall development methodology

Excellent reply! Would you be willing to email me one of your real change-request documents?

Will definitely check out. Thanks for replies all!

Message me your email and I can send you a copy of our templates.