When a move from AX 2009 to Dynamics 365 Finance & Operations comes up, one of the topics we focus on most is how to migrate the customizations developed over the years. In a system that has been in use for a long time, tables, classes, forms, and reports become part of the way the company operates. Identifying which customizations are still needed, understanding the existing business logic, and adapting it to the new version form an important part of the transition.

There are significant differences between the two versions from a development perspective. Finding the Dynamics 365 equivalent of an AX 2009 form, report, or modification to a standard object is not always straightforward. While we can migrate some structures in a similar way, others need to be reconsidered using the methods available on the new platform. Compiling the code alone is not enough, either. We need to check that forms, reports, and business rules work as expected.

So where can we use AI in this process? How can we establish a workflow for understanding X++ code, identifying dependencies between objects, and generating code suitable for the target version? This is one of the topics I have been working on recently. I believe we can use AI more systematically in the code upgrade process, particularly when we define transformation rules in advance and regularly validate the generated results.

In this article, we will use XPO files exported from AX 2009 as our starting point. We will examine the source objects with Claude Code, establish transformation rules, and migrate them to the metadata XML structure used by Dynamics 365. Throughout the process, we will discuss which changes are mandatory, where decisions are needed, and how we can check the generated objects. Using a car rental module, we will examine tables, forms, and the conversion of MorphX reports to SSRS step by step.

One point I particularly care about here is being able to trace the reasons behind the changes. We should be able to see how a field, method, or relationship is represented in the target version. When we find an error in the source code, we should also be able to distinguish it from the changes required for the version upgrade. The rule set and decision records we create will help us both control the transformation and reuse the knowledge in subsequent development work.

The scope of this article is the migration of application code and metadata structures. Migrating transaction data, balances, and historical transactions requires a separate effort. Here, we will focus on the process from code analysis through compilation in the target environment, using the forms, and generating report output.

Before we begin

Before moving on to code migration, we need to prepare the source files and the target development environment. It is just as important for AI to know which structure to use when creating objects and how to validate them as it is for it to read the source code. We will therefore begin by bringing together XPO files, labels, working examples from the target environment, and compilation tools.
Read more