As announced in 2016 Microsoft has published a prelease for Data Migration from 
Dynamics AX 2009 to newest Dynamics 356 for Operations. What we can expect an what does it in the real life.
As Data Entities in Dynamics 2009 are not real existing the great step is to map mostly used AX 2009 tables to Dynamics 365 for Operations entities. So i saw round about 1.400 AX 2009 tables that are prepared to be transported via Data Migration Tool to the new D365 fOps environment.
Prerequisites
As Dynamics 2009 Environments are mostly installed with earlier SQL Server Versions the main SQL Platform in the field should be SQL Server 2008, as well as later Versions are supported. Depending on the SQL Server Version some specific setting have to be applied, as well as SSIS is needed for the process. Access Database Engine, DIXF Services Installation, AX 2009 X++ Components and AX 2009 Client binaries have to be installed. Dynamics 365 for Operation needs to be Platform Update 4 or higher. The ERP Application has to be registered as APP in Azure AD to get access to the Dynamics 365 fOps. Environment. For details of the required setup steps a documentation is supplied by Microsoft. Currently the Data Migration Tool is available for Partners who request this, otherwise it will be delivered with availability of the next Dynamics 365 for Operations release.
What to do with Standard Tables
For multiple areas (e.g. Accounts receivable, Accounts payable, …) exist predefined Data Migration Groups each with a set of tables belonging to the specific area. Each Group contains multiple tables which can be migrated within on data package. A Data package in the meaning of Dynamics 365 for Operation is a set of tables belonging to one or more entites and can be consumed by Dynamics 365 Data Import and Export. Applying the Data package can be done interactive, remote or driven by LCS.
To select and delimit the data of the exporting environment a native “select”-Statement can be supplied with default queries and adjusted for each source table, e.g. to select data only created after specific historical date.
So the procedure is to declare a Data Migration Group in Dynamics AX 2009 which contains multiple AX 2009 tables, maybe delimited through are pure SQL sequence. These tables are mapped by the Data Migration tool to the coresponding Dynamics 365 fOps entities. While exporting the tables, the coressponding data packages will be created. By Default the tool can recognize dependencies inside a package and creates sensful sequence to import. If selected, the data packages can be automatical moved and applied to the connected D365 fOps environment. If required Master Data and parameters are set correct in the new environment the package should be applied successful. If not you have to research inside the Data Import Export in D365 fOps to find out missing but required source tables or settings. By default the Name of exporting legal entity is used to identify the importing legal entity. If this doesn’t match it will not work properly. The Name of the legal entity is transported as a part of the package name transfered to the target. So the legal entity in Dynamics 365 fOps has to be created with the same name as in Dynamics AX 2009 before starting the Data Migration process.
If you have done Data Import and Export with Dynamics 365 fOps you know it will be a iterative process to succeed. Validation of the data to import is the critical issue and success factor for the data migration process. For most of standard tables in Dynamics 2009 this will be a good approach to migrate System Configuration and Parameters, Setup of Financial, Customers and Vendors, most Master Data and open documents to Dynamics 365 fOps.
What to do in case of modification
If modifications in the source System are present the Data Migration Tool can not automatical map the tables and fields found to a probably not existing Dynamics 365 fOps entity. This can be seen at a glance as a missing mapping in the Data Migration Tool because the Tool does not find and can not assign a target entity. So if Customer needs the prior modification in the future version the customizing needs to be verified, planned and realized if the features are not mappable as a standard feature in D365 fOps yet.
Apart of the Process to generate the Customization in D365 fOps the Data Migration Tool can deal with customized tables if following prerequistes are present in target system.
- Custom Tables
- Custom Entity
- Custom Staging Areas
- Mapping for Custom Entity
Summary
So as one part of a overall migration scenario the Data Migration Tool is essential and helpfull organzier
- to get an overview of data to migrate (what, how much and what is related)
- to recognize misconfiguration in the target database schema (e.g. done by pure SQL)
- to build and configure the Data Migration Groups as needed
- to export, deliver and import to the new einvironment
- to verify Data Import in target system
After this is gone through the DEV and TEST Sandboxes a cutover plan should be created for deploying essential Data to the new productive Dynamics 365 for Operation Environment.