Key Takeaways
-
A HubSpot data migration is a scoping decision first: every data type gets migrated, archived or rebuilt, and someone must choose.
-
Audit the old CRM before planning the move, measuring volume, fill rate, recency and usage so each decision rests on evidence.
-
We recommend migrating data a named team will act on soon after launch, and archiving history that answers only occasional questions.
-
Rebuild rather than copy anything that encodes the old system's logic, such as workflows, lead scores and stage definitions.
-
Give each data type a named business owner who signs off the decision and answers later requests for old data.
In the migrations we scope, the first question on the table is how to move everything into HubSpot. A better question is what deserves to move at all, and an audit answers it before anyone builds an import file.
What should a HubSpot data migration include?
A HubSpot data migration should include the records and fields your teams will act on, carried across cleanly, and nothing that survives only because the old system kept it. Each data type gets one of three decisions.
Migrate: the data moves into HubSpot as records and properties, and teams use it from day one. Open deals, active customers and consent records sit here.
Archive: the data leaves the old system but does not enter HubSpot. It goes to a secure export where someone can retrieve it for an occasional question, such as a dispute about an old contract.
Rebuild: the logic is recreated in HubSpot from a fresh definition rather than copied. Workflows, lead scores, stage definitions and reports belong here, since they encode how your old process worked.
A copy job skips all three choices, so the new portal inherits empty fields, duplicate companies and automation tied to properties whose meaning has drifted. If you are still weighing who should run the project, our comparison of DIY and partner-led HubSpot implementation sets out the trade-offs.
What this means for you: list each object and field in your current system, then write migrate, archive or rebuild next to it before you discuss tools or import templates.
How do you audit your data before a HubSpot data migration?
You audit it by measuring what exists, who uses it and how recently it changed. Opinions make a poor guide here, since each team defends its own fields.
Picture an 80-person engineering services firm leaving a CRM it has used for nine years. Three departments call all of its data essential. An audit tells a different story: many custom fields are blank on almost every record, and a large block of contacts has sat untouched for years.
A useful audit captures five facts for each object and field:
-
Volume: how many records exist, and how many are duplicates by email address or company domain.
-
Fill rate: the share of records where the field holds a value.
-
Recency: when the record was last updated or last showed activity.
-
Usage: whether any report, view or process depends on the field today.
-
Owner: the person who can say what the field means and whether it is still needed.
A spreadsheet of fields with fill rates and last-modified dates turns a debate into a short review meeting.
Questions to ask: Which fields would anyone notice were missing a month after launch? Who in our company can explain what each custom field was created to record?
How do you decide what to migrate, archive or rebuild in a HubSpot data migration?
Decide with a test for each data type rather than a blanket rule. The test asks whether a named team will use the data soon after launch, whether it is accurate enough to act on, and whether it carries logic from the old process.
A practical starting point is a look-back window of 24 months for contacts and closed deals. Records with activity, an open deal or a customer relationship inside that window migrate. Older records go to the archive unless a team can name the action it will take on them. A business with multi-year contracts may need a longer window.
Data that passes the use test still has to pass the quality test. Job titles last updated several years ago are filled but wrong, and migrating them gives sales a confident view of stale facts. Leave such fields out, or bring them across into a clearly labeled legacy property.
At a glance: the migrate, archive or rebuild decision for each data type, with the test that settles it and the person who signs it off.
|
Data type |
Decision |
The test that decides it |
Owner |
|
Active contacts and companies |
Migrate |
Activity, an open deal or a customer relationship inside the look-back window |
Marketing operations lead |
|
Open deals |
Migrate |
The deal can still close and has a named owner and a next step |
Sales manager |
|
Closed-won deals |
Migrate |
Needed for revenue reporting, renewals or account history |
Revenue operations |
|
Email and call activity |
Migrate recent, archive the rest |
Someone will read it to work an open deal or active account |
Sales and marketing leads |
|
Custom fields |
Migrate only if filled and used |
Filled on enough records to matter and used by a report or process |
HubSpot admin with the field owner |
|
Consent and opt-out records |
Migrate or keep as suppression |
Needed to email lawfully, as your compliance team defines it |
Compliance owner |
|
Lead scores and workflows |
Rebuild |
The logic depends on fields and stages that are changing |
HubSpot admin |
|
Pipelines and deal stages |
Rebuild |
The stages must reflect the sales process as it now runs |
Sales leader |
|
Contracts and attachments |
Archive and link |
Finance or legal already treats another system as the record |
Finance or legal lead |
In the migrations we review, the costliest problems come from old logic copied forward rather than from data left behind, since a copied score or workflow keeps applying old rules to new definitions.
What this means for you: put the table in front of each owner and ask them to sign off their rows. A decision with a name next to it holds up when someone asks for the old data back.
What should you leave out of a HubSpot data migration?
Leave out anything that adds volume without adding a decision, starting with three categories.
Contacts with no permission and no relationship: if you cannot email them and nobody sells to them, they clutter each list and report. Check how your own subscription counts contacts before you import them.
Legacy custom fields: a field that is blank on nearly all records, or that duplicates a standard HubSpot property, should not become a new property.
Bulk activity history: years of logged emails and call notes are heavy to move and light on value. Archive older history where account managers can still look it up.
Opt-out records need care even for contacts you archive. Keep a suppression record in HubSpot so nobody imports and emails those people later, and let your compliance team set what consent evidence has to be retained.
What this means for you: write each exclusion down with a one-line justification, so the decision survives the first request to bring everything across.
How do you check that a HubSpot data migration scope was right?
Check it twice: through reconciliation before the final import, and through the requests people make in the first weeks after launch.
Before the import, reconcile counts. The records you planned to migrate, the records in the import file and the records HubSpot accepted should match. HubSpot reports errors for rows it could not import, and each of those rows needs a decision rather than a silent drop.
After launch, we would track three signals for 30 days: requests for archived data, the fill rate of migrated properties, and requests for new fields. Repeated requests for the same data type suggest it belonged in HubSpot.
Questions to ask: How many rows did HubSpot reject, and has someone decided what happens to each one? Which archived data has been requested more than once since launch?
The Bottom Line
The goal is not to move less data but to move the right data. Audit before you plan, give each data type one of three decisions, and put an owner's name on each one. Rebuild the logic rather than copying it, and keep a reachable archive for the rest.
The Markivis Approach
A migration starts with a field-level export of the old CRM, scored for fill rate and recency, which we then walk through with the person who owns each area. The migrate, archive or rebuild table follows, signed off by those owners. Import files and mapping documents come last, as part of our HubSpot implementation services.
-
Archives are set up so a named person can retrieve old records without reopening the legacy system.
-
Scoring and workflows are rebuilt against the new definitions, then tested before launch.
Our partnership with Slimstock has now run for more than four years, as the Slimstock case study describes. The engagement covered HubSpot, CRM, lifecycle and demand generation rather than a migration, so we cite it for the habit it built, not for a migration result. A portal that stays useful for four years depends on fields whose meaning the people using them agreed at the start.
FAQ
A: Audit each object and field for volume, fill rate, recency, usage and ownership. Then give each data type one decision (migrate, archive or rebuild) and have its business owner sign it off.
A: For one source CRM, we would plan four to eight weeks, with the audit and owner sign-offs taking the first two or three. Each additional source system, or heavy rebuilding of workflows and scores, extends that range.
A: We would not migrate it by default. Bring across recent activity on open deals and active accounts, and archive the rest somewhere account managers can search, since old activity adds little to the next action.
A: Some cleanup can happen after launch, but duplicates and stale fields imported on day one feed workflows and reports immediately. Removing them before the import costs less than unwinding what they trigger.
A: It is exported to a secure store outside HubSpot, with a record of what it contains and who can retrieve it. Agree retention with your compliance team before the old CRM contract ends.
A: Yes, a phased approach can move open deals and active accounts first, then add history once the core setup is stable. Label reports during the gap so nobody reads partial data as complete.
A: If the old data is largely unreliable, starting with open deals and current customers can be cleaner. Archive the full legacy export, then let HubSpot build a trustworthy history from launch onward.
Ready to Scope Your HubSpot Data Migration?
A migration that starts with import templates carries old problems into a new system. One that starts with an audit and named decisions gives your team a portal it can trust.
On the call, we would go through the object and field list of your current CRM with you and mark the fields most likely to fail the use and quality tests. You leave with a first draft of the decision table to put in front of your owners.