In this article by Yogesh Kasat and JJ Yadav, authors of the book Microsoft Dynamics AX Implementation Guide, you will learn one of the important topic in Microsoft Dynamics AX implementation process—configuration data management.

(For more resources related to this topic, see here.)

The configuration of an ERP system is one of the most important parts of the process. Configuration means setting up the base data and parameters to enable your product features such as financial, shipping, sales tax, and so on.

Microsoft Dynamics AX has been developed based on the generic requirements of various organizations and contains the business processes belonging to diverse business segments. It is a very configurable product that allows the implementation team to configure features based on specific business needs. During the project, the implementation team identifies the relevant components of the system and sets up and aligns these components to meet the specific business requirements. This process starts in the analysis phase of the project carrying on through the design, development, and deployment phases.

Configuration management is different from data migration. Data migration broadly covers the transactional data of the legacy system and core data such as Opening balances, Open AR, Open AP, customers, vendors, and so on. When we talk about configuration management, we are referring to items like fiscal years and periods, chart of accounts, segments, and defining applicable rules, journal types, customer groups, terms of payments, module-based parameters, workflows, number sequences, and the like. In a broader sense, configuration covers the basic parameters, setup data, and reference data which you configure for the different modules in Dynamics AX.

The following diagram shows the different phases of configuration management:

In any ERP implementation project, you deal with multiple environments. For example, you start with CRP, after the development you move to the test environment, and then training, UAT, and production, as shown in the following diagram:

One of the biggest challenges that an implementation team faces is moving the configuration from one environment to another. If configurations keep changing in every environment, it becomes more difficult to manage them. Similar to code promotion and release management across environments, configuration changes need to be tracked through a change-control process across environments to ensure that you are testing with a consistent set of configurations.

The objective is to keep track of all the configuration changes and make sure that they make it to the final cut in the production environment.

The following sections outline some approaches used for configuration data management in the Dynamics AX project.

The golden environment

An environment that is pristine without any transactions—the golden environment—is sometimes referred to as a stage or pre-prod environment. Create the configurations from scratch and/or use various tools to create and update the configuration data. Develop a process to update the configuration in the golden environment once it has been changed and approved in the test environments.

The golden environment can be turned into a production environment or the data can be copied over to the production environment using database restore.

The golden environment database can be used as a starting point for every run of data migration. For example, if you are preparing for UAT, use the golden environment database as a starting point. Copy to UAT and perform data migration in your UAT environment. This would ensure time you are testing with the golden configurations (If the configuration is missing in the golden environment, you would be able to catch it during testing and fix your UAT and the golden environment too).

The pros of the golden environment are given as follows:

• The golden environment is a single environment for controlling the configuration data
• It uses all the tools available for the initial configuration
• There are less number of chances for corruption of the configuration data

The cons of the golden environment are given as follows:

• There is a risk of missing configuration updates due to not following the processes (as the configuration updates are made directly in the testing and UAT environments).
• There are chances of migrating the revision data into the production environment like workflow history, address revisions, and policies versions.
• There is a risk of migrating environment-specific data from the golden environment to the production environment.
• This is not useful for a project going live in multiple phases, as you will not be able to transfer the incremental configuration data using database restore.
• You must keep the environment in sync with the latest code.

Copying the template company

In this approach, the implementation team typically defines a template legal entity and configures the template company from scratch. Once completed, the template company's configuration data is copied over to the actual legal entity using the data export/import process.

This approach is useful for projects going live in multiple phases, where a global template is created and used across different legal entities. Whereas, in AX 2012, a lot configuration data is shared and it makes it almost impossible to copy the company data.

Building configuration templates

In this approach, the implementation team typically builds a repository of all the configurations done in a file, imports them in each subsequent environment, and finally, in the production environment.

The pros of building configuration templates are as follows:

• It is a clean approach.
• You can version-control the configuration file.
• This approach is very useful for projects going live in multiple phases, as you can import the incremental configuration data in the subsequent releases.

This approach may need significant development efforts to create the X+ scripts or DIXF custom entities to import all the required configurations.

Summary

Clearly there are several options to choose from for configuration data management but they have their own pros and cons. While building configuration template is ideal solution for configuration data management it could be costly as it may need significant development effort to build custom entity to export and import data across environments. The golden environment process is widely used on the implementation projects as it’s easy to manage and require minimal development team involvement.

Resources for Article:

Further resources on this subject:

• Web Services and Forms[article]
• Setting Up and Managing E-mails and Batch Processing[article]
• Integrating Microsoft Dynamics GP Business Application fundamentals[article]