The Data Migration Checklist for a CRM With Years of History in It

Nobody talks about data migration the way they talk about the CRM itself.

The CRM gets the pitch deck, the demo, the enthusiastic kickoff meeting. The data migration gets a line item in the scope document and a vague reassurance that it will "all come across cleanly."

At a fifteen-person business that might even be true. At 100 to 200 people it usually isn't. By that size a CRM migration is rarely one spreadsheet: it's years of deal history, several integrations feeding the database from different directions, and data that sales, marketing, finance and support have all touched in their own way. A CRM that starts life with duplicate contacts, broken associations, wrong field mappings and missing deal history is a CRM your team will distrust before they've had a chance to use it properly, and at this scale there is no single weekend where you can safely cut over and fix it after the fact.

This is the checklist for that situation: what to do before any migration starts, how to map fields correctly across multiple source systems, and how to validate that what arrived is actually what you sent, run as a staged or parallel migration rather than a single cutover. Before any of it starts, mapping your sales process before the migration starts is worth doing first, since the migration only makes sense against a process everyone has already agreed on.

Before You Touch Anything: The Pre-Migration Audit

The most common migration mistake is starting the import before reviewing the source data. Messy data migrated correctly still produces a messy CRM, just in a different system. At this size the audit isn't a one-person job either: sales has opinions about which deals still matter, finance has opinions about which invoiced accounts need to stay, and support has tickets tied to records nobody in sales has looked at in years.

Open your current system and look at what's actually there, not what you think is there. Four things to check:

Duplicates. The same contact or company appearing under multiple records, often with slightly different email addresses, phone number formats or name spellings. With years of history behind multiple integrations, duplicates usually come from more than one direction, a form submission, a support ticket, a manually added lead, so merge them before migration, not after. Importing duplicates into HubSpot and merging them later is significantly more work, and any automation that fires while duplicates exist can produce incorrect results.

Incomplete records. Contacts missing email addresses can't be used in email automation or tracked meaningfully. Companies with no associated contacts are hard to attribute activity to. Decide upfront whether incomplete records get migrated, held back until completed, or excluded, and who on each team makes that call for their own patch of the data.

Inconsistent formatting. Phone numbers in five different formats. Company names in title case, UPPERCASE and random lower case. Date fields formatted as text strings. These cause problems in segmentation, personalisation and any automation that reads property values as a condition. Standardise formatting in the source data before you export, and check each integration is writing the same format, not just each user.

Outdated records. Contacts you haven't interacted with in three or more years, unsubscribed contacts who have explicitly opted out, closed deals from companies that no longer exist. Migrating everything regardless of relevance inflates your contact count, skews your reporting and makes segmentation less useful. With years of history, this step alone can cut the dataset considerably. Be deliberate about what actually needs to come across.

Understanding HubSpot's Object Structure

Before mapping fields, you need to understand what you're mapping them to.

HubSpot organises data into four core objects: Contacts, Companies, Deals and Tickets. Each has its own properties and associations. A contact associates with a company, a deal associates with both.

This matters because a single row in your spreadsheet, or a single record pulled from an integration, often needs to be split across multiple objects in HubSpot. A row containing a contact name, email, company name, deal value and deal stage needs to become a contact record, a company record, a deal record, and the correct associations between all three, not just a flat import.

HubSpot allows importing multiple object types in a single file using a record ID column for each object. This is more efficient than separate imports followed by manually building associations, but it needs the file structured correctly before you start, and with several source systems feeding the same objects, that structure has to be agreed once, not reinvented per system.

The Field Mapping Process

Field mapping is the step where you decide where each piece of data in your source system lands in HubSpot. Get it right and the migration is clean. Get it wrong and you spend weeks finding out that a critical property is empty because it mapped to the wrong field, or that a field in your old system has no equivalent in HubSpot and needs a custom property created before the import runs. With several integrations, that discovery work multiplies by however many systems are feeding the CRM.

Step 1: Export your source data and list every column header, from every system.

For each field note: what it contains, what format the data is in, whether it's consistently populated, and whether it's required for any process your team runs. Do this for each integration separately, not just the primary CRM export, an integration that has been writing to a field for years without anyone noticing is easy to miss.

Step 2: Map each source field to a HubSpot property.

Some will map directly, First Name maps to First Name, Email maps to Email, Company Name maps to Company Name. Others need decisions.

Common mapping decisions at this scale:

• Notes or free-text fields from a legacy CRM may not have a direct HubSpot equivalent. These can be imported as the Body field of a Note activity associated with the contact, or as a custom single-line or multi-line text property. Decide before the import which approach suits how your team will use that data, and be consistent across every integration that writes notes.
• Custom stages or categories from another system need to be mapped to the closest HubSpot equivalent: Deal Stage, Lifecycle Stage, or a custom property. If the stages don't map cleanly, create a custom dropdown property in HubSpot before the import so the original values are preserved, this matters more with years of history behind those stages.
• Phone number fields, HubSpot has specific phone number properties (Mobile Phone Number, Phone Number) that accept formatted numbers. If your source data has multiple phone number fields across multiple systems, decide which maps to which HubSpot property and whether any should be combined.
• Lead source or acquisition channel, if a source system has a field indicating how a contact was acquired, this can map to HubSpot's Original Source property, or to a custom property if your source values don't match HubSpot's source categories. HubSpot's Original Source is set automatically when a contact is created via a tracked channel, importing a value into this field overrides that automatic detection for historical contacts.

Step 3: Identify gaps. Fields that exist in HubSpot but have no data, and fields in your source data with no HubSpot equivalent.

For HubSpot properties that will be empty after migration because none of your source systems captured that data, decide whether those properties need to be populated before automation is built, or filled in over time as the team uses the platform. For source data fields with no HubSpot equivalent, create custom properties in HubSpot before the import, via Settings > Data Management > Properties, selecting the correct object type and property type (single-line text, multi-line text, dropdown, number, date and so on).

Step 4: Produce a written field mapping document.

Before the import runs, produce a document that maps every source field, from every system, to its destination HubSpot property, notes the data type, and flags any fields requiring manual review. This document is the single source of truth if questions arise during or after the import, and if you're working with a partner on what expert implementation support actually adds, it's the document that prevents the "I thought that was included" conversation.

Staged, Not a Single Weekend

A fifteen-person business with one clean spreadsheet can often migrate in a weekend. At 100 to 200 people, with years of deal history and several live integrations, that approach raises the stakes considerably: a broken mapping doesn't turn up until Monday, by which point the old system may already be switched off.

A staged or parallel-run migration reduces that risk. Migrate one object or one business unit first, contacts and companies before deals, or one region before another, and validate it properly before moving to the next. Where the old and new systems can run in parallel for a defined window, do that: keep the legacy CRM live and read-only while the team starts working in HubSpot, so there's a fallback if something in the migration turns out to be wrong. Agree the cutover date only once validation on the first stage has actually passed, not on a calendar set before the audit began.

The Import Itself: What to Do and What to Avoid

Use HubSpot's import tool, not a third-party import service, for standard object imports. HubSpot's native import (found under Contacts, Companies, Deals, or in the Import centre) handles the mapping interface, runs duplicate checking at the time of import, and creates the associations between objects correctly when the import file is structured with the right columns.

Run a test import before each stage. Take a sample of 50 to 100 records, representative of the range of data in that stage, and import them first. Check that every field mapped correctly, that associations were created between contacts and companies, and that any required properties are populated. Fix any issues in the source data and update the mapping document before running the full import for that stage.

Don't import unsubscribed contacts without the correct opt-out status. HubSpot's Email Subscription settings control which contacts can receive marketing emails. If your source system has contacts who have unsubscribed or opted out, those records need to arrive in HubSpot with the correct subscription status, not as standard contacts who get included in the next email send. HubSpot lets you manage subscription statuses during import via the import settings.

Deduplication happens before and after. Run deduplication in your source data before the import. After the import, HubSpot's Manage Duplicates view (Contacts > Actions > Manage Duplicates) identifies likely duplicate records automatically based on email address and similar name patterns. Review this view after each stage and merge any matches the pre-import deduplication missed.

Where the Data Actually Lives

One question a migration of this size has to answer before anything moves: where does the new CRM instance actually sit, and where does personal information go while it's in transit between systems. Under the Australian Privacy Principles, APP 8 covers cross-border disclosure of personal information, so if any source system, integration or backup step routes customer data overseas, that needs to be understood and documented before the migration starts, not discovered afterwards. APP 11 requires you to take reasonable steps to protect personal information from misuse and unauthorised access, which during a migration means access to both the old and new systems is limited to the people actually doing the work, and neither system is left more exposed than it was before the project started.

Confirm where the destination instance is hosted, ideally an Australian or Sydney-region equivalent, and where each integration in the chain actually sends data, before personal information starts moving. This is a sign-off item, not an assumption.

Post-Migration Validation Checklist

Before the CRM is handed to the team, run through this validation list:

Contact records

• All contacts have a valid email address or are flagged as having none.
• Phone numbers are formatted consistently.
• Lifecycle stage is populated for all records.
• Original source is populated for historical contacts where available.
• Unsubscribed contacts show the correct subscription status.

Company records

• Company name is populated for all records.
• Associated contacts are correctly linked.
• Industry, size and other standard fields are populated where available.

Deal records

• Deal name, amount and close date are populated.
• Deal stage is mapped to the correct HubSpot pipeline stage.
• Associated contacts and companies are correctly linked.
• Deal owner is assigned.

Associations

• Each contact is associated with their correct company.
• Each deal is associated with the relevant contacts and companies.
• No orphaned deals (deals with no contact association) unless deliberately excluded.

Reporting check

• Run a contact report filtered by lifecycle stage and confirm the distribution matches expectations from the source data.
• Run a deal pipeline report and confirm deal count, total value and stage distribution match the source.
• Check the lead source breakdown in HubSpot's Traffic Analytics to confirm original source data imported correctly.

Data quality sign-off

• Record, in the mapping document, that a data quality check was run against the migrated data before go-live, this is the practical version of the Australian Privacy Principles' APP 10 requirement to keep personal information accurate, complete and up to date.
• Have someone outside the migration project, a department lead, not the person who built the mapping, sign off each stage before it's treated as done.

When to Bring In a CRM Setup Service

At this size, a self-managed migration is possible, but the margin for error is thinner than it looks: multiple source systems, several integrations, custom objects and years of historical activity all raise the cost of getting it wrong. The work you should demand as standard from any onboarding partner includes exactly this kind of staged migration plan, not just an import.

Conclusion

Data migration isn't the exciting part of a CRM setup. But it's the part that decides whether the team trusts the platform from the start, or spends the first six months compensating for a foundation that wasn't solid.

Clean the data before you export. Map the fields before you import. Stage the migration instead of cutting over in a weekend. Validate the results before you hand over the keys. And document every decision, including where the data actually sits, so that whatever questions arise six months from now, the answers already exist.

If your migration is more complex than a spreadsheet, we can manage the whole process, including NBH's RevOps and HubSpot work. Contact us.