A migration can preserve the number of contacts while losing the relationship between a person, a company and an open opportunity. Before moving CRM data into HubSpot, decide how you will identify records, preserve those relationships and recognize a result that needs correction. Your HubSpot migration checklist should also explain what you will do if the cutover fails its acceptance checks.
TLDR: Inventory the source, approve a field and identity map, test representative records and associations, and define the cutover and recovery conditions. Reconcile accepted records against the approved scope. Keep source exports and recovery evidence before any production change.
Product documentation checked August 29, 2026. All field maps, counts and test references below are fictional. This is a planning checklist, not a guarantee that an import or restore will preserve every part of your CRM.
1. Define the data migration scope
We recommend an inventory by object and data type. Contacts and companies are only part of the decision. Identify the deals, activities, attachments, relationships, historical fields and external references your team needs to retain.
For each source, name its owner, export method, approved scope and expected destination. Decide what should remain in an archive and how authorized users will find it. A deliberate exclusion should be documented before anyone compares record totals.
If the destination already contains active processes, review them with a HubSpot portal audit. Identify workflows, integrations and communications that could react to new or updated records. Obtain approval for the migration behavior rather than assuming an import is isolated.
2. Preserve identity in your HubSpot migration
HubSpot's import requirements call for a unique identifier when updating existing records or associating records. Depending on the object and method, identifiers can include a HubSpot Record ID, a custom unique-value property, contact email or company domain. Confirm the applicable identifier for each object instead of relying on a display name. HubSpot: format import files.
We recommend keeping the source system's immutable record reference in the approved mapping. Build a cross-reference between that source identity and the destination identity, especially when several people share a company or a person has changed email addresses.
Do not assume a field called “ID” has the same meaning in both systems. Label the origin explicitly, preserve the source export, and record how you will detect a collision or missing identifier before the production import.
3. Approve data migration field mappings
This fictional field map shows the level of detail we recommend. The proposed custom property names are examples, not pre-existing HubSpot fields.
| Source field | Proposed destination | Mapping decision | Test |
|---|---|---|---|
| Source contact key | Proposed source-contact reference | Preserve as text; confirm identity strategy separately | Every accepted source contact has its expected reference |
| Work email | Contact email | Trim incidental whitespace; route ambiguous identities for review | A known existing contact is updated as intended |
| Account key | Company association reference | Resolve through the approved company cross-reference | Contact is related to the intended company |
| Territory code | Proposed territory property | Translate only through the approved value table | Unknown codes remain exceptions |
| Source opportunity key | Proposed source-deal reference | Preserve the original identifier | Repeated import test does not create an unintended second deal |
Add the destination data type, allowed values, blank-value policy and accountable owner to the real workbook. Decide explicitly whether an empty source value should preserve or replace a populated destination value. Test that behavior with your selected import settings.
The CRM feature overview can help orient stakeholders to the destination. The approved object and import documentation should control the actual migration design.
4. Test data migration relationships and exceptions
We recommend a small test set that represents the difficult cases, not just the cleanest rows. Include an existing destination record, a missing identifier, an unknown field value, a contact with a company, and an opportunity with its intended associations.
Record the expected result before the test. Have the responsible owner inspect both the source and destination references afterward. If an association is wrong, correct the mapping and repeat the test before expanding the batch.
Use synthetic records or an explicitly approved test set in an appropriate environment. Do not copy personal data into public documents or screenshots. A test should verify the production method without making unapproved changes to live customer records.
5. Reconcile data migration results against scope
HubSpot's import history reports created records, updated records, associations and errors. Those results help investigate an import, but you still need to compare them with your expected source scope. Review the error file and affected records before closing the migration task. HubSpot: review past imports.
Here is a fictional planning example with one source object:
| Reconciliation category | Illustrative count |
|---|---|
| Source records reviewed | 100 |
| Approved exclusions | 8 |
| Expected destination records in scope | 92 |
| Destination records verified against source identity | 90 |
| Unresolved records | 2 |
The expected population is 100 minus 8, or 92. With only 90 verified identities, the example remains unresolved. That conclusion does not change because the total destination database happens to contain 92 records. Unrelated or duplicate records could make an aggregate total look right.
Keep detailed field-by-field reconciliation in a separate acceptance register. This checklist establishes the migration sequence and the decision to proceed, pause or recover.
6. Plan the data migration cutover
Agree on when source changes stop or how you will capture changes made after the initial export. Document the final extract, batch references, responsible operator and communications to the affected team.
We recommend a cutover record with the approved source scope, preserved before-state, mapping version, expected totals and launch conditions. Include the person authorized to pause the work. Do not rely on an informal message that “the data looks fine.”
Keep the old system available according to your approved retention and access plan until the responsible owner accepts the migration. This does not mean retaining data indefinitely; it means making the retention decision explicitly with the people responsible for it.
7. Verify data migration recovery before cutover
HubSpot now documents Restore CRM changes for supported objects within a 14-day window. It requires Super Admin permissions; restoring changes from installed integration apps also requires the relevant public beta. Verify the eligible source, objects and preview in your account before relying on it. HubSpot: restore CRM changes.
Deleting records associated with an import does not reverse updates made to pre-existing records. Do not treat deletion as a general rollback procedure. HubSpot: import reversal limitation.
We recommend a recovery plan that separates newly created records, updated records, associations and downstream actions. Establish what the selected restore method actually covers and how you would handle anything outside that coverage. A CRM restore is not evidence that an email, external system update or business action has been reversed.
Before production, have the authorized owner review a controlled recovery test and its limitations. Define the failure conditions that require a pause, the approval for recovery, and the checks that confirm a correction worked. Preserve the export and mapping even when a native restore option is available.
Choose the cutover decision before migration day
We recommend writing the decision rule in plain language. Proceed when required identity, value and relationship tests pass and the accountable owner accepts the remaining exceptions. Pause when a required check is unresolved. Recover only through a reviewed method whose scope and consequences are understood.
A deadline can make an exception urgent, but it cannot make its result known. If an owner accepts a limitation, record exactly what is excluded, who will resolve it and which business process is affected. Do not label an untested record as verified to make the completion report easier to read.
Separate import success from business acceptance
Your technical operator can confirm that a job ran. The data owner needs to confirm that the intended information arrived. The process owner needs to confirm that the team can use it. Give those checks separate fields in the migration record so that a successful execution does not silently stand in for all three.
For a controlled retry, retain the earlier result and identify which source records are being corrected. Compare the result using stable references rather than a new aggregate database count. Decide how to handle values changed by users after the first attempt before repeating an update.
Prepare the handover for the person who did not build the map
Ask an authorized colleague to locate an imported record from its source reference and explain the mapping decision. They should also be able to find the exception owner and the agreed recovery boundary. If that requires the migration lead to reconstruct the story from memory, the handover is incomplete.
Prepare the data migration inventory by business use
Before the migration starts, have the project manager collect decisions from the sales and marketing teams and any service users affected by the move. Your data migration plan should explain how customers, open opportunities and active work will be represented on the new platform. Migration scope should follow the approved business need, not everything the old system can export.
- Contact data: Identify required customer data, job titles, source references and ownership. Decide how each contact record will be matched. A company name is a descriptive value, not a dependable substitute for a company identifier.
- Company and deal data: Preserve the relationships needed to explain open revenue and sales processes. Have sales teams confirm the destination pipeline definitions and the deal information they need to act.
- Historical data: Separate information needed in daily work from information retained in an approved archive. Review payment data and sensitive material with the authorized owner rather than assuming it belongs in a CRM import.
- Custom fields: Review each required source field against the destination model. Have the administrator prepare the approved HubSpot properties and validate their types and allowed values before testing the data migration.
Do data cleaning before a test import
We recommend resolving duplicate entries, inconsistent formats and outdated contacts according to an approved rule. Removing duplicates requires an identity decision; matching a name alone is not sufficient. Keep the original export and the transformation log so you can explain why the migration file differs from the source.
Use the data migration tool or import method selected for production on a small batch first. Cleaner data is helpful only if the field mappings preserve its meaning. Compare the expected source identity, destination property and association for each difficult case. Record whether the test import created, updated, skipped or rejected the record. Investigate data conflicts before increasing volume.
Map lifecycle stages and data sync dependencies
Ask the responsible team to approve how lifecycle stages map from the old system into HubSpot. Do not assume two fields with similar labels describe the same customer journey. Test the mappings against your agreed definitions and the workflows that use them. Keep lifecycle stages distinct from the next sales action, as explained in our lifecycle stage and lead status guide.
Document which other systems sync data with the CRM and which system owns each shared value. Review whether the data migration could trigger marketing automation, change an integration match or overwrite a user's recent update. Obtain approval for any temporary pause, then define how data sync will resume and how changes during the pause will be reconciled. A blanket instruction to disable every integration is not a recovery plan.
The migration process is not finished when the last import completes. Train the intended users on the migrated records, their custom fields and the reports they will use. Before saying the migration is complete, have the accountable owners accept the results and the remaining exceptions. A successful migration is an evidence-based decision about usable data, not a promise that data loss is impossible.
Frequently asked questions
Is matching the total record count enough?
No. We recommend checking identity, required values and associations against the approved source population. Totals can conceal duplicates, exclusions and incorrectly matched records.
Should every source field be migrated?
Decide based on the agreed business purpose, retention requirements and destination model. Document each exclusion and preserve only the source material your authorized retention plan allows.
Can we use deleting the import as the recovery plan?
Do not rely on deletion as a general recovery method. Review the current restore options and document how you will recover each type of change, including effects outside the CRM.
When should the old system be retired?
After the authorized owners accept the migration and approve the retention and access plan. Keep unresolved exceptions visible and make the retirement decision separately from the upload completion.
Scope the migration before scheduling cutover
Our HubSpot onboarding services can help you define the field map, responsibilities and acceptance conditions. Bring a source inventory and the relationships your team cannot afford to lose.
If you need to review the migration boundaries, talk with Selworthy before approving the production cutover.
