Following the right HubSpot migration best practices can make the difference between a CRM that your teams can use from day one and a portal that needs months of cleanup after launch. Moving the records is only one part of the job. You also need to decide how contacts, companies, deals, lifecycle stages, ownership, workflows, reporting, and integrations should work once HubSpot becomes the system your teams depend on.
This is where migrations often become more complicated than expected. A contact can arrive in HubSpot with every property populated and still be of little use to sales if the company and open deals are no longer associated with it.
Likewise, an import can complete successfully while historical records start enrolling in new workflows, owners change unexpectedly, or leadership finds that the pipeline report no longer matches the numbers it used before the move.
HubSpot now provides tools such as Smart Transfer that can handle more of the technical movement from supported platforms, but the tool does not replace migration planning. Smart Transfer can audit supported source data, transfer records, help clean the data afterwards, and revert a transfer.
However, it remains a one-way transfer into HubSpot; additional custom field mappings require Data Hub, and Smart Transfer does not currently support custom objects.
In this blog post, we’ll walk through the HubSpot migration best practices that help protect your CRM data, preserve relationships between records, reduce cutover issues, and give your sales, marketing, and service teams a HubSpot portal they can work from after launch.
Key Highlights
- Define the migration business outcomes before choosing the method.
- Decide what to migrate, rebuild, consolidate, or remain archived.
- Clean duplicates and inconsistent values before HubSpot workflows and reports begin using them.
- Design the HubSpot data model before recreating old CRM fields and pipelines.
- Map associations and record identifiers alongside individual properties.
- Choose Smart Transfer, Data Sync, structured imports, APIs, or a combination based on the source architecture.
- Test difficult records, not just a handful of clean contacts.
- Pause or gate automation while historical production data is moving.
- Plan for records created or changed between the main migration and final cutover.
- Keep a structured hypercare period after launch so data, automation, reporting, and user issues can be addressed quickly.
What Makes a HubSpot CRM Migration Successful?
It is easy to measure a migration by record counts. If the old CRM had 75,000 contacts and HubSpot now has 75,000 contacts, the transfer appears to have worked. However, that tells you very little about whether the CRM works for the people using it.
Suppose those contacts arrive without the correct companies. Sales has now lost account context. If the open deals migrated but are associated with the wrong owners, pipeline reporting becomes unreliable. If lifecycle stages do not reflect the new qualification process, marketing may struggle to build the lists and reports it needs even though every contact technically exists.
A successful HubSpot CRM migration needs to preserve the information and relationships that support the business process. That means checking not only whether records arrived, but whether ownership, associations, lifecycle stages, deal stages, historical information, reporting, and integrations still work together.
You should also look at what happens after the transfer. Can a sales rep open a migrated company and understand its active opportunities? Can marketing build an audience using the new lifecycle model? Can leadership open a dashboard and recognize how the numbers are being calculated?
10 Tips for a Successful HubSpot Migration
Here are the 10 best practices for a successful HubSpot migration, which include:
1. Define What Success Looks Like Before You Start
Before discussing imports, CSV files, APIs, or Smart Transfer, decide what the migration is supposed to change for the business.
Perhaps sales wants to move from three inconsistent pipelines to one standardized process. Marketing may need lifecycle stages it can finally trust. Leadership may want a single pipeline dashboard instead of reports assembled manually from several systems. Or the immediate goal may simply be to retire an expensive legacy CRM without losing the information teams still use.
Write those outcomes down before the migration begins. Doing this gives the project something more useful to measure than “all records moved.”
For example, if leadership expects HubSpot to become the source of truth for pipeline reporting, the migration needs to preserve or rebuild the fields, deal stages, ownership rules, and associations required to produce that report. If marketing expects to use HubSpot lead scoring immediately after launch, the migration needs to make sure the fit, lifecycle, and engagement data behind that scoring model is available and trustworthy.
You should also assign someone who can make final decisions.
Migration projects often slow down because nobody knows who can approve whether an old field should be removed, whether historical activity needs to move, or whether two sales pipelines can be consolidated. A project owner should have enough authority to resolve those questions rather than allowing them to remain open until the production migration.
2. Audit the Source CRM Before Deciding What to Move
Once the goals are clear, take a proper look at the system you are leaving. Most established CRMs contain far more than active contacts and deals. Over time, teams add properties, custom objects, pipelines, workflows, lists, reports, integrations, and fields for processes that may no longer exist.
If you move everything automatically, HubSpot starts life carrying years of old CRM decisions. A better approach is to sort what you find into four groups: Migrate, Rebuild, Consolidate, and Archive.
Records, fields, and information that still need to exist in HubSpot belong in Migrate. Workflows, scoring rules, pipelines, and processes that should continue but need to use HubSpot functionality belong in Rebuild. Duplicate fields, overlapping lists, old stages, and unnecessarily complex processes may belong in Consolidate. Historical information the business still needs for reference but does not need in its active CRM can remain in Archive.
The Automation Strategy Group uses this same framework in its HubSpot migration work because it stops the source system from deciding the shape of the new portal. While auditing the CRM, look beyond the obvious objects. Review reports, automation, integrations, users, ownership, historical activities, and the fields that other systems depend on.
A property may look unused until finance tells you it drives the revenue report they review every month. Likewise, a workflow nobody recognizes may still be assigning inbound leads every day. This is why the audit should happen before the mapping starts.
3. Clean the Data Before HubSpot Depends on It
A migration is a good time to clean your CRM, but you do not need to make the source database perfect. Focus first on the problems that will create trouble inside HubSpot.
Duplicate contacts are the obvious example. If the same person exists three times in the old CRM, bringing all three into HubSpot can create duplicate company associations, duplicated reporting, separate workflow histories, and ownership conflicts. Resolving that before the migration is usually easier than merging the records after users and automation start interacting with them.
The same applies to company records.
You may have Acme Inc, Acme Incorporated, and Acme sitting as separate records even though they refer to the same customer. If those records each have different contacts and deals associated with them, the cleanup should happen before the migration team starts mapping associations. Then look at inconsistent values.
Country, state, industry, territory, customer type, and other dropdown fields often contain years of variations. If one system stores United States, US, and USA, decide what the HubSpot property should use and normalize the values before they become part of filters and workflows.
Inactive ownership deserves attention as well. If thousands of records still belong to former employees, decide how HubSpot should assign them before the production transfer. However, do not confuse cleanup with deleting history.
A record may no longer belong in the active CRM but still need to be retained for legal, reporting, or reference purposes. In that case, archive it rather than bringing it into HubSpot simply because it already exists.
4. Design the HubSpot Data Model Before Mapping Fields
One of the easiest migration mistakes to make is opening a mapping spreadsheet too early. Before deciding where every old field should go, decide how HubSpot should work.
Start with the standard CRM objects. How will the business use contacts, companies, deals, tickets, leads, products, and other supported objects? Does the company genuinely need custom objects, or can a standard HubSpot object and a better property structure handle the requirement?
HubSpot itself recommends reviewing whether a standard CRM object can support the business process before creating a custom object. Then work through the relationships.
Should every contact belong to one primary company? Do deals need several associated contacts? Do service tickets need company and contact associations? If the source CRM uses parent and subsidiary accounts, what part of that structure still needs to exist in HubSpot?
Next, design lifecycle stages and pipelines. Do not recreate every old pipeline simply because users recognize the names. If two teams follow the same sales process, one HubSpot pipeline may be easier to manage than two nearly identical ones. Likewise, old lifecycle stages may have been created around the previous CRM rather than the way the business now qualifies leads.
Once the HubSpot model is agreed, mapping the source CRM becomes much easier. You are no longer asking, “Where can we put this old field?” You are asking, “Does this information have a role in the HubSpot model we have already approved?”
5. Map Objects, Properties, Associations, and IDs Together
Field mapping is only one part of a HubSpot data migration. You also need to know how HubSpot will recognize the same record and which other records it should remain connected to.
A successful migration map should look like the table below:
| Migration Element | What You Need to Document |
| Source object | Where the record currently lives |
| HubSpot object | Where the record will live after migration |
| Source field | Existing CRM field |
| HubSpot property | Destination property |
| Data type | Text, date, dropdown, number, etc. |
| Transformation | Formatting or value changes needed |
| Identifier | How HubSpot will recognize the record |
| Association | Which contacts, companies, deals, tickets, or other records should remain connected |
| Decision | Migrate, rebuild, consolidate, or archive |
Associations deserve as much attention as properties. Consider an open deal linked to one company and three contacts in the old CRM. If the deal amount, stage, and close date all transfer correctly but those relationships disappear, sales has lost the people and account context behind the opportunity. The deal migrated. The business process did not. Identifiers also need careful planning.
Email is often useful for matching contacts, but real CRM databases contain shared inboxes, missing email addresses, duplicate emails, and contacts who changed companies while keeping the same personal address. Companies may use domain names, external system IDs, or another unique identifier.
For deals, tickets, custom records, and other objects, preserving the original CRM ID as a HubSpot property can also make validation and troubleshooting easier. When an issue appears after migration, being able to compare one specific source record with one specific HubSpot record saves a lot of time.
6. Choose the Migration Method After You Understand the Data
It is tempting to pick the tool at the beginning because that makes the project feel more concrete. However, the data should determine the migration method, not the other way around.
HubSpot now offers Smart Transfer for several supported platforms, including Salesforce, Dynamics 365, Zoho CRM, Pipedrive, ActiveCampaign, Account Engagement/Pardot, Marketo, and others. Smart Transfer can audit the source, transfer supported data into HubSpot, help with cleanup, and revert a transfer.
Read More: Pardot to HubSpot Migration Checklist
For a relatively standard source system, that can remove a lot of manual work. At the same time, you need to understand its boundaries. Smart Transfer is one-way into HubSpot. Custom field mappings require a Data Hub subscription, and HubSpot currently does not support custom-object transfer through Smart Transfer. Some additional data types use a one-time post-sync transfer and will not continue updating automatically afterward.
Data Sync solves a different problem. It can keep supported records aligned between HubSpot and another platform using one-way or two-way synchronization, which can be useful when the systems need to operate together during a phased transition.
Structured imports also remain useful. If the dataset is controlled and the migration team understands the identifiers, associations, field types, and import order, file-based migration can provide a lot of visibility over what moves and when.
More complicated environments may need APIs, middleware, or a partner-led migration. This becomes more likely when the source contains unusual relationships, several custom objects, heavy transformation requirements, or historical records that standard tools cannot represent cleanly.
A migration can also combine methods. The standard CRM records might move through a HubSpot-supported tool while specialized historical or custom records use another route. That is perfectly reasonable. The migration architecture should fit the data.
7. Protect Record Identity and Associations
This deserves its own migration best practice because broken relationships can be harder to spot than missing records. Imagine running a validation report after migration and finding that 25,000 contacts existed in the source CRM and 25,000 contacts now exist in HubSpot. That sounds successful.
Then the sales team opens HubSpot and finds that 4,000 of those contacts are no longer connected to the correct company. The record-count check passed, but the migration still damaged the sales process.
Before production migration, document how each important association will be preserved. That includes contact-to-company, contact-to-deal, company-to-deal, ticket relationships, product relationships, and custom-object associations where relevant.
HubSpot’s current Smart Transfer support illustrates why this matters. For Salesforce, for example, HubSpot explicitly maps Account relationships into Contact-to-Company and Deal-to-Company associations and can transfer Opportunity Contact Roles into Contact-to-Deal associations.
This kind of relationship mapping should be part of your plan regardless of the source platform or migration method. The same principle applies to identity.
If contact email is your main matching field, define how the migration handles missing or duplicated email addresses. If company domain is your identifier, decide what happens when two companies share a parent domain. Document those exceptions before they appear in production.
8. Run a Test Migration With Real Edge Cases
Your test migration should not contain ten perfect contacts selected because they are easy to verify. Choose the awkward records.
Include the customer with several open deals. Add the contact associated with more than one company. Test a former employee who still owns records. Include a deal with old dates, unusual currency, or custom fields. If the source database contains records without email addresses or with incomplete information, include some of those too. Those records are where mapping decisions get tested properly.
After the test migration, compare the source and HubSpot record by record. Do the property values match? Are the owners correct? Did dates retain the right format? Did dropdown values map as expected? Are company and deal relationships intact? Can users find the information in the place where you expect them to work with it?
Then test the business process around those records. If the migrated deal is supposed to appear in an executive pipeline dashboard, check the dashboard. If a contact should qualify for a segment, build the segment. If an associated company field should drive routing, test the routing rule.
A successful test does not prove that records can be imported. It proves that the HubSpot structure can support the records after they arrive.
9. Control Workflows, Integrations, and Cutover Carefully
Historical data can behave like new data if you do not control HubSpot automation during migration. Suppose you import 60,000 contacts and 8,000 of them meet the enrollment criteria for an active MQL workflow. HubSpot does not know that those contacts are historical records being migrated unless your workflow logic tells it so.
Suddenly, old leads can change lifecycle stage, generate tasks, trigger internal notifications, enter nurture sequences, or be assigned to sales reps. That is why important automation should be reviewed before the production migration.
Some workflows may need to be paused. Others can remain active but require a temporary suppression rule or migration flag. In some cases, you may want the workflow to operate only on records created after the go-live date.
Integrations need similar treatment. If another application is still updating the source CRM while production data is moving into HubSpot, decide which system owns the data during the transition. Otherwise, a field can be migrated into HubSpot on Monday and change in the old CRM on Tuesday without anyone capturing the update.
This leads to another important cutover issue: the delta migration. HubSpot’s current migration guidance recommends freezing the source system at go-live and migrating records created or updated between the main production migration and that freeze point.
HubSpot specifically calls out this delta run because even a short migration window can produce a meaningful amount of new or changed CRM data. Plan the delta migration from the beginning rather than trying to identify the missing records after launch.
10. Validate the Migration After Go-Live and Plan for Hypercare
Once users log into HubSpot, the migration enters a different phase. At this point, you are testing the CRM under real working conditions rather than controlled migration scenarios.
Start by reconciling the production dataset again. Compare record totals, ownership, associations, lifecycle stages, pipelines, and other critical information against the agreed source baseline. Check the workflows and integrations that were activated after migration and make sure they behave as expected with newly created records.
Then ask your users to work normally. Have a sales rep process a new inbound lead. Ask a manager to run a pipeline review from HubSpot. Let marketing build a segment from the migrated data. Ask service users to open customer records and confirm the history they need is available. Those activities often reveal issues that a migration team would never find by looking only at import logs.
HubSpot now treats hypercare as a formal post-go-live stage and describes a two-to-four-week stabilization period in its current CRM migration guidance. HubSpot recommends assigning an owner, maintaining a shared issue log, reviewing problems frequently during the first week, and keeping the source CRM in read-only mode until the agreed stabilization criteria have been met.
This approach makes sense because go-live does not prove the system is stable. It simply gives real users the chance to test it at normal volume.
HubSpot Migration Best Practices by Project Stage
These HubSpot migration best practices become easier to manage when you group them by project stage. The exact timeline will vary depending on the source system and the amount of customization, but the order should stay broadly consistent. See the table below:
| Migration Stage | Priority | Question to Answer |
| Planning | Goals and ownership | What needs to work after migration? |
| Source audit | Current data and processes | What should migrate, rebuild, consolidate, or archive? |
| HubSpot design | Destination architecture | How should teams operate inside HubSpot? |
| Mapping | Fields, IDs, and relationships | Where does each record and association belong? |
| Testing | Data and process validation | Do representative records work correctly? |
| Production migration | Controlled data movement | Which automation and integrations need to be paused or gated? |
| Cutover | Final source changes | How will records changed during the migration window be captured? |
| Hypercare | Stability and adoption | Can users complete normal work without returning to the old CRM? |
Notice that the actual record transfer sits relatively late in the process. That is deliberate. By the time production data starts moving, the difficult questions about scope, data structure, mappings, and system ownership should already have answers. If those decisions are still being debated during the final import, the project is not ready for cutover.
Read More: Common CRM Migration Questions
Which HubSpot Migration Method Should You Use?
The right HubSpot migration method depends on the source system and the amount of work required to make that data useful inside HubSpot. If your source platform is supported by HubSpot Smart Transfer and the CRM mainly uses standard objects and relationships, Smart Transfer may be a good place to start. It can handle much of the transfer process while still giving you opportunities to review mappings and control what moves. However, remember that the transfer is one-way and custom-object transfer is not currently supported.
If both systems need to remain active for a period, HubSpot Data Sync may be more appropriate because supported integrations can run one-way or two-way synchronization. That can help during phased transitions, but it also means you need clear rules around source-of-truth fields and which records are allowed to synchronize.
For simpler or highly controlled datasets, structured imports can still be effective. They give the migration team direct control over transformation and sequencing, provided the identifiers and associations have been planned correctly.
When the source CRM contains unusual custom objects, extensive historical data, complicated associations, or several systems that need to change together, an API or partner-led migration may be the better route. The important point is not to choose the most sophisticated migration method. Choose the one that fits the data you actually have.
Common HubSpot Migration Challenges to Watch For
Here are the most common HubSpot migration challenges you need to look for before migrating, which include:
1. Every old CRM property gets recreated in HubSpot
This usually happens when teams treat migration as copying rather than redesigning. The result is a new HubSpot portal filled with legacy fields, duplicate concepts, and properties that users do not understand. Over time, those fields find their way into workflows, lists, and reports, which makes removing them much harder.
Before creating a HubSpot property, ask how the business expects to use it after launch. If it does not support an active process, report, integration, user need, or retention requirement, it may belong in the archive rather than the new CRM.
2. Contacts arrive without the right Companies or Deals
Association problems often stay hidden until users start working inside HubSpot. A salesperson opens a contact and cannot see the company. A manager finds deals without the right stakeholders. Marketing builds an account list and discovers that migrated contacts are missing company relationships. This is why association testing should be separate from record-count validation.
Take a representative sample of customers, target accounts, open deals, and unusual relationships and verify them manually before declaring the migration complete.
3. Historical records trigger new HubSpot automation
This problem appears when automation is designed for future activity but remains active during migration. A workflow may see a historical record that meets its criteria and treat it exactly like a brand-new lead or customer.
The safer approach is to review the automation before the production run and decide whether each workflow should be paused, filtered, or allowed to operate on migrated records. This becomes especially important for workflows that send emails, create sales tasks, change ownership, or alter lifecycle stages.
4. Reporting changes after go-live
Different CRM platforms often calculate or structure reporting differently. If the pipeline number in HubSpot does not match the old CRM, start by comparing definitions rather than assuming the migration lost deals.
Check pipeline inclusion, deal stages, currencies, ownership, close dates, lifecycle definitions, and the source properties feeding the report. Sometimes the new report exposes a weakness that already existed in the old CRM. In other cases, the migration map needs to be corrected.
Either way, agree on the future reporting definition rather than trying to force HubSpot to reproduce a legacy dashboard without understanding the calculation behind it.
5. Records created during cutover disappear
This tends to happen when the team runs the main migration but allows the source CRM to stay active without a plan for late changes. A sales team can create a surprising number of contacts, opportunities, activities, and field updates in only a few days.
If those records are not included in the final delta migration, HubSpot begins with a gap on day one. Build the source freeze and delta transfer into the production plan. HubSpot’s current guidance places both directly in the go-live sequence for exactly this reason.
How The Automation Strategy Group Can Help
The Automation Strategy Group is a certified HubSpot Solutions Partner that helps US B2B companies move from platforms such as Salesforce, Marketo, Eloqua, ActiveCampaign, and other CRM or marketing automation systems into HubSpot. Our team reviews records, properties, associations, workflows, pipelines, reporting requirements, and integrations, then determines what should migrate, what needs to be rebuilt using HubSpot, what can be consolidated, and what should remain archived.
From there, we can handle the HubSpot setup, migration mapping, source-data preparation, property and association structure, migration execution, workflow and pipeline rebuilding, testing, validation, documentation, and team handover under the same engagement.
The Automation Strategy Group is a US-based, senior-only consulting team that has worked with CRM and marketing automation platforms since 2016, and holds HubSpot accreditations covering CRM Data Migration, CRM Implementation, Solutions Architecture Design, Custom Integration, and Service Implementation.
Planning a move to HubSpot? Schedule a free consultation with one of our HubSpot migration experts.
Frequently Asked Questions
What are the best practices for a HubSpot migration?
The best practices for a HubSpot migration start with defining what the new CRM needs to support, auditing the source system, cleaning the data, and designing HubSpot before production records move. From there, teams should map fields and associations, test representative records, control automation during cutover, reconcile the data after launch, and keep a structured hypercare period.
What should I do before migrating data to HubSpot?
Before migrating data to HubSpot, review the source CRM and decide which records, fields, processes, and historical information still have a business purpose. You should also clean important data issues, design the HubSpot object and pipeline structure, document associations and identifiers, and agree on how the migration will be validated before production transfer begins.
Should I clean CRM data before migrating to HubSpot?
CRM data should be cleaned before a HubSpot migration wherever the issue could affect matching, associations, workflows, reporting, or user experience. Duplicate contacts and companies, inactive ownership, inconsistent field values, and obsolete records are good places to start. However, historical information that does not belong in the active CRM may be better archived than deleted.
What data should I migrate to HubSpot?
The data you migrate to HubSpot should include the information your sales, marketing, service, operations, reporting, and integration processes still need. You do not need to recreate every field and historical record from the old CRM. Review each area and decide whether it should migrate, be rebuilt, consolidated with another process, or remain archived.
How do I map CRM data to HubSpot?
CRM data mapping should document the source object and field, destination HubSpot object and property, data type, transformations, unique identifiers, and required associations. Mapping relationships at the same time as properties helps prevent contacts, companies, deals, and other records from arriving without the connections users need.
How can I avoid duplicate records during a HubSpot migration?
Duplicate records are easier to control when you define the matching rules before the migration. Review the source CRM for duplicate contacts and companies, decide which identifiers HubSpot should use, and test records with missing or shared identifiers before production migration. Do not rely on record names alone when stronger unique IDs are available.
How do I preserve associations when migrating to HubSpot?
Preserving associations requires documenting which source relationships need to exist in HubSpot and ensuring the migration method can recreate them. Contact-to-company, contact-to-deal, deal-to-company, ticket, and custom-object relationships should be included in the migration map and tested separately from individual property values.
Should I use HubSpot Smart Transfer for my migration?
HubSpot Smart Transfer can work well when your source platform is supported, and your data fits the objects and field types it can transfer. It can audit source data, move supported records, help with cleanup, and revert a transfer. However, it is one-way into HubSpot, custom mappings require Data Hub, and custom-object transfer is not currently supported, so more complex migrations may need another method.
How should I test a HubSpot migration before go-live?
Test the migration with records that represent the difficult parts of your database, not only clean contacts. Include active customers, open deals, unusual associations, missing values, different owners, and records that depend on important custom fields. Then validate both the record data and the business processes, reports, and associations that depend on it.
What should I check after a HubSpot migration?
After migration, check record totals, ownership, associations, lifecycle stages, pipelines, historical information, workflow behavior, integrations, and the reports leadership relies on. Users should also complete their normal sales, marketing, and service tasks during the post-launch period. HubSpot currently recommends a structured 2-4 week hypercare phase following CRM go-live.
