If you are moving from Dynamics 365 On premises or any platform to Dynamics 365 Online or earlier versions of CRM, you will need to migrate your data. In this blog, we are sharing a list to check when creating a Test Plan and Test Execution strategy for Data Migration Testing.
Scope of Migration
Analyze the Scope of Migration for your project or instance. Migrating the entire data in Dev/Test/UAT environments and getting a signoff at each phase is time consuming. Hence, you need to check with stakeholders/Business owners and be in an agreement for full or partial data migration (Subset of data per entity) in lower environments like Dev/Test and full data migration in UAT/Production.
Before jumping into migration testing get a checklist of all entities that need to be migrated. Get it reviewed with business Owners and add any entities that were missed.
Determine the order of validating entities
It is crucial that you validate the entities in order so that the data referenced in lookup fields are present when the record is validated. For example, you need to have your accounts in the system before you validate opportunities.
Determine the Cut-off Date
Check with business owners on the Cutoff Date for Old History Records. Consider whether history records over a certain number of years from old system should be migrated into a new Dynamics 365 system. For example, do history records over five years old need to be in the new Dynamics 365 system?
Field to Field Mapping sheet
Get the field-to-field mapping sheet from source to destination. Ask the following questions:
Your test cases should cover the below scenarios for each entity:
Service Account for Master Data
Ensure that owner of Master data is not a specific user in the team and it should be Service Account.
Lookups and References
Ensure all the look up on the Dynamics 365 CRM forms has the correct data
Perform a Limited Test Migration
Start validating with limited set of sample data for each entity and ensure data is migrated for all the fields from source to destination.
Unique identifier in CRM
To identify a record uniquely in Dynamics 365, use the GUID of the record from the source instance to the destination Dynamics 365 instance.
Created On date
Created On date of the CRM record should be the actual Created on date in the source and not the date the record was migrated into Dynamics 365.
Ensure calculated fields in Dynamics 365 are correctly populated.
Ensure while validating Opportunities, the actualclosedate will be set to actualclosedate the opportunity is closed in the source system.
Individual activity entities like email, appointment, phone call, or task should be migrated individually with Owner correctly migrated.
Ensure status of Cases and Activities are correctly migrated.
Ensure you open at least a record for each entity and check if any errors are displayed. Chances are that you might miss importing a mandatory field and then you get an error that could be easily caught.
Console App to validate count of records
Some entities like Accounts/Opportunities/Contacts might have lots of records. From an advanced find, we can get only 5000 records at a stretch and its time consuming to review data in this small set. Hence, check with the dev. team for a console application that can run against each entity so you can find the record count easily and compare with the source and destination in Dynamics 365.
Ensure to validate status field for CRM records. In source application, there might be different status like the Active/Pending Closure/Closed. In this scenario validate that all types of status should be available in destination, especially if you have created unique status reasons.
Validate that the Owner is not the System user who is used to migrate the records but that it’s the user who created the record, or owns it in the source environment.
Validate field-to-field mapping with the source application to Dynamics 365 against the data-mapping sheet.
Involve the Business Users Early in the Cycle
In addition to checking the data and matching counts of the source and target data, you can have business users review and test the data. The users know the data. It’s important to have testing scripts identified for data testing rather than “eyeballing” the data and assuming it looks right.
Lastly, we recommend executing smoke test cases and business scenarios against the system and then providing a Sign off on the Dynamics 365 data migration testing.
For more Dynamics 365 tips and tricks – subscribe to our blog!
Happy Dynamics 365’ing!