Migration Checklist: Moving to HubSpot

Phase 0

Decide & Plan

Lock scope, owners, and the cutover window before any data moves.

• Define migration scope by HubSpot object. List every object in scope: Contacts, Companies, Deals, Tickets, Products, Line Items, Quotes, Custom Objects, and activities (notes, calls, emails, meetings, tasks). Document each as in-scope or out-of-scope in writing.

  Risk if skipped: Unscoped objects surface mid-migration and force re-export, re-mapping, and an extended freeze window.

• Decide historical-activity scope and time horizon. Pick a hard cutoff (for example: last 24 months of emails, calls, notes, meetings). Activities can be imported but timestamps and threading behave differently per type.

  Risk if skipped: Loading all-time activity history multiplies row counts and can push the project past contact-tier limits without warning.

• Confirm HubSpot subscription tier and Marketing Contacts allocation. Marketing Contacts and overall contact ceilings are billed per tier. Overage triggers an immediate tier upgrade that cannot be reversed until renewal.

  Risk if skipped: Importing past the Marketing Contacts ceiling auto-bills the next tier for the full annual term.

• Choose data residency: US (na1) or EU (Frankfurt) data center. New portals can be provisioned in the EU data center. Existing portals require an opt-in residency migration. Decide before provisioning the destination portal.

  Risk if skipped: Provisioning in the wrong region forces a separate residency migration after cutover, doubling the project.

• Document success criteria for the migration. Define falsifiable acceptance tests: per-object row count match, total pipeline value parity, association integrity sample pass rate, and UAT sign-off from named owners.
• Set cutover date, freeze window, and rollback decision point. Pick the freeze date for source-system writes, the cutover weekend, and the hour by which a no-go call must be made if validation fails.

  Risk if skipped: Without a pre-agreed rollback gate, teams push through partial loads and create reconciliation work that takes weeks.

• Assign a single accountable owner (DRI) and stakeholder list. Name one DRI for the migration plus named owners for sales ops, marketing ops, RevOps, IT/security, and legal/compliance.
• Identify legal and compliance constraints. Capture GDPR data-residency requirements, HIPAA BAA scope if healthcare data is in play, SOC 2 evidence needs, and any per-jurisdiction retention rules.

  Risk if skipped: Late-discovered HIPAA scope can force a portal rebuild because Sensitive Data settings cannot be retro-applied to all properties.

• Document explicit out-of-scope items. Write down what is NOT migrating (dead leads older than X, deprecated custom fields, archived tickets, etc.) so it does not creep back in.

Phase 1

Pre-Migration Prep

Get the source clean and the destination schema fully built before any export.

Phase 2

Source Export

Pull every byte you will need out of the source system in transformable formats.

• Export contacts as CSV with all standard and custom fields. Include source record ID, email (lowercased), first/last name, phone, lifecycle stage equivalent, owner email, created date, and every custom field.

  Risk if skipped: Omitting source record ID makes idempotent re-runs impossible — re-loads create duplicates.

• Export companies as CSV with all standard and custom fields. Include source ID, normalized domain, legal name, address, industry, owner email, and parent/child company linkage if used.
• Export deals with full property set and pipeline metadata. Include source ID, deal name, amount, currency, close date, pipeline name, stage name, owner email, and associated contact/company IDs.
• Export tickets, products, and line items as separate files. Each object type has its own schema and required fields. Do not merge them into one sheet.
• Export custom-object records, one file per object type. Include the source ID, the field that will become the unique External ID in HubSpot, and all associations to standard objects.
• Export contact↔company, contact↔deal, and company↔deal association tables. Export junction tables as two-column CSVs (source contact ID, source deal ID) per association type. Capture association labels where the source supports them.

  Risk if skipped: Missing association exports break the parent/child relationships that HubSpot uses for reporting and roll-ups.

• Export activities — notes, calls, emails, meetings, tasks — as separate files. Each activity type has different required fields in HubSpot. Capture activity timestamp, owner email, body/notes, and the source ID of every associated record.
• Export file attachments — both metadata index and binaries. Export the file-to-record join table (which file is attached to which contact/deal/ticket) and the binary files themselves into a folder structure mirroring the index.

  Risk if skipped: Losing the join table means files can be re-uploaded but not re-linked to their owning records.

• Export the source user list with roles and reporting structure. Capture each user's email (the matching key in HubSpot), role, and team. This is the owner-mapping source.
• Export pipeline, stage, and picklist definitions. Document every source pipeline name, stage name, stage probability, and every picklist option with both display label and internal value.
• Capture screenshots and configs of source automations, reports, and dashboards. Workflows, reports, and dashboards do not transfer. Document them now so they can be rebuilt in HubSpot post-cutover.
• Record the exact timestamp of every export. Note the wall-clock time each export file was generated. This is the delta-window anchor for the final cutover export.

  Risk if skipped: Without per-file timestamps the delta export at cutover may miss or double-count records changed during the export window.

Phase 3

Transform & Map

Turn raw exports into HubSpot-shaped files with explicit mapping decisions.

Phase 4

Sandbox Test Migration

Catch every problem in the standard sandbox before production load.

• Load a 1–5% representative sample of each object into the sandbox. Use stratified sampling: include records from each pipeline, lifecycle stage, owner, and time period. Random 1% can miss edge cases.

  Risk if skipped: A non-representative sample passes validation but production load hits unknown edge cases.

• Test the Import Tool wizard path via Settings → Data Management → Data Integration. Walk through Advanced Imports for multi-object files. Validate column-to-property mapping, association mapping, and the 'Prevent property overwrite' option.
• Validate field-by-field on 10 random sandbox records per object. Open each record in the HubSpot UI and compare every property value against the source. Spot-check date fields, picklists, and multi-checkbox values.
• Test edge cases: long strings, special characters, NULL, blank vs. missing. Verify a 60,000-character note imports, that em-dashes and emojis survive, and that blank-vs-missing distinction matches expectations.
• Verify parent-child and many-to-many associations preserved. Spot-check 20 contact-to-company and contact-to-deal associations. Confirm association labels (Decision Maker, etc.) landed on the right side.

  Risk if skipped: Reversed association direction is silent and only surfaces when a report shows zero linked records.

• Stress-test against the 50,000 associations-per-record ceiling. If any source object has more than 50,000 associations of a single type, design a chunking strategy or shard the data. This is a hard platform ceiling.

  Risk if skipped: Hitting the 50k ceiling mid-load rejects associations silently and reports show under-counted relationships.

• Verify activity timestamps and ownership. Open 10 imported notes/calls/emails and confirm Activity Date and Activity assigned to land correctly. Meetings require an owner column mapped to Activity assigned to.
• Run a full-volume test or the largest sample the sandbox allows. Time the load. Extrapolate to production volume and confirm the cutover window is realistic.
• Test the error-file workflow. Download a deliberately-bad row's error file from the Import Tool. Confirm the team can read it, fix the source, and re-import only failed rows.
• Get a sales-ops or RevOps domain expert to spot-check sandbox data. Have a power user open 25 deals across pipelines and confirm amounts, stages, close dates, and associations look right.
• Sign off the sandbox test results in writing before Phase 5. Get the migration sponsor's documented approval. Capture the sandbox import IDs and row counts as evidence.

  Risk if skipped: Skipping written sign-off lets ambiguity about 'good enough' bleed into the production go/no-go call.

Phase 5

Production Cutover

Execute the production load in dependency order with idempotent upserts.

• Confirm source-system freeze and verify zero new writes in the last hour. Check source audit logs. If writes are still happening, halt and escalate to the freeze owner.

  Risk if skipped: Writes during cutover create a delta that the final export misses, leaving records behind in the source.

• Take a final full export of source data as the delta against Phase 2 baseline. Export every object again. Diff against Phase 2 to find created/updated/deleted records during the prep window. Apply only the delta to the prepared transform.
• Disable destination workflows, sequences, and integrations one final time. Re-verify the pause set from Phase 1b is still in place. New workflows may have been created since.

  Risk if skipped: A workflow created mid-project that no one paused fires on every imported contact and triggers notification spam.

• Load users and Owners first. Use the Import Tool with the Owners object. All owner-mapped records depend on these existing.
• Load parent objects: Companies, then Contacts. Companies before contacts so the contact-to-company association can resolve on contact load. Use upsert on Company Domain Name and Email respectively.
• Load Deals and Tickets. Both depend on Contacts and Companies existing. Use the External ID upsert key per object. For deals, confirm pipeline and stage internal values resolve.
• Load Custom Objects and their associations to standard objects. Custom objects with associations must be loaded after their associated standard objects.
• Load activities last: notes, calls, emails, meetings, tasks. Activities require existing records to associate with. Include the Activity assigned to and Activity Date properties so timestamps and ownership land correctly.
• Load file attachments and link them to records via Notes. Upload each binary into HubSpot Files, then attach via a note on the associated record.
• Capture import job IDs, row counts, and error files for every step. Save the import ID, requested row count, succeeded count, and downloadable error file URL per load. This is the audit trail for Phase 6.

  Risk if skipped: Without per-step row counts, reconciliation in Phase 6 becomes guesswork.

• If any load step fails partway, stop and diagnose before continuing. Do not push forward with partial data hoping to fix it later. Fix the transform, run an idempotent re-load using the upsert key, then continue.

  Risk if skipped: Pushing through partial loads creates orphan records and double-counted rows that take weeks to untangle.

• Re-enable workflows, sequences, and integrations only after all loads complete. Turn integrations back on one at a time and monitor for unexpected enrollment or notification traffic.

Phase 6

Validate

Prove the migration was correct before letting users in.

Phase 7

Post-Migration Cleanup

Wrap up so HubSpot becomes the unambiguous system of record.

• Send go-live communication to all end users. Include the HubSpot login URL, the SSO instructions, the where-to-get-help contact, and the freeze date on the source.
• Run role-specific HubSpot training sessions in the first week. Separate sales-rep, marketing, and service sessions covering the Lifecycle Stage and Lead Status conventions chosen in Phase 3.
• Set the source system to read-only and announce the date. Switch source-system permissions to read-only on the announced date so accidental writes do not happen during the dual-state window.

  Risk if skipped: Leaving the source writable invites confusion about which system is the truth.

• Rebuild reports and dashboards in HubSpot. Use the screenshots and configs captured in Phase 2 as the source. Prioritize the top 10 dashboards used by leadership.
• Rebuild workflows, sequences, and saved views. Recreate the prioritized 20% of workflows from Phase 3d. Defer the long tail to a 30-day backlog.
• Re-establish integrations to other systems. Reconnect calendar sync, email sync, BI tools, and any system-of-record integrations. Test each before unpausing.
• Configure the HubSpot data-retention policy for inactive contacts. Settings → Data Management → Privacy & Consent. Decide whether to enable auto-deletion of contacts inactive over a set window (default 365 days).

  Risk if skipped: Auto-deletion turned on too aggressively after a migration removes recently-loaded but as-yet-unengaged records.

• Run a HubSpot duplicate-management pass on contacts and companies. Settings → Data Quality Command Center or the native duplicate-management tool. Resolve any cross-source duplicates that survived the import.
• Schedule a 30-day post-migration retrospective. Capture what went well, what broke, what was missed, and what the team would do differently. File the document in the project archive.
• Document the source-system decommission date. Typically 90 days after cutover, aligned with the data-retention window. Get the call documented in writing by the data owner.
• Archive all source-system exports and HubSpot import error files to cold storage. Move CSVs, binaries, and import error files to long-term object storage with a retention tag aligned to legal hold requirements.

  Risk if skipped: Deleting source exports too early leaves no recovery path if a data issue surfaces in month four.

• Close out the project formally. Final status report, lessons-learned document, sponsor sign-off on closure. Release the migration team.