The most reassuring sentence in a CRM migration is not “the data imported successfully.”
It is “we can prove the new system produces the right records, automations, permissions, and reports—and we know what to do if it does not.”
A complex Salesforce-to-HubSpot project contains too many dependencies to manage through status meetings alone. Enterprise buyers need evidence. Before approving cutover, your HubSpot agency should provide a complete migration evidence pack.
The following nine deliverables turn a vague promise of readiness into a reviewable go/no- go decision.
A successful CRM data migration preserves business meaning, not just field values.
Every cutover decision should be supported by a defined artifact and approval owner.
Reporting, permissions, integrations, and automation require the same rigor as record transfer.
Your migration plan should include reconciliation, rollback criteria, and post-launch ownership before the legacy system is retired.
The first deliverable is an inventory of what exists in Salesforce and what depends on it.
This should cover:
Standard and custom objects
Fields and picklist values
Record types
Validation rules
Flows, workflows, and triggers
Reports and dashboards
Integrations and middleware
User profiles and permission sets
Forms, campaign processes, and attribution dependencies
Documents, attachments, notes, and activity history
The inventory should distinguish what is active, duplicated, obsolete, or legally required to retain.
Go/no-go test: Every in-scope object and dependency has an owner and a documented disposition: migrate, transform, rebuild, archive, or retire.
A field-mapping spreadsheet is necessary, but it is not sufficient.
The target-state model must show how Salesforce concepts will work in HubSpot. That includes relationships, lifecycle stages, pipeline logic, association labels, custom objects, and required fields.
For each mapped field, document:
Source object and field
Target object and property
Data type
Transformation rule
Default or fallback value
Allowed values
Ownership
Whether historical values must be preserved
What happens when the source value is invalid
Go/no-go test: Business owners can explain how their critical processes and reports will work using the target model.
A CRM migration exposes years of operating decisions. Duplicate accounts, abandoned opportunities, inconsistent territories, and overloaded free-text fields do not disappear when moved to HubSpot.
Before extraction, the agency should establish a baseline that includes:
Total records by object
Duplicate rate
Missing required values
Invalid email and phone formats
Orphaned records
Inactive owners
Stale opportunities
Invalid or retired picklist values
Records blocked by retention or consent rules
The remediation ledger should explain which issues will be fixed at source, transformed during migration, quarantined, or accepted.
Go/no-go test: Every known data-quality issue has a treatment decision and accountable owner.
Executives rarely experience a CRM migration as a collection of records. They experience it as a change in numbers.
Salesforce and HubSpot can calculate stages, dates, attribution, pipeline, and forecasts differently. Without a reporting-continuity specification, both systems may be internally correct while appearing to disagree.
Document:
The critical reports that must survive cutover
The exact definitions behind each metric
Source fields and filters
Expected differences between platforms
Historical backfill rules
The date on which HubSpot becomes authoritative
Who approves each replacement dashboard
Go/no-go test: Leadership has reviewed side-by-side results and accepted explained variances.
An enterprise CRM migration changes more than the CRM. Marketing platforms, ERP systems, support tools, billing platforms, data warehouses, enrichment services, and custom applications may all exchange data with Salesforce.
For each integration, identify:
Data exchanged
Direction of travel
Owning system
Frequency or trigger
Authentication owner
Error handling
Monitoring
Cutover sequence
Backfill requirement
Recovery method
Go/no-go test: Every integration has passed a production-like test, and failed transactions are visible to a named owner.
Do not recreate every Salesforce automation simply because it exists.
Some workflows encode valuable business logic. Others compensate for an old process, duplicate another automation, or create unnecessary complexity.
The register should classify each automation as:
Rebuild as-is
Redesign for HubSpot
Consolidate
Replace with a native feature
Retire
Defer to a later phase
Each rebuilt automation needs a trigger, action, exclusion rule, owner, test case, and monitoring plan.
Go/no-go test: No active Salesforce automation lacks a disposition, and every launch- critical HubSpot workflow has passed positive, negative, and exception tests.
CRM implementation teams often focus on functionality first and permissions later. That is risky.
The migration evidence pack should map:
Roles and teams
Record visibility
Field-level restrictions
Export permissions
Admin access
Sensitive-property access
Subscription and consent status
Legal or regional restrictions
Former employee ownership
Service accounts and integration users
Go/no-go test: A representative user from every role has completed access testing, and restricted information is confirmed to remain restricted.
User acceptance testing should prove that real work can be completed in HubSpot. Reconciliation should prove that the transferred data is complete and accurate.
Test scenarios should include:
Creating and qualifying a new lead
Associating contacts, companies, and deals
Progressing opportunities
Routing and reassignment
Producing a quote or handing off to the quoting process
Updating data through integrations
Running management reports
Handling duplicates and exceptions
Completing common tasks with standard user permissions
Reconciliation should compare source and target counts, transformed values, associations, activity history, and key financial or pipeline totals.
Go/no-go test: All critical defects are closed or formally accepted, and reconciliation falls within approved tolerances.
The final deliverable should tell everyone what happens before, during, and after launch.
The runbook should include:
Change freeze timing
Final extraction and delta load
Integration shutdown and activation sequence
User provisioning
DNS, forms, and connected-app changes if applicable
Validation checkpoints
Go/no-go meeting owners
Rollback triggers
Communication plan
Support channels
Defect triage
Daily hypercare reviews
Legacy access and retirement schedule
Rollback is not failure. It is a controlled option when an agreed threshold is breached.
Go/no-go test: Every cutover task has an owner, start time, dependency, validation step, and fallback action.
Ask prospective agencies to show anonymized examples of these deliverables. You are not asking them to reveal client data. You are testing whether their method produces decision- ready evidence.
Listen for:
How they resolve disagreement between business teams
How they determine acceptable variance
How they test negative and exception cases
How they preserve reporting confidence
How they control scope changes
How they support users after launch
An enterprise CRM migration partner should be comfortable discussing uncertainty. Confidence without controls is not a migration method.
| Area | Ready | Ready with accepted risk | Not ready |
|---|---|---|---|
| Data model | Approved and tested | Minor deferred items documented | Critical process cannot be represented |
| Data quality | Within approved tolerance | Known exceptions have owners | Unknown loss or unowned errors |
| Reporting | Critical reports reconciled | Explained variance accepted | Leadership cannot trust key metrics |
| Integrations | Tested and monitored | Noncritical integration deferred | Critical system exchange fails |
| Automation | Critical workflows pass | Low-impact defects accepted | Routing or lifecycle logic unreliable |
| Access | Role testing complete | Minor access cleanup scheduled | Sensitive data exposed or users blocked |
| Users | UAT accepted | Training follow-up planned | Core tasks cannot be completed |
| Cutover | Runbook rehearsed | Small timing risks accepted | No viable rollback or support plan |
Moving from Salesforce to HubSpot should create a simpler, more useful revenue system. But simplification does not mean skipping controls.
The evidence pack gives executives, RevOps, IT, sales, and marketing a shared definition of readiness. It also gives your HubSpot agency a clear standard for delivery.
Set2Close helps mid-market and enterprise B2B teams plan, execute, validate, and adopt complex Salesforce-to-HubSpot migrations. If your team needs an evidence-led migration plan, begin with a discovery and readiness assessment.
Integration allows Salesforce and HubSpot to continue exchanging data. Migration moves agreed processes and data to a target platform, usually with a plan to reduce or retire reliance on the former CRM.
Obsolete, duplicate, legally restricted, corrupted, and unused data may be better cleaned, archived, or retired. The decision should follow documented business, legal, and reporting requirements.
Use record-count reconciliation, field and relationship sampling, critical report comparisons, integration tests, permission tests, and end-to-end user acceptance scenarios. Validate transformed meaning, not only raw values.
Retire Salesforce only after the target system is accepted, required history is retained, integrations are stable, users can complete core work, and legal, audit, and reporting obligations are satisfied.