Before you begin Data Migration

Do you know your current data? 

• What is a normal record versus an exception? Do you are your users know the difference and how exceptions should be handled?
• Do you know all the tables and relations in your system? Make sure you understand where the data on screens and reports actually comes from and how it is related.
• Is your historical data valid? Are address and contacts correct? Are there old items that need to be updated? Fix your data in the legacy system before migration.
• How much customization has been done on your legacy system? - Have changes in your data schema changed data over time? Sometimes adding new fields or re-purposing fields makes older entries invalid. 

Where will the data come from?

• Is it all in your legacy ERP? Having all data come from one source will simplify migration.
• New data. Are you adding data to your legacy data? Be careful of Migration by Excel.
• External/Integrated systems? If you are integrating with other systems, or combining multiple systems into AX make sure you understand what data is coming from where. How will you handle de-duplication/redundant data. How will you fill in gaps from legacy systems into AX schema?
• How will you manage multiple streams with updates? Make sure someone is in charge and the keeper of the data. They need to where everything is coming from, its correct format and any transformations done on it. Keep everything documented. 

Areas to watch out for:

• Reporting / Data warehouse use– do your reports really reflect the actual data in the system or is the output changed. Verify the data the users see, can be tied back to the data in the database. If not, start working to determine what is the truth in your data and make corrections as needed.
• Addresses – AX will validate that City/State/Zip match. If the addresses in your legacy system do not match the city/state/zip combinations in AX, the imports will fail. Another area is systems that allow free text entry of address blocks. AX needs the information separated.
• Bad/Old Data hidden by default views. Do any of the default views in your legacy system automatically hide/no show older data or bad data? Are there open transactions that users do not see because of views but are still open in the raw data? Have customization's hidden data that no longer matches the new schema but still exists in the database? 
• Do your core team members understand all data across the business? Make sure the core users understand everyone and every segment of your business, not just the customer/vendors/items they work with daily.
• What data required for system integration's? Are you bringing over all the data required? Will the format from AX work? Make sure that the data size in AX matches what is required for the input/output from integration's and test them.
• How will the system be frozen for test runs and validations? You need to freeze the data to have a system you can validate against. Make sure you plan how this is accomplished and where the frozen data will be.

More considerations:

• Data migration versus data entry. Always look at data entry as a method of moving data. Assess the costs of having someone hand key the data versus expensive IT resources working on a one time activity.  
• Migrate early! - Data can play a big role in how the system functions. Data migration should start on day one of your project. Having full data loads will allow you to properly asses performance and exceptions in the system.
• Do you need all the data in AX, or is a Data Warehouse a better approach? By moving some historical data into a DW, you can complete some of the work before go-live. This will reduce the amount of work needed on go-live. You will get the benefits earlier and this data/reporting can be managed outside of any other future upgrades. 
• Practice with a complete data set. Make sure you practice complete migrations and understand what order the migration needs to happen in. Practice by providing data for CRP/UAT and just to make sure you can do it right.
• Data freeze before go-live. Set a time when you will either stop changing master data in AX, or start a dual maintenance process. This is key so there are no gotcha's on go-live weekend.