Tutorial: How to migrate to Microsoft Dynamics 365 for finance and operations from Axapta 3.0, 4.0, Dynamics AX 2009 or even 2012?
Migrate to Microsoft Dynamics 365: How can you upgrade from previous versions of Microsoft Dynamics AX? Today Microsoft has support Microsoft Dynamics AX 2012 R3 or from AX 2009. But what if you have a different version? Customizations? You want to implement again?
In the tutorial below we will demonstrate how you can migrate from Microsoft Dynamics AX 2009. For this tutorial we will create a mapping for customers and customer groups. It’s a nice demonstration of the great capabilities which will help you in different levels. So we will work towards a runnable project with a single button click! First we need to establish a connection to the on-premise database for AX 2009. After that we can initialize the mapping and finalize it. The tasks with dependencies can be used to run in the data migration project in the correct sequence and in parallel.
With the Business Integration Solution we have added nice features to simplify the migration, give you more control and you can do it without development!
Which steps are required to run a successful migration?
- Setup an ODBC connection
- Get the data model
- Create the messages and mappings for the tables you need
- Extend the mappings using the “Form mapping”
- Define the dependencies using tasks
- Setup the project to run a delta run
- Run the migration project
Below you can see the steps in detail for a sample migration from Microsoft Dynamics AX 2009.
Setup an ODBC connection
The first step is to setup a connection to your on-premise database. For that you need to install an agent and you’re ready to connect. You can read more details here.
Let’s just show the connector setup. In the connector you can specify the link to the Azure Service BUS and the ODBC connection to the database.
The ODBC connector can be added as source connector to the project.
Get the data model
There is a new feature to scan the data model and use that for the migration. From the design tab in the project you can open the migration.
Now we are able to select the tables from the source.
Now you can see all the standard and all the custom tables. You can build your list step by step. The top grid can be used to filter the table and using the plus sign the table will be added to the selection.
After the “OK” the tables are added.
Create the messages and mappings for the tables you need
Now we can create the message for the two selected tables.
Now we can open the customer mapping for example and verify the missing fields.
Which shows the list like below.
Extend the mappings using the “Form mapping”
As we know the remaining fields, the mapping should be created for the missing fields. Data entities are simplifying the data model, but there is no connection between a data entity and a form. And that makes it very difficult to test. Using the Business Integration Solution the mapping can be done using the form mapping by starting the recording. But before we can do this we need to initialize the form mapping based on the existing mapping.
And now we can start the form mapping. Navigate to the customer group form and select the mapping between the fields.
Use the plus sign to create a mapping for the selected fields.
And when this is finished we have a form mapping which can be used for testing purposes.
This is an easy setup of course. There are some remaining challenges:
- Global product table where you need to change it to a master product, product version or distinct product.
- Global address book where you need to change it to an organization or person
- Address information which is updated using a view instead of a table
- Contact information which is updated using a view instead of a table
- Financial dimension setup
- Inventory dimension setup
The huge benefit is that you can find the context, the form and in the background the data model, fields and edit methods.
Define the dependencies using tasks
Now we can put the messages in the right sequence using the tasks.
And the tasks are created with the correct dependencies.
Setup the project to run a delta run
When you have a migration which can be executed in more than four hours, you may want to check-out our “Delta-run” functionality.
In some case, you only want to import the delta. For example: Just before go-live you want to import the latest open transactions; however you do not want to run all the messages again because this is time consuming. In Connectivity Studio you can achieve this by using the option Delta run. In the tasks, you can define what message to run during a delta run. While you start the project - to run the related tasks - you can indicate that this run is a delta run.
Per task a set of messages can be linked. For each message can be defined if it should be executed in a normal run or during a delta run.
Running a delta means that it will only insert new lines and not update existing lines. So for master data it can add the new customers for example and transactions will only run when the delta-run is started.
Skip master data which is not changed during the latest run and go-Live to improve the performance!
Run the project
The project should be executed in the batch. When the project is executed, the tasks are executed in the batch too. Each message in the same task is running at the same time (in parallel).
After the run, the data can be validated in the history and using the form mapping can be validated if the field is shown correctly in the form.
Data migrations projects are seen as difficult. With the benefits shown above, a data migration can be controlled and be executed by the IT department. It’s not required to have developers involved in the project.
- 70% of the tables can easily be mapped and require minimal changes
- 0% of developers is required to create the migrations
- 100% of the migration can be tested multiple times from fields, tables to dependencies using tasks
- 0% risk as it runs always the same!
Hope this information is useful for you and don’t hesitate to contact us.