Microsoft Dynamics AX Support

This blog contains posts by the Microsoft Dynamics AX Support teams Worldwide

Moving between Microsoft Dynamics AX 2012 Environments

Moving between Microsoft Dynamics AX 2012 Environments

Rate This
  • Comments 9

Moving between Microsoft Dynamics AX 2012 Environments


It is common practice to restore a Microsoft Dynamics AX database from one environment into another environment for testing and development purposes.  In most cases, this is not a problem but there are circumstances that need to be considered to get the restored database
functioning.  The scope of this document covers settings such as server names, domain names, user accounts, and URLs that may need to be changed in the new environment. 

In Microsoft Dynamics AX® 2012 RTM (6.0), the application code files are stored in the same database as the transactional business data and in Microsoft Dynamics AX® 2012 R2 (6.2) there is a separate _model database.  Both database implementations require further
planning to move environments.

There are special circumstances where there are AOT based metadata and matching SQL database records that need to be moved together, such as customized security or workflow objects.  The topic of moving code will not be covered here, but you can refer to Microsoft Dynamics AX 2012 White Paper:Deploying Customizations Across Microsoft Dynamics AX 2012 Environments.

Consider the following scenarios where users may need to restore a Microsoft Dynamics AX database to a different environment:

  1. Testing a Microsoft Dynamics AX service pack, rollup, or full version upgrade.
  2. Bringing Microsoft Dynamics AX 2012 data in house for testing or development.
  3. Restoring a copy of the production database into a test or development environment to
    work with the most recent changes.
  4. Moving a production database from one Active Directory domain to different production
    Active Directory domain environment.

In most scenarios, users should have the base Microsoft Dynamics AX 2012 software installed in the new environment and running at the same service pack and rollup version as the environment where the database was backed up.  This would not apply to scenarios where users are testing a service pack, rollup or full version upgrade.

At a high level, the process for moving the database from one environment to another will follow these steps:

  1. Restore the database and set proper SQL permissions.
  2. Provide correct Microsoft Dynamics AX
    user credentials to allow users to connect and login with a client.
  3. Configure the base system functionality for those setting which may have changed.
  4. Install or configure additional components such as Business Intelligence and Enterprise

The specific requirements of a user's particular scenario may include additional steps or steps in a different order.  This document is designed outline common considerations.  Having a good understanding of the installation process and all the integrations and touch points will aid users in adapting the process to their needs.

 This is a summary of the full document attached below, which has also been updated to add additional information on Microsoft Dynamics AX® 2012 R2 (6.2)


Attachment: 112013_AX2012-TechDomain_M05_MoveEnvironment_edited.docx
Leave a Comment
  • Please add 7 and 3 and type the answer here:
  • Post
  • Thank you for sharing. Your last link just takes me to a list of AX 2012 trainings. Which of this trainings has the article on moving environemnts? What is the module number?

  • Larry you are a lifesaver

  • I second that, Justin.

  • Has this changed for R2?  Has it been updated?

  • Are there any other methods for moving a production database from one Active Directory domain to different production Active Directory domain environment?

  • The steps for moving a production database from one Active Directory domain to different production Active Directory domain environment, may not be too involved depending on if it is just the database that will move and no other servers that will change.  If that is the case then you are going to mostly be concerned about the AOS service account that need to connect into the database and the changing the AOS configurations to point to that database.  

    If the situation is that all server will change from one AD domain to another then a re-install of those components would be recommended.

    I don't know of any real changes that need to be adjusted for AX R2 and the addition of partitions.

    Please let me know if there are other components like Retail or Management Reported that also need to be covered.

  • Updated the documents to include some Microsoft Dynamics AX® 2012 R2 (6.2) information.

  • Good stuff--thanks for documenting this.  I have gone through the process and the part about re-registering the basic services--that button is not present.  I thought it might show up after I deleted one, but it didn't.  Is there another way to re-register the basic services or to get that button to appear?  Tried opening it in developer VAR and CUS, etc. with no luck.



    Hi Tony

    Open the AifService form, and click on 'Refresh' and this should re-register all the services.


  • Thank you for sharing this info with us. I have created two nice SQL scripts for all this and also included some other tables to be restored as well and truncated (for example SYSBREAKPOINTLIST and SYSUSERLOG) and we have also added some tables in the scripts for customizations and add-ons :)

    But still a question :

    In AX 2012 R3 we have new functionality and so also new tables. One of this is the Mobile Device Portal. Can you tell me which tables are effected/used by this functionality ?



Page 1 of 1 (9 items)