CRM migration project plan: phases, timeline, cutover

A CRM migration project plan is a dated sequence of five things: an audit of what you have, a data model for the new system, a mapping document, a phased load with a pilot, and a cutover with a rollback option. Everything else is detail hanging off those five. This page gives you the plan, the mapping decisions that go wrong most often, and the honest answer to the question nobody asks until week six: what actually moves between two CRMs, and what has to be rebuilt.

The project plan at a glance

This is the ten-week default we work to. It is a starting shape, not a law. Complexity moves it, and the biggest mover is not record volume but how many integrations and custom objects you carry.

Published timelines disagree with each other, so treat any single number with suspicion. SyncMatters puts mid-market migrations at four to six months and notes that most teams underestimate by 30 to 50 percent. LOW/CODE puts mid-market migrations with custom objects at eight to sixteen weeks, and Get CRM Consultant at ten to twenty weeks including planning and go-live. The range is wide because "migration" means a spreadsheet import to one team and a Salesforce decommission to another. Size your plan against your integration count, not against someone else's calendar.

One number both timeline sources agree on: data preparation, meaning cleansing, deduplication and mapping, is the largest single consumer of project time. SyncMatters puts it at 40 to 60 percent of the total. Plan accordingly, and put the buffer there rather than at the end.

What actually transfers between CRMs, and what does not

This is the section most migration guides skip, and it is the one that produces the week-eight emergency. Teams assume a migration moves the CRM. It does not. It moves records and properties. Almost everything that makes the CRM feel alive, the call logs, the email threads, the attachments, the workflows, is a separate workstream or a rebuild.

The activity history point is the one worth arguing about internally before you sign anything. HubSpot's own import flow supports notes but not other activity types, a limitation its users have been raising in the HubSpot community for years. Preserving calls, meetings and logged emails means an API-based load that writes them as engagement records, which is developer work or a paid migration tool, not a CSV. Vantage Point makes the same point about Salesforce to HubSpot moves and adds the practical consequence: logged emails are among the most fragile data classes in any migration, and many teams end up migrating recent history in full detail and archiving the rest.

Attachments follow their own path. Vantage Point states plainly that HubSpot has no native bulk import for Salesforce attachments and that files need a separate workstream with re-association afterwards. If your commercial or legal team relies on signed documents living on the account record, find that out in week one, not at cutover.

The three questions to settle before mapping starts

• How far back does history have to be readable in the new system? Full fidelity for two years and an archive for everything older is a cheaper answer than full fidelity forever, and it is usually the right one.
• Readable where? A read-only legacy instance, a data warehouse, or a flat export in cold storage are all valid. They cost very different amounts.
• Who signs off that the loss is acceptable? Put a name against it. This is the decision that gets relitigated at cutover if it was never made explicit.

Why your previous CRM failed, and what to learn from it

Before you evaluate platforms or map a single field, run the retrospective. Why did the current system end up where it is? Until that is answered honestly, you are buying the same problem in a new interface.

Published failure rates disagree enough that you should not plan against any one of them. Johnny Grow puts the CRM failure rate at around 55 percent, defining failure as not meeting planned business objectives. LOW/CODE reports a spread of roughly 30 to 63 percent across studies, with Gartner's figure for outright failure nearer 30 percent, and attributes the spread to the definition rather than to the underlying reality. What the sources do agree on is where the failures come from: adoption, data quality and training, not the software. LOW/CODE puts technology at only 6 to 10 percent of causes.

That agreement is the useful part. It tells you the retrospective matters more than the platform shortlist.

The six reasons CRMs get retired

Across CRM architecture and HubSpot migration work, the same six patterns come up.

1. Architectural limitations. Legacy systems stop scaling with business complexity. You have outgrown the platform and nobody wants to say so.

• Warning sign: you constantly ask "can the CRM do X?" and the answer is always "not natively."
• Lesson: evaluate against where the business will be in 24 months, not where it is.

2. Data fragmentation. The CRM holds contacts, but deal intelligence lives in spreadsheets, communication history lives in email, and customer health lives in the support tool.

• Warning sign: nobody trusts CRM reports because everyone knows the real data is elsewhere.
• Lesson: plan integrations from day one. A CRM without connected sources is an expensive Rolodex.

3. User adoption resistance. Clunky workflows push teams back to spreadsheets. If entering data takes longer than the alternative, adoption always loses.

• Warning sign: reps maintain personal spreadsheets alongside the CRM.
• Lesson: prioritise the daily-use experience over the feature matrix. We wrote up the full pattern in CRM adoption: why reps won't update it.

4. Integration debt. Custom integrations built years ago become maintenance liabilities. Nobody remembers how they work and one API change breaks three workflows.

• Warning sign: when something breaks, there is a scramble to find the person who built it.
• Lesson: prefer native connectors, document everything, and assume the builder will not be there to fix it.

5. Compliance and security gaps. Regulatory requirements have outpaced the platform. Data handling that was fine five years ago is now real risk.

• Warning sign: legal or security has flagged CRM data handling.
• Lesson: evaluate data residency, consent management and audit capability during selection.

6. Cost-benefit inversion. Maintaining the system costs more than replacing it. Licence spend rises while adoption falls.

• Warning sign: you are paying enterprise prices for small-business usage.
• Lesson: calculate total cost of ownership over three years, including implementation, training and customisation.

The retrospective questions to answer

• What three things did the old CRM do well that we must preserve?
• What three things did it do badly that we absolutely cannot repeat?
• Which integrations were essential, and which created more problems than they solved?
• What data actually drove decisions, and what was collected and ignored?
• Who were the power users, and what made them successful?

Migration is a chance to reset. It is only a reset if you learn from what went wrong.

Migrating off a homegrown or legacy CRM

Homegrown systems break the standard plan in three specific places, so give them their own week in phase 0.

• Export is the first risk, not the last. Legacy and in-house systems often have no clean export path, proprietary formats, or fields whose meaning lives only in someone's head. Prove you can get the data out before you plan anything else.
• The business logic is not in the data. Assignment rules, stage progression, and pricing logic are usually buried in application code. Inventory them as requirements, not as data to migrate.
• Do not replicate the old shape. Rebuilding a homegrown CRM's quirks inside a modern platform gets you the same system with a new licence fee. Map old workflows to the outcomes they served, then design fresh.

The same applies when you are moving between vendors rather than off a homegrown build. If you are weighing where to land, our Attio vs HubSpot comparison covers the trade-offs, and CRM for startups covers choosing by stage so you are not migrating again in eighteen months.

Migrating from spreadsheets to a CRM

This is a smaller project than a platform-to-platform move, and it fails for a different reason: there is nothing forcing the data to be consistent, so it never was.

• The cleanup is the project. Nutshell makes the point that quality problems hidden in spreadsheets surface during migration and have to be resolved up front, not after. Duplicate contacts, inconsistent company naming and half-populated columns are the norm, not the exception.
• Decide the object model before the import. A spreadsheet has rows. A CRM has contacts, companies and deals with relationships between them. One row is often three records. Getting that split wrong is what leaves you with contacts unattached to companies and reporting that never works.
• Find the shadow copies. There is rarely one spreadsheet. Ask each rep what they actually work from, then reconcile before importing anything.
• Reporting history does not survive. Pipeline snapshots, forecast history and activity logs generally do not exist in a spreadsheet in a form a CRM can consume. Say so at the start so nobody expects a trend chart on day one.

The realistic window for a small team with clean data is a few weeks. Nutshell notes that timelines run 30 to 50 percent longer than first estimates once testing and training are included, which matches the SyncMatters figure for larger projects.

What a CRM migration costs

Nobody publishes their real numbers, so treat the following as reported market ranges rather than a quote, and note that the two sources disagree at both ends.

Two things are worth extracting from that. First, complexity drives cost far more than record volume does, which is why integration count is the better sizing input than database size. Second, both sources put pre-migration cleanup on the credit side of the ledger rather than the debit side: LOW/CODE reports that a cleanup phase before the load reduces total project cost by 25 to 35 percent, because dirty data discovered mid-migration adds weeks.

The costs that get missed in the first budget are consistent: data cleanup effort, integration rebuilds, training that continues past go-live, and the internal time of the people running the project. That last one is usually the largest and is almost never in the spreadsheet.

What you really need in your new CRM

Feature comparison spreadsheets are seductive. Every vendor has one and every one of them shows that vendor winning. What you need is a way to separate essentials from distractions.

Must-have versus nice-to-have

Platform comparison: HubSpot, Salesforce and Attio

There is no universally best CRM. Context decides. This is an honest read of what we see work for different shapes of organisation, and it is our judgement rather than a benchmark.

On supported sources, HubSpot's migration documentation lists ActiveCampaign, Copper, Keap, MailChimp, Microsoft Dynamics 365, Pipedrive, Zoho CRM, Marketo and Salesforce Account Engagement. Being on that list means there is a supported path for records and properties. It does not mean your activity history comes with it.

Questions to ask vendors that they would rather you did not

• What is total cost of ownership over three years, including implementation, training and support?
• How do you handle data residency for GDPR?
• What happens to my data if we leave the platform, and in what format?
• What are your API rate limits, and what happens when we exceed them during a bulk load?
• How long does the average customer take to reach full adoption?
• What percentage of customers need custom development beyond standard configuration?
• If your mapping tool produces a bad load, who fixes it and at whose cost?

That last question is not rhetorical. It is one of the queries this page gets found for, and it does not have a standard industry answer, which is exactly why it belongs in the contract rather than in the kickoff call.

Building your CRM data model

This is where migrations succeed or fail. A data model is the structural blueprint of the CRM: what you collect, how it is organised, and how the pieces relate.

Think of a floor plan. A bad one means rooms do not connect logically and every renovation is painful. A good one means movement is intuitive and you can add rooms without tearing down walls.

Your data model determines whether reports tell accurate stories, whether automation can actually automate, whether attribution shows the truth, and whether the team trusts what they see.

The three core objects

Contacts (people). Individual humans you interact with.

Essential properties: first name, last name, email, phone in a standardised format, job title, lifecycle stage, lead source.

Worth considering: buying authority level, technology stack, communication preferences.

Common mistake: creating a contact for every email address without linking to a company. Orphaned records and broken reporting follow.

Companies (accounts). The organisations you sell to or serve.

Essential properties: company name and domain, industry as a standardised dropdown rather than free text, employee count, annual revenue, location.

Worth considering: account tier, customer since date, churn risk score, expansion stage.

Common mistake: not using the domain field for automatic contact-to-company association, which leaves you linking records by hand forever.

Deals (opportunities). Revenue opportunities with a value and a close date.

Essential properties: deal name, amount, close date, pipeline stage, owner, associated contacts and company.

Worth considering: deal type, decision criteria status, competitor presence, champion identified.

Common mistake: associating only the primary contact. When the deal closes with one contact linked, marketing cannot show which campaigns touched the buying committee and attribution breaks.

Relationship mapping

• Contact to company: many-to-one.
• Contact to deal: many-to-many.
• Company to deal: one-to-many.

Attribution, reporting and automation all depend on these being right. If a deal closes and the contacts involved are not associated, you cannot show marketing return and you cannot trigger the right follow-up.

Property standardisation rules

Naming conventions. Lowercase with underscores, prefixed by function. Good: sales_win_reason, marketing_campaign_source. Bad: Win Reason, campaignSource, winReason.

Field types. Dropdown when values are predefined and exclusive. Multi-select when a record can carry several. Number for anything you will calculate or filter numerically. Date for anything time-based. Checkbox for yes or no flags.

Required versus optional. Be ruthless. Only require fields essential to a core workflow. Over-requiring creates friction and produces garbage entered to escape the form.

The pre-migration audit

The number one migration mistake is moving dirty data into a clean system. You end up with the old problems in a new interface.

Data health assessment

Record inventory: total contacts, companies and deals; orphaned records; anything with no activity in 24 months or more.

Duplicate analysis. Duplicates hide behind email variations, company name variations, and records created through different touchpoints. For a benchmark to score yourself against, Landbase reports that organisations without an active data-quality programme commonly run duplicate rates in the 10 to 30 percent range, against a widely used target of under 5 percent. Measure yours before you promise anyone a number.

Completeness rates. What percentage of records carry the fields you depend on? Contacts with a valid email, companies with an industry, deals with a close date, contacts linked to companies.

For context on how bad this usually is: Validity's State of CRM Data Management in 2025, a survey of 602 CRM users and administrators across the US, UK and Australia, found that 76 percent of organisations say less than half their CRM data is accurate and complete, and 37 percent reported losing revenue as a direct consequence. If your audit comes back looking fine, audit again.

Data quality scoring. Flag invalid email formats, impossible dates, conflicting values and phone numbers that do not parse. The mechanics are covered in more depth in CRM data quality: why your reports keep lying.

Integration dependency mapping

Categorise each one as essential (must be rebuilt), important (rebuild, but the business survives a gap) or legacy (sunset during migration). If the architecture underneath is already point-to-point spaghetti, migration is the moment to fix it rather than recreate it: CRM integration: stop the point-to-point spaghetti.

Stakeholder alignment and goals

Run department workshops with sales, marketing, customer success and finance. Ask each team the same three questions: your top three CRM pain points, the one report you wish you had, and the integration most critical to your daily work. Document the answers in a requirements matrix and prioritise by business impact rather than by who is loudest.

Then turn vague goals into measurable ones.

These are examples of the shape a target should take, not benchmarks to adopt. Set the numbers from your own baseline.

Data preparation and cleanup

Budget more time here than feels reasonable. It is the phase that both timeline sources identify as the largest.

Deduplication

Duplicates come from predictable sources: multiple form submissions, email variations, import errors across data sources, and manual entry inconsistency.

• Use native deduplication first. HubSpot has built-in duplicate management.
• Consider enrichment tooling such as Clay to identify matches across variations.
• Establish merge rules before you merge anything. Which record becomes the source of truth? Usually the one with the most recent activity and the most complete data.
• Document merge decisions. You will be asked to justify one.

Worth knowing before you set a target: deduplication is not a one-time event. Contact data goes stale continuously, at rates Cognism and others put in the tens of percent per year, which is why a clean-at-cutover database is dirty again within a year without a maintenance process. We covered the decay maths in CRM data decay.

Cleansing checklist

• Standardise phone number format
• Normalise email addresses to lowercase
• Convert date fields to ISO 8601 (YYYY-MM-DD)
• Map legacy picklist values to new standardised values
• Archive records with no activity in 24 months or more
• Validate email addresses and remove hard bounces
• Fill critical missing fields via enrichment or manual follow-up

Field mapping

The mapping document is the deliverable that matters most and the one most often left half-finished. Every source field needs a destination or a written reason it has none. "We will figure that one out later" is how fields arrive in production as free text.

Handling missing data

Not every gap needs filling. Leave it blank when the field is not critical and does not drive automation. Use an explicit placeholder when a workflow requires a value. Enrich programmatically for standard B2B firmographics. Flag for manual follow-up only when the field is business-critical and cannot be filled any other way.

Executing the migration

Phase 0 is the audit above. Phase 1 is the data model and the mapping document. Everything from here is execution, and the sequence matters more than the calendar: no phase starts until the one before it has met its exit criterion.

Phase 2: sandbox testing (weeks 3-4)

• Extract a sample of roughly 10 percent of your data across all object types.
• Run the load into a test environment.
• Validate: are properties mapping correctly, are relationships preserved, are formats standardised?
• Document what failed and what surprised you, adjust the transformation logic, repeat.

Agree the pass threshold in advance and write it down. We work to a low single-digit error rate on the sample before proceeding, but the right number is the one your team will actually hold the line on rather than one borrowed from a blog post.

Note the platform limits while you are sizing this. HubSpot's documentation puts import files at just over a million rows each and daily import volume in the millions, with a cap on how many imports run at once, so raw volume is rarely the constraint. API rate limits during an activity load usually are. Check the imports API documentation and the import file format guide against your record counts before promising a load window.

Phase 3: pilot rollout (weeks 5-6)

• Load the full dataset into production after the sandbox passes.
• Onboard power users first: ten to fifteen people across sales leadership, marketing ops and customer success.
• Run daily standups so issues surface immediately.
• Collect what is missing, what is confusing, what is broken, and refine before anyone else arrives.

Phase 4: full rollout (weeks 6-9)

Phase by department, sales first because they are the highest-volume and most CRM-dependent users, then marketing and customer success, then finance, operations and executives.

Support model: departmental champions who can answer peer questions, daily office hours for the first fortnight, a dedicated channel for questions, and a running document of common issues that feeds back into training.

Phase 5: cutover, rollback and the parallel run

Cutover is a decision, not an event, and it should be reversible.

• Make the legacy system read-only rather than switching it off. Reads stay available, writes stop, and there is no ambiguity about which system is the source of truth.
• Define rollback criteria before cutover, not during it. Agree in advance which reconciliation failures trigger a rollback, so the decision is arithmetic rather than argument.
• Run parallel for a period matched to how critical the system is. Easy.bi suggests two to four weeks for non-critical systems, four to eight for business-critical ones, and eight to sixteen for revenue-critical or compliance-bound systems, with read-only legacy patterns often kept for three to six months afterwards.
• Keep the legacy CRM readable for 30 to 60 days minimum. You need somewhere to look when somebody asks where the data went.

Validation checklist

• Record counts reconcile with source, per object
• Key properties populated correctly, spot-checked across 50 records per object type
• Relationships intact: contacts on the right companies, deals associated properly
• Integrations functioning and writing to the right places
• Automations triggering as expected
• Reports reproduce known historical numbers

That last one is the check people skip and then regret. If a report on the new system cannot reproduce last quarter's closed-won number, something in the mapping is wrong and you want to know now.

Common migration mistakes

Inadequate change management. Teams resist, reps keep their spreadsheets, marketing builds a parallel system and adoption never reaches critical mass. A CRM at 50 percent adoption is arguably worse than no CRM, because you now have unreliable data that people believe. Prevention: visible executive sponsorship, role-specific training, publicly celebrated early wins, and ongoing monthly sessions rather than one launch event.

Ignoring data quality. Dirty data goes in, reports are unreliable from day one, automations fail because triggers do not fire on garbage. Prevention: clean before, not after; validation rules that prevent bad entry; scheduled audits; named ownership per object.

Over-complexity on day one. Everything gets automated immediately, nobody understands the system, and simple tasks become bureaucratic. Prevention: core functionality first, advanced features in later phases, document every automation. If you cannot explain a workflow in two sentences, it is too complex for phase one.

Poor integration planning. The new CRM does not connect to the systems people actually use, so they revert to manual entry. You have built a new silo. Prevention: audit connected tools before migration, test integrations with sample data before go-live, prefer native connectors, and plan for what happens when an integration breaks, because it will.

Skipping post-migration testing. The team declares victory at go-live, historical records did not transfer correctly, and nobody notices until source access is gone. Prevention: keep the legacy CRM readable, spot-check critical records in every department, document what transferred and what did not, and hold a rollback plan.

What people actually search before a CRM migration

Most migration advice is written from the writer's mental model of the project. Here is a different input: what people typed into Google to arrive on this page. Over the 90 days to 4 September 2026, Search Console records 3,899 impressions for this URL. Query text is visible for 59 of those searches, covering 1,038 impressions, and the distribution says something useful about how teams actually approach this.

Two things follow. First, almost two thirds of the demand is for the artifact, not the theory. People want the sequence and the dates, which is why this page now opens with the plan table rather than working up to it. Second, the questions that get asked in full sentences are disproportionately about loss: history, notes, attachments, customer context. That fear is well founded, as the transfer table above shows, and it is under-served by the guides that rank for this topic. Those two observations are what this refresh was built around.

After go-live

Migration is the starting line. Three things decide whether the investment holds.

Adoption. Role-specific training rather than a generic overview, weekly drop-in office hours for the first 90 days, one champion per department, and internal documentation written against your setup rather than the vendor's. Track daily active users, records created and updated per user, and automation usage. The deeper failure modes are in CRM adoption: why reps won't update it.

Measurement. Review at 30 days for urgent issues, at 90 days against the goals you set in phase 0, and at six months for actual return. Score against the targets you wrote down, not against a feeling.

Maintenance. Treat the CRM as a product, not a project: weekly adoption review, monthly workflow optimisation, quarterly field and property audit, annual full system and integration review. Without this, the duplicate rate and completeness scores you fought for in the audit are gone within a year.

Frequently asked questions

What should a CRM migration project plan include?

Six phases: an audit and retrospective, a data model and field mapping document, a sandbox load against a sample, a pilot with power users, a departmental rollout and cutover, and a validation period with the legacy system read-only. Each phase needs a written exit criterion, and the mapping document needs a destination or a documented exception for every source field.

How long does a CRM migration take?

Published estimates disagree. SyncMatters puts mid-market migrations at four to six months; LOW/CODE puts mid-market migrations with custom objects at eight to sixteen weeks; Get CRM Consultant puts them at ten to twenty weeks. A simple move with clean data and few integrations can be done in six to eight weeks. Size yours by integration count and custom object count rather than by database size, and add buffer to the data preparation phase, which consumes 40 to 60 percent of project time according to SyncMatters.

Will I lose my activity history when I migrate CRMs?

Partly, unless you plan for it. Standard imports move records and properties. HubSpot's import supports notes but not other activity types, so calls, meetings, logged emails and tasks need an API-based load that recreates them as activity records with their original timestamps. File attachments follow a separate path entirely and have no native bulk import from Salesforce into HubSpot. Marketing engagement history such as opens, clicks and page views generally cannot be reconstructed at all.

What does a CRM migration cost?

Reported mid-market ranges run from $35,000 to $150,000 (LOW/CODE) and $25,000 to $200,000 or more (Get CRM Consultant), with each integration that must be reconnected adding roughly $2,000 to $8,000. Complexity drives cost more than record volume does. The reliably missed costs are data cleanup, integration rebuilds, training past go-live, and internal project time.

How long should I keep the old CRM running?

Keep it readable for at least 30 to 60 days, and make it read-only at cutover rather than switching it off. Easy.bi suggests parallel periods of two to four weeks for non-critical systems, four to eight weeks for business-critical ones, and eight to sixteen weeks where revenue or compliance depends on the system, with read-only legacy access often retained for three to six months.

What is a normal duplicate rate before a migration?

Landbase reports that organisations without an active data-quality programme commonly sit between 10 and 30 percent, against a target of under 5 percent. Measure yours in the audit phase before committing to a cleanup target, because the number determines how much of your timeline the preparation phase consumes.

How do I migrate from spreadsheets to a CRM?

Treat the cleanup as the project. Decide the object model first, because one spreadsheet row is often a contact, a company and a deal. Find the shadow spreadsheets people actually work from before importing anything. And set the expectation early that pipeline and forecast history will not survive the move, because that data does not exist in a spreadsheet in a form a CRM can consume.

Who is responsible if the migration tool produces a bad load?

There is no industry-standard answer, which is the point. Vendor and partner agreements vary on remediation liability, so put the question in the contract discussion rather than the kickoff: who fixes a bad load, at whose cost, and against what reconciliation standard. Agreeing the rollback criteria before cutover is the practical version of the same protection.

Your CRM should work for you

A migration is a chance to reset the revenue operations foundation, but only if it is approached as one.

Learn from the past. Understand why the previous system failed before choosing the next one, or you are changing the scenery and keeping the problems.

Build the right foundation. The data model determines whether reporting, automation and adoption are easy or a daily fight.

Plan for the loss. Decide early what history you are keeping in full fidelity, what you are archiving, and who signs off. This is the decision that turns into a crisis when it is left implicit.

Treat go-live as the start. The audit numbers you worked for decay without a maintenance process.

If you are facing a migration and want to avoid the failure modes above, Ziel Lab works on CRM architecture, attribution and data pipelines, including clean-slate migrations that move data without losing context. Let us look at your infrastructure and tell you what the real scope is.