Migrating Custom Code to Microsoft Dynamics AX 2012

Overview

A Microsoft Dynamics AX 2012 upgrade contains several steps, as shown in the following illustration.

Planning Code Upgrade

Each code upgrade is different. Here are three key considerations for code upgrade process:

1. New feature that replaces existing customization.

In some cases, a new Microsoft Dynamics AX 2012 feature will replace the client’s existing customization. When planning code upgrades, identify such customizations and choose not to upgrade them as they have been replaced by the Microsoft Dynamics AX 2012 feature.

2. Microsoft Dynamics AX 2012 refactoring that impacts the client’s customization.

In some cases, Microsoft Dynamics AX 2012 features have changed and the change will impact the client’s customizations. You must identify which customizations are impacted. There are two categories:

• Required changes
• Optional changes

3. Upgrading standalone code.

In some cases, partners/customers have added new codes (tables, classes, forms, reports etc.) which are not directly dependent on Microsoft. In such cases, you need to make sure the customization is completed and running successfully in  the Microsoft Dynamics AX 2012 environment.

Migrating the Custom Code

Before migrating the custom code, determine if entire functionality needs to be migrated or only part of the process needs to be migrated. Once confirmed:

1. Identify the standalone code customers have added (like tables, classes etc.) as well as the standard AX objects modified.

2. Create a project containing all modified and/or new objects by a particular custom process.

3. Export the project to the shared directory. Make sure you are exporting the code from the correct layer. Usually  the customer’s customization exists in the CUS layer.

4. Start the Microsoft Dynamics AX 2012 client development environment. Make sure you are connected to the desired layer and select the appropriate model as your current model.

5. As far as the standalone code is concerned, it can be imported into Microsoft Dynamics AX 2012 directly as the code has no dependency on the standard Microsoft Dynamics AX 2012 code. In order to minimize the compilation errors, import objects in following sequence:

• Import Enumerations (Enums)
• Import Extended Data Type (EDT)

Migrating EDT relations – In Microsoft Dynamics AX 2012, EDT “Relations” node is replaced by “Table Reference” node.

Following properties are used to track EDT relation

• Import Tables

Make sure table relations, delete actions, indexes and table properties are migrated correctly.

• Import Forms
• Import Classes
• Import and/or Create Menu Items
  • Display menu items – These are used to provide access to forms.
  • Output menu items – These are used to provide access to reports.
  • Action menu items – These are used to provide access to jobs, classes.
• Import Menus

6. Understand the customization done to the standard Microsoft Dynamics AX 2012 objects and manually move the custom code to the respective object. Compile the object and make sure there are no errors.

7. Migrating reports – Microsoft Dynamics AX 2012 no longer supports AX reports. Microsoft SQL Server Reporting Services (SSRS) is the primary reporting platform for Microsoft Dynamics AX 2012. A new SSRS report needs to be developed in Microsoft Dynamics AX 2012 for existing MorphX and/or SSRS reports in earlier Microsoft Dynamics AX versions.

Converting existing MorphX report into SSRS report –

• Examine the existing MorphX report – determine the data source used for the report, run the report to understand the input parameters, understand the relationship between different data sources used.
• Define the SSRS report data source – Determine which type of data source is appropriate for the SSRS report.

• When custom business logic is needed, create a report data provider class which contains the X++ business logic to produce a dataset for the report.
• In AOT, create temporary table to store report dataset.
• Define the report in Visual studio, generate precision design in SSRS report based on Generated design.
• Compile and deploy the report.
• View the report in AX by creating a menu item.

8. Migrate Security – Microsoft Dynamics AX 2012 supports role based security; access is not granted to individual users, only to the security role. Users are assigned security roles. Security will not be migrated automatically; they must be defined in Microsoft Dynamics AX 2012 as necessary.

9. Make sure all custom objects are compiled, synchronized and running successfully in Microsoft Dynamics AX 2012.

10. If the development environment is integrated with a version control system such as Team Foundation Server (TFS) , follow these steps:

• For all new objects created, add them to version control
• Check all changed objects in version control

11. Create labels.

You can learn other valuable tips and insights through our Dynamics Community Newsletter or contact our Microsoft Dynamics AX 2012 experts at RSM or 855-437-7210

by: Shamika Kshirsagar

Kimberlee Laughlin