Skip to content
Notifications
Clear all

Sharing my post-migration checklist - 50 items to verify before you call it 'done'.

2 Posts
2 Users
0 Reactions
2 Views
(@crm_hopper_2026)
Reputable Member
Joined: 3 months ago
Posts: 181
Topic starter   [#21742]

Having just concluded a nine-month migration from a highly customized Salesforce Sales Cloud instance to HubSpot Enterprise, I am compelled to share the exhaustive verification protocol my team developed. The transition was declared "complete" by the vendor's project manager after the final data sync, yet we discovered over a dozen critical failures in the subsequent fortnight. These were not mere data anomalies, but systemic flaws in automation, permissioning, and reporting that would have eroded revenue operations silently.

The root cause was a reliance on high-level smoke tests. To combat this, we constructed a granular, phase-driven checklist that moves beyond "did the data transfer?" to "does the business process function identically or better?" I am documenting it here as a methodological framework for any platform migration—be it to Salesforce, HubSpot, Pipedrive, or another system. Consider this a validation of operational integrity, not just technical data transfer.

**Phase 1: Core Data Integrity & Hygiene**
* Verify record counts per object pre- and post-migration, accounting for deliberate de-duplication or archiving.
* Confirm a statistically significant sample (e.g., 2% per object) for field-level accuracy across all mapped custom fields, especially picklists and date formats.
* Audit for broken internal record relationships (e.g., Contact > Company, Deal > Contact, Open Tasks > Owner).
* Validate that "lost" data (fields intentionally not migrated) is documented and signed off by business unit heads.
* Check for and rectify any encoding issues in text fields (apostrophes, special characters, line breaks).
* Verify the preservation of historical notes, email sync bodies, and activity timelines.
* Confirm that all unique identifiers (like legacy IDs) are stored in a dedicated field for audit and reference.

**Phase 2: User Access & Security**
* Test every user profile and role against the defined permission matrix; attempt unauthorized creates, reads, edits, and deletes.
* Verify team hierarchies, sharing rules, and territory assignments function as designed.
* Confirm that private records and fields remain private post-migration.
* Test all login methods (SSO, username/password, IP restriction) with a subset of users.
* Validate that deactivated users are excluded from lists, reports, and automation triggers.

**Phase 3: Process & Automation Workflow**
* Execute end-to-end tests for each documented business process (e.g., lead-to-opportunity conversion, support ticket escalation, contract renewal).
* Trigger every active workflow rule, sequence, and automation playbook with test data and verify the resultant actions, delays, and conditions.
* Test all API-integrated processes (e.g., form submissions to CRM, CRM updates to ERP) with live endpoints.
* Verify that email templates, documents, and meeting links populate correctly with migrated data.
* Confirm that task creation, assignment, and due date calculations are accurate.

**Phase 4: Reporting, Analytics & Dashboards**
* Run parallel reports in the old and new systems for a defined period (e.g., last full quarter) and reconcile discrepancies down to the individual record.
* Validate that all custom report types and dashboards have been recreated and that filters, groupings, and formulas produce identical logic.
* Check that historical data is available in new report formats and contributes to trend analysis correctly.
* Test scheduled report deliveries to ensure they generate and distribute without error.
* Verify that key metrics (win rate, pipeline velocity, lead response time) calculate correctly in the new environment.

**Phase 5: External System Integrations**
* Perform a full sync cycle with all connected applications (marketing automation, accounting, telephony, customer support).
* Confirm bidirectional field mapping is intact and data is writing to the correct objects.
* Test webhook endpoints and middleware (like Zapier or custom scripts) for failed payloads or authentication errors.
* Validate that integration-specific features (e.g., click-to-call, email tracking, webinar registration status) are fully functional.
* Review API call usage against new platform limits to forecast potential throttling.

**Phase 6: End-User Experience & Governance**
* Conduct user acceptance testing with a diverse group of end-users from sales, marketing, and service.
* Verify that mobile applications reflect all data and allow for critical actions (log call, update deal stage).
* Confirm that global search returns relevant results across multiple objects.
* Test bulk actions (edits, exports, deletions) with appropriate permissions.
* Finalize and disseminate new internal documentation, including naming conventions, required fields, and process changes.

This checklist is deliberately exhaustive. The goal is not to induce paralysis, but to provide a structured approach to risk mitigation. The final, and perhaps most critical, item is to establish a 30-day post-migration monitoring period where key users are on high alert for anomalies. This phase often uncovers edge cases and complex interaction failures that only manifest under real-world use. The migration is not done when the data is moved; it is done when the business operates without interruption or data loss in the new environment.



   
Quote
(@amyt5)
Eminent Member
Joined: 1 week ago
Posts: 31
 

Oh man, this hits so close to home. The "vendor's project manager after the final data sync" line gave me flashbacks. It's that exact moment when everyone breathes a sigh of relief, and the real work of finding the landmines begins.

Your shift from "did the data transfer?" to "does the business process function?" is the absolute key. So many migrations get obsessed with the raw numbers and miss that data is just fuel for the real engine: the workflows, automations, and reports.

On your point about statistical sampling for core data, I'd add one more layer: sample by *source*. If you had multiple data entry points or legacy systems feeding into your old CRM, you need to pull your verification samples from each stream. I once found a whole segment of contacts from a specific web form tool that failed to map a custom "Lead Source" picklist value because the sample batch we checked was all from sales-entered records. Nightmare.

Excited to see your full list.


Clean data, happy life.


   
ReplyQuote