This is my fourth post on Data Migration for AX following Data Migration Approaches for Dynamics AX, Data transformation during data migration and Before you being Data Migration.
Today I am going to talk briefly about what happens after the Data Migration has been run. How do you validate the data and how to approach any Misses or Errors.
Today I am going to talk briefly about what happens after the Data Migration has been run. How do you validate the data and how to approach any Misses or Errors.
Data Validation
There are two sides to data validation, validation for the IT/Technical team and validation for Business users. The IT teams validation tends to focus on numbers and error counts, while the Business users should be focused on data quality not just that all the records arrived. The business users should have been providing constant feedback to the technical team through all the trial runs and conference room pilots. One of the biggest issues encountered in data migration tends to be records created between the last CRP/UAT and go-live. I recommend a program of freezing data or to use double entry to avoid this, instead of finding unknown data at the last minute.
How does IT validate if you can’t look at every record?
- Number or records - make sure you have the correct number of records in every table. Create SQL scripts to compare and validate and use these as part of every migration run.
- Understand how many records there should be for each table - most tables in AX will have a 1:1 relationship with the source, while some will 1:n relationship. Make sure you understand how many records should be in each table. Special care should be paid attention to all the Item Master tables.
- Total Quantities – Make sure the total quantity ordered/open matches for Sales, Purchases, Work Orders, Transfer etc. Have a SQL Script for this.
- Do this check also by Customer/Vendor/Item to have a second level deeper check. This helps to confirm everything matches up when it comes over.
- Total Dollar Value– Make sure the total dollar value of ordered/open matches for Sales, Purchases, Work Orders, Transfer etc. Have a SQL Script for this.
- Do this also by Customer/Vendor/Item to have a second level deeper check. This helps to confirm everything matches up when it comes over.
- Consistency Check - learn to use the Consistency check as part of trial runs. It will help you find items that got missed on related tables.
- Ultimately practice will show where to check for errors
How does Business validate if they can’t check every records (Hash totals)
- Business should be receiving the record count reports from IT to validate
- The business should practice using hash total reports to compare critical data between systems. These reports should be run as part of UAT and your last CRP. Make sure that the reports can easily be exported to Excel to allow for comparison. Lastly and most importantly, keep copies of the reports and the queries/parameters used to run them so you can make sure any differences at go-live are not due to someone running the report differently.
- The timing of hash total reporting is critical - as you may still be closing the books in your old system when data migration runs, there is no reason to run a trial balance until it is ready. Create a schedule with owners for each report and make sure they understand what is required.
- Verify all the users have the access they need to both source and destination so there is no slowdown in running the reports.
- Some areas of the system should be checked with spot-checks of records in the destination - Customers/Vendors/Items. Everyone should understand what fields should be populated and what valid values are. Lastly, experience through trial runs should inform users where to check first.
- Make sure you understand what the source and destination reports are and how to cross-reference them if data was changed as part of migration.
- Some sample reports commonly used for Hash Totals - this is not exhaustive and should be validated against what data you are migrating:
- Trial Balance
- AR Aging
- Open Sales Orders
- AP Aging
- Open Purchase Orders
- Fixed Asset Balances
- On-hand Inventory
- Inventory by Dimension/Item group
Dealing with errors/misses
So, you have completed data migration and found something. What do you do? The first question to ask is - What is the impact on the business versus cost/time to fix versus compliance requirements? You will need to consider all three when coming up with a solution. If there is little impact on the business, can you simply ignore and fix as you go on? Is the cost to the business to be down a little longer small enough to re-run/restart something? Is it a financial reporting/compliance issue that must be fixed regardless? Have a team available to discuss from all sides before rushing to a fix.Did you find the issue before transactions started?
- Can you delete the data and re-run the migration?
- Can you hand key any missing data?
- If it is just a field or couple of fields missing, can you use SQL to update the records?
- Is your data good enough for transaction integrity that can be updated properly later? I am thinking about reference/informational fields here.
- Did you try a Consistency Check to verify and potentially fix?
- Learn the Rename field option in AX to fill in missing records
- Can you load data to a test system and then use export/import to production?
Did you find the issue after transactions started?
- Make sure you find the source of the problem, not just the symptom.
- Can you stop processing transactions in that part of the system while a resolution is found?
- Make a copy of the production environment and use it to test fixes.
- Is the impact financial/compliance related? Then these will need to be properly addressed. Make sure any fixes are fully documented.
- Can you use SQL to fix? Again, make sure the fixes are documented and signed off.
- Lastly, have a plan agreed to by everyone.