How to Decide Which Data to Move to HubSpot| Markivis

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.

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.