Lessons from 25 CRM Migrations: Make the first 30 days count 

After 25 Salesforce & Hubspot CRM migrations, the patterns repeat. The tech stacks change. The vendor names change. The mistakes don't.

Teams walk in thinking the hard part is the data. It isn't. The hard part is that every decision they defer in the first month. Here is what keeps going wrong, and what works.

Most CRM migration problems are discovery problems

The decisions you defer in week one set the blast radius of everything that follows. If you're still mapping objects in month three, you started too late.

Scope creep isn't a planning failure. It's a symptom of incomplete discovery.

Get a full data and report inventory done before anything else. List every object, every custom field, every report anyone depends on. Then answer the retention question in writing: how far back for cases, activities, campaigns, contracts, attachments? This one answer drives volume, timeline, and tool selection. Debating it in month four costs weeks.

Lock the answer, get sign-off, and move on.

Decide "migrate as-is or redesign" for every major process

This is the most consequential call in any Salesforce or Hubspot CRM migration. Choosing to redesign a complex process halfway through compounds complexity in every direction. New fields reopen old automation decisions. New automation reopens old reporting decisions. The migration quietly becomes a re-implementation.

For each major workflow, pick one lane explicitly and record it. Write it down. "Lead routing migrates as-is. Deal stages get redesigned. Renewal workflow migrates as-is." Short, specific, committed.

"We'll figure it out later" is how a six-month project becomes a twelve-month project.

Declare a development freeze, in writing

Once Salesforce or Hubspot CRM migration prep begins, new development in the source org has to stop. Custom fields, automations, layout changes, integration tweaks, validation rules, page layouts, all of it.

Agree the freeze date upfront with every affected team. What gets built after the freeze lives outside the migration. No exceptions, because exceptions become the project.

If a truly urgent change appears, route it through a change control process with one owner and a written approval trail. Three informal "quick adds" after the freeze will cost more testing time than the change itself.

Get compliance, legal, and finance in the room early

Teams skipped during scoping show up loud in the final week, when changes cost the most.

Finance, legal, and compliance consistently surface requirements late. SOC 2 dependencies on opportunity data. Separate agreement objects used by legal. ARR field definitions that differ from what RevOps assumes. Retention rules tied to regulatory obligations. Every one of these is cheap to handle in week two and expensive to handle in week twenty.

Run a compliance and legal requirements workshop during discovery. Map every regulated data element. Document who owns it. Keep a stakeholder list that includes the quiet teams, not just the ones who showed up to the kickoff.

Audit every automation before you move a record

Most CRMs carry years of undocumented automation debt. Workflows built by someone who left two years ago, still firing in production, still quietly touching records.

Inventory all of it: workflow automations, assignment rules, validation rules, scoring logic, field triggers, sequence enrollments, third-party integrations. For each one, document what it does, who built it, when it last changed, and which call applies:

• Migrate as-is

• Rebuild

• Retire

  
  

Automations that "probably still do something useful" and get migrated by default are how complexity moves from one system to another without ever being resolved. The Salesforce or Hubspot CRM migration is your one chance to close that loop. Use it.

Size the rebuild work as its own workstream. Logic that took five minutes to configure in one platform often needs a different approach entirely in another. It is not a final-sprint task.

Deduplication is a workstream, not an afterthought

Duplicate data is always worse than expected. When you consolidate multiple orgs, duplicates compound.

The sequence matters. Clean each source separately first. Reconcile the combined dataset second. Skipping the first step produces merged duplicates that carry conflicting field values across records nobody can untangle after the fact.

Treating dedup as a final-week cleanup is how migrations derail. Build it in as a named workstream with an owner, a timeline, and a clean definition of done.

Security and access models rarely line up

A heavily restricted, territory-based model and an open, role-based model cannot simply be merged. Pretending they can produces a testing phase where half the users can't see their own records and the other half can see everything.

Run a security model alignment workshop in discovery. Map each system's access model side by side. Identify the conflicts. Pick a target model. Document the decision and the migration path. Do this before the testing phase.

Testing time is not a buffer

When migration runs late, testing is the first thing squeezed. It shouldn't be.

If your Salesforce or HubSpot CRM data migration runs over, the go-live date moves. Testing time stays fixed. Establish this as governance before the project starts, not as an argument you lose after the schedule slips.

Two testing traps worth naming.

Staging is not production. Layouts, validation rules, user profiles, disabled workflows, they all drift between environments. Rules disabled during data loads have to be re-enabled in a systematic way. Keep a staging-to-production delta log and review it before every go-live checklist.

UAT needs one template. Discovering that one team has an excellent template and everyone else improvised is a quality control failure. Standardize the UAT template at kickoff. Cover objects, fields, automations, integrations, and user roles. Apply it the same way across every team.

Back up everything. More than once.

A single backup at kickoff is not a backup strategy. Take named checkpoint exports throughout the project:

• Pre-migration baseline (data and configuration, separately)

• Post-deduplication

• Post-load per object group

• Pre-go-live

Label each one clearly with a date and description. These become your rollback points when something breaks downstream, which it will.

Two easy misses.

Data and configuration need separate backups. A data export does not cover automation, field definitions, page layouts, or permissions. Back those up on their own schedule.

Test your restore. A backup you've never restored is a backup you don't actually have. Run a sample restore from the baseline before you need it, not after.

Store exports in a shared, access-controlled location, version-controlled, with a naming convention that works if the project lead is on holiday when the incident hits.

Build real buffer into the timeline and write down Plan B

Every experienced Salesforce or Hubspot CRM implementation lead is skeptical of aggressive go-live dates for good reason. Build 20 to 30 percent buffer in explicitly, at the plan stage, labeled as buffer. Hidden buffer gets spent on optimism. Labeled buffer survives.

Before go-live, write down Plan B. What happens if you need to extend the freeze window? Push the go-live date? Pre-migrate non-critical objects and hold the rest? Cut scope?

Decide the criteria now. Write them down. Share them with the steering committee before the decision matters. Having no Plan B when you need one is a bad place to be.

One decision log, enforced

Decisions made in meetings need to be recorded, and everyone needs to use the same place. Notion, Confluence, Jira, a single shared doc, the tool matters less than the discipline.

Pick one. Establish the protocol at kickoff. Assign someone to enforce it. Make documentation a prerequisite for closing any decision.

When decisions live in three tools, two Slack threads, and one person's head, they get relitigated. Relitigated decisions are where timelines go to die.

The pattern

Every lesson here traces back to the same root cause. Decisions that belong in the first 30 days happen in the final 30 days instead.

Discovery. Retention. Migrate-or-redesign. Freeze. Automation inventory. Stakeholder map. Security model. Backups. Buffer. Plan B. One decision log.

Get them done before anyone touches a record. The migration gets easier. Skip them, and you'll have a much more exciting project.

If you are starting a Salesforce & Hubspot CRM migration this quarter, treat the first 30 days as the most valuable 30 days of the project. Because they are.