Looking for PowerObjects? Don’t worry, you’re in the right place! We’ve been part of HCL for several years, and we’ve now taken the final step in our acquisition journey: moving our website to the HCL domain. Nothing else is changing – we are still fanatically focused on Microsoft Business Applications!

PowerObjects Blog 

for Microsoft Business Applications

|

Dynamics 365 Data Migration Testing Best Practices

Post Author: Joe D365 |

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.

Test Plan 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.

Identify Entities

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:

  • Which field in the source is mapped to which field in the destination?
  • What are the list of fields in the source that no longer required in the destination?
  • What are the fields that can be retired and not migrated?

Test Execution Strategy

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.

Calculated fields

Ensure calculated fields in Dynamics 365 are correctly populated.

Opportunities

Ensure while validating Opportunities, the actualclosedate will be set to actualclosedate the opportunity is closed in the source system.

Activities

Individual activity entities like email, appointment, phone call, or task should be migrated individually with Owner correctly migrated.

Case/Activity Status

Ensure status of Cases and Activities are correctly migrated.

Record Validation

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.

Record Status

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.

Owner

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.

Field-to-Field Mapping

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!

Joe CRM
By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

One comment on “Dynamics 365 Data Migration Testing Best Practices”

PowerObjects Recommends