How do I check that CRM record links survive a platform migration?

Make two inventories, and give each item an owner and a way to verify it.

1. Record relationships: list the record types, relationship or lookup field, parent record, and dependent records that refer to it. Include important cross-team relationships. Note records intentionally excluded so they are not mistaken for failures.
2. URLs: list the fields, buttons, or other places where users find links. Record each link’s purpose and destination type: another CRM record, a document system, a portal, or the old CRM. Keep passwords, tokens, and sensitive customer details out of the checklist.

For each entry, capture safe test examples using placeholders, such as [source record ID] and [expected destination]. Microsoft’s guidance for its Salesforce-to-Dynamics 365 migration path recommends moving parent records before dependent records so lookups can resolve, and identifies missing parents as a cause of lookup-resolution failures. That guidance is specific to this migration path. [S1]

Agree on expected results before the migration, then compare the new CRM against that baseline. Reconcile counts for relevant record types, but don’t treat matching totals as proof that individual relationships are correct. For a sample of parent records, check that expected dependent records appear; for a sample of dependent records, confirm the lookup points to the intended parent. Include important record types and known exceptions.

A simple test row could look like this:

Test case: [dependent record ID] | Expected parent: [parent ID/name] | Actual parent: [observed value] | Result: Pass / Fail | Notes: [details]

Use actual identifiers only in a suitably controlled work document. Microsoft recommends reconciliation and spot checks of lookup relationships for the migration path its guide covers. [S1] Your team must define a sufficient sample and resolve failures; the guide does not prescribe a sample size or establish that all records are correct.

Treat these as a separate URL test: checking a record relationship won’t show whether a clicked address works. Group links by destination and purpose. Test representative links from the new CRM using the role and sign-in context intended for the user. Check that each opens the expected item, not just a landing page or access-denied screen.

For old-CRM addresses, ask the migration or platform team about a supported replacement or redirect plan. Don’t guess a new address by changing part of an old URL. Log results as working, needs replacement, access issue, or not tested, with an owner and next action. The cited guide does not establish how to inventory or validate external-system links or source-app URLs, so plan those checks with the relevant system owners. [S1]

Use this handoff template and fill in the bracketed details:

CRM link verification plan

• Scope: [record types, teams, and systems]
• Owners: [relationship and URL owners]
• Baseline: [counts, key relationships, and test examples captured before migration]
• Post-move checks: reconcile agreed counts; inspect sampled lookups in both directions; open sampled URLs in the intended user context.
• Exceptions: [known exclusions or special handling]
• Failure log: [test case, expected and observed results, owner, next action]
• Sign-off: [reviewer confirms checks are complete or lists unresolved items]

Run the checks in a test environment first if available, then repeat the agreed checks after the final migration. Keep failures visible; matching totals alone are not a reason to mark the plan complete. This is a planning template, not a guarantee that every relationship or link is covered.