Every CRM migration I have led or rescued had a story. A sales leader convinced the team to move to a platform with better forecasting. A marketing department needed cleaner attribution and audience building. A founder wanted to cut subscription bloat. The goals varied, but the headaches were oddly familiar: messy data, conflicting reports, integrations that broke at quarter end, and a go-live date chosen by hope rather than capacity. If you work as a marketing consultant, you get asked to guide these projects because you sit at the intersection of revenue, process, and customer truth. The job is not just moving records from one system to another. It is translating how a business sells and serves into a framework the new CRM can enforce.
This checklist reflects that reality. It is written from the vantage point of someone who has worked the migrations end to end, and sometimes called in after the fact to clean them up. Use it as a scaffolding, not a rigid script. The right answer for a six-person agency will not fit a 600-person manufacturer. But the questions, trade-offs, and pacing apply in both cases.
Start with the reasons, then challenge them
Stakeholders often cite three reasons to migrate: features, price, or pain with the current system. Those are valid, but they are not enough to design a successful move. Push for specifics that you can test later.
If someone wants “better reporting,” ask which decisions suffer today and what metrics they use to make them. If someone wants “marketing automation that just works,” map the actual life cycle: how a webinar registrant becomes a qualified opportunity, what qualifies an MQL in practice, and where handoffs fail. If the CFO wants a cheaper stack, quantify savings against migration cost, retraining time, and the two quarters it often takes to normalize pipeline after a big change.
When I joined one migration, the official reason was “sales hates the UI.” It turned out the real issue was duplicate accounts created by a webform integration that appended a space to the domain. We could have salvaged the old system with a one-day fix. We still migrated later, but with clarity on what mattered and what success looked like.
Define the CRM’s job in your revenue system
A CRM rarely stands alone. It is the anchor for a constellation of tools: marketing automation, data enrichment, billing, support, analytics, and sometimes a customer data platform. Before you evaluate vendors, document the CRM’s job description in this ecosystem.
I use a one-page architecture map: sources of truth, systems of engagement, and systems of analysis. For each system, name the canonical owner of particular fields. If marketing owns persona and lifecycle stage, write that down. If finance owns contract start and end dates, note the source and sync direction. This prevents the most common failure mode I see: two platforms both trying to own the same data, causing silent overwrites and endless reconciliation.
Decide where you resolve identity and deduplicate. If that responsibility shifts during migration, plan for prompts in the go-live window when users will discover that “Acme Corp” exists eight ways. Decide how many objects will be mastered in the CRM versus referenced. If you sell consumption-based products, the usage data might live elsewhere, but the CRM still needs enough to report on renewal risk.
Choose the right migration strategy: big bang, phased, or hybrid
There is no single winning strategy. Each has trade-offs that a marketing consultant should surface early.
A big bang migration, where you move everything and cut over on a single date, compresses change into a short window. It is risky, but it can be cheaper overall and reduces the burden of maintaining two systems. It works if your data is relatively clean, your processes are well https://squareblogs.net/brendarhrp/crm-hygiene-habits-a-marketing-consultants-checklist documented, and your team can absorb an intense two to four weeks.
A phased migration moves segments or functions step by step. For example, you might start with new inbound leads and net-new opportunities, then migrate existing pipeline, then historical accounts. This reduces risk and gives you space to iterate. It demands discipline to avoid living in two worlds for too long. You will need rules for where work happens during the overlap.
A hybrid approach is often the most pragmatic. You cut over key objects at once, but defer rarely used entities or complex automations. You freeze most legacy customization, then bring over only what proves necessary. This preserves momentum while protecting core operations.
Align the data model with the real sales motion
CRMs ship with a default data model: accounts, contacts, deals, activities, and so on. Real businesses almost always need extra structure. The mistake is cloning the old system in the new one, field for field and trigger for trigger. That carries forward old compromises.
Start by mirroring the sales motion you want. If you sell into franchises, you may need a parent-child account structure. If you sell to buying committees, ensure you can track multiple contacts with roles on an opportunity. If you run partner-led deals, the model must accommodate partner attribution and shared revenue. Architect this at the beginning, not after you have imported 200,000 records.
Define the minimum viable field set for each object. I use a tiering scheme: critical (must have to operate), important (used in most reporting or routing), nice to have (only when the team has spare capacity). Then prove these tiers by walking through actual scenarios: an inbound demo request from a multinational, a renewal with an upsell, a churned customer returning after two years. This exercise flushes out missing fields better than a committee meeting ever does.
Set standards for picklists and dates. If “lead source” drives budgets and bonus payouts, lock the values and provide a translation table for historic data. If SDRs use “next contact date” to power sequences, define how automation updates it versus manual edits. Field standards drive adoption as much as training.
Create a data quality plan before you migrate a single record
Data cleanup is the least glamorous part of a migration and the most decisive. If you skip it, your timelines expand, your users lose trust, and your analytics stall for quarters.
Start with a profiling pass. Pull distributions for core fields: how many nulls, how many values outside expected ranges, how many duplicates by email, phone number, or company domain. Spot patterns by region or team. If one region has 80 percent missing industry values, find out why before you import.
Decide what to fix pre-migration versus post. You can standardize country codes, normalize state names, and strip formatting artifacts ahead of time. You might defer enrichment of titles or technographics, but plan the job and timing. Do not bring trash across the bridge.
Set matching and merging rules. For contacts, you can match on email plus name. For accounts, you might need a composite: website domain, normalized company name, and billing postal code. Write down when a record should be merged automatically and when it requires a manual decision. If you lack a data steward, appoint one for the migration window.
Finally, define data governance for day two. The moment users enter data in the new system, entropy starts again. Create lightweight validation rules that match your team’s tolerance. I favor soft warnings initially, then stricter validation after two sprints, once people have adapted.
Inventory automations and decide what to rebuild, retire, or replace
Automations that grew organically in the old CRM often resemble a bramble patch. There are triggers that fire a dozen emails, workflows that update fields in circles, and a handful of scripts no one wants to touch. Migrating them “as is” guarantees old problems will reappear in a shinier interface.
Do a ruthless inventory. Catalog workflows, triggers, scheduled jobs, and code. For each item, annotate the business purpose, owner, frequency, and last modified date. Then mark it with one of three labels: rebuild cleanly, retire, or replace with a different capability.
Rebuild cleanly for core lifecycle transitions and routing. If your team lives on lead scoring and handoff to SDRs, design those flows first. Retire anything tied to a past campaign or a defunct sales process. Replace brittle mechanisms with native features in the new platform when available. I have seen teams delete 40 percent of automation during migration without losing any outcomes, simply by consolidating and adopting built-in objects that did not exist when the old system was configured.
Plan reporting parity and improvements
Executives will judge the migration on reporting as much as daily usability. Set expectations by defining report parity goals. Identify the five reports leadership checks weekly, and replicate them in a staging environment before go-live. That includes filters, cohort definitions, and time buckets.
While you are at it, improve what you always wanted to fix. Clean up pipeline stage definitions, align expected close dates with reality, and introduce cohort views that highlight sales-cycle changes after the new lead routing goes live. If marketing cares about multi-touch attribution, confirm whether the CRM can carry the required touchpoint granularity, or whether you need to pair it with an analytics layer. The worst time to discover that your campaign object cannot store enough context is two weeks after quarter start.
Stakeholders and change management that actually works
A migration touches nearly every role in a revenue team. It is tempting to run it as a technical project owned by ops. That is how you end up with configuration that passes QA but fails on the sales floor.
Identify four stakeholder groups: executive sponsors, sales managers, marketing leaders, and front-line users. Each needs a different level of engagement. Executives set timing and success criteria. Managers provide process truth and are your allies in training. Marketing leaders ensure campaigns keep running and that the database retains its value. Front-line users validate that your design maps to their everyday reality.
Replace generic training with scenario-based sessions. Run a live exercise where an SDR picks up a new inbound lead, qualifies it, and books a meeting, with the trainer showing where fields update and which activities matter. Run another where a CSM renews an account with usage-based pricing. People learn faster when they see their work reflected in the system.
Assign migration champions on each team, ideally people who are respected and curious. Give them early access, a place to log issues, and a direct line to the project team. When a champion says the new follow-up workflow saves them five clicks, adoption spreads.
Integration mapping and the hidden costs of “simple” connections
Integrations cause more surprises than any other component. A connector that worked fine for marketing emails can throttle under a heavier sync when the CRM changes. API limits that were academic in testing become blockers during the first full refresh.
Map each integration with four questions. What triggers the sync: time-based pull, event-based push, or both? What fields move in each direction, and what is the source of truth for conflicts? How will errors be surfaced to ops, and what is the escalation path? What is the expected volume at peak, not just average?
Do a load test before go-live. If your marketing database of 500,000 contacts expects to sync with the CRM nightly, push a full refresh to see the performance curve. A vendor’s “near real-time” claim often means different things at different volumes. Budget time to tune batch sizes and backoff logic.
Be careful with enrichment tools. They can improve data capture, but they also add noise if configured loosely. Decide where enrichment happens in the flow. If it fires before deduplication, you will pay to enrich duplicates, then pay time to merge them.
Security, compliance, and retention specifics
Security and compliance are not just legal departments’ concerns. They shape the configuration and sometimes the vendor choice. Define permission sets early, especially if you have multiple business units or regions with distinct rules. If SDRs should not see customer support cases, encode that. If managers need access to revenue data across teams, verify that role hierarchies cover it.
Confirm how the new system handles data subject requests and consent tracking. If you operate in regions with strict privacy laws, ensure you can honor deletion and suppression in both the CRM and its integrations. Document retention policies for activities and emails. Some platforms trim engagement history after a certain horizon unless configured otherwise.
If your sales team frequently exports CSVs to work offline, tighten that process. Data leakage often begins with convenience. Provide safer substitutes, like saved views with limited fields and expiration on exports.
The migration schedule that respects reality
Every team wants a fast migration. Speed is fine, but the calendar must reflect dependencies that do not compress well. A schedule that works in practice has four phases: discovery and design, build and data prep, testing and training, and cutover with stabilization. The time allocation depends on complexity, but even small teams benefit from a clear arc.
Discovery and design consumes two to four weeks for most mid-market projects. It includes stakeholder interviews, data profiling, architecture mapping, and a written design document. Build and data prep runs another four to eight weeks. This is when you configure objects, set up automations, construct integrations, and clean data in parallel.
Testing and training must be more than a two-day checkbox. Plan at least two sprints of user acceptance testing, with fixes in between. Training begins with champions in the first sprint and scales to the full team just before cutover.
Cutover and stabilization often lasts two to three weeks. During this window, expect daily triage. Build your calendar around go-to-market events. If your biggest product launch hits the same week, slip the migration.
The two checklists that make or break go-live
Because a migration carries many moving parts, the right checklists prevent unforced errors. The first list covers pre-cutover readiness. The second governs the go-live day itself. Use them. Adapt them. Keep them short enough to execute under pressure.
Pre-cutover readiness checklist:
- Data snapshots taken and restore plan documented Final deduplication pass complete, with merge rules validated Integrations smoke-tested with production-like volumes Priority reports recreated and signed off by stakeholders Training complete for champions and scheduled for all users
Go-live day checklist:
- User provisioning verified, permissions tested by each role Legacy automations paused or frozen to avoid double-firing Initial data load completed, spot checks across objects pass Routing and notifications validated with real test records Incident channel staffed with decision-makers and timeboxed triage
These lists do more than contain tasks. They create a shared understanding of what “ready” means. They also give you a way to say no to late-breaking scope that jeopardizes the launch.
Budget, ROI, and the real cost curve
Migrations command time and money across three dimensions: license costs, implementation costs, and productivity dip. The first two are easy to quantify in proposals. The third sinks projects that look fine on paper.
Expect a dip in user productivity for two to four weeks after cutover. New interfaces slow people down. Muscle memory leads to misclicks. Plan for this by easing nonessential targets during the stabilization period and by offering floor support, either literal or virtual, where an admin helps users in real time.
ROI comes from three places when done well: improved conversion and cycle time through cleaner routing and follow-up, better retention and upsell via reliable renewal workflows, and reduced tech spend by consolidating tools the new CRM replaces. Quantify each in plausible ranges and tie them to metrics you already track. When an executive asks six months later if the migration paid off, you need more than a satisfied feeling.
Edge cases that deserve attention
Every migration has gotchas. A few recur enough to warrant preemptive action.
Sales territories with exceptions break naive routing rules. If a named account list overrides geographic assignment, encode the priority. Do not rely on “tribal knowledge” during the first week when tickets and Slack threads fly.
Legacy attachments and email threads balloon storage. Decide early whether to bring them over. If you must, compress and tag with source dates so they remain useful. If you do not, provide a clear archive plan so legal and support teams know where to find historical context.
Custom objects or modules in the old system may map awkwardly to the new one’s data model. Resist forced fits that create confusion for users. Sometimes the answer is to keep a thin reference in the CRM and maintain the heavy object in a separate system with a reliable link.
Multi-brand, multi-language environments multiply picklist complexity. Localize labels but standardize the underlying values. This allows global reporting without endless transformation.
Training that sticks
Change management does not end after a week of recorded sessions. Build reinforcement into the first month.
Schedule office hours twice per week, hosted by an admin and a business lead. Review the top five issues and demonstrate the fixes. Inspect dashboards in a shared session so leaders see exactly how numbers are derived. Share a weekly digest of tips and how many duplicates were prevented or data errors caught, reminding the team that the guardrails have value.
Tie small wins to workflows people care about. An SDR who books one more meeting per week because the “next best action” view actually surfaces the right leads will champion the system more effectively than any top-down message.
Post-migration metrics that tell the truth
You cannot declare success on anecdote. Track leading and lagging indicators for at least two quarters.
Leading indicators: time to first response on inbound leads, lead-to-opportunity conversion rates, average time opportunities spend in early stages, and the percentage of records with complete critical fields. If these degrade materially, dig into routing rules and field validation.
Lagging indicators: win rate, average deal size, cycle length by segment, renewal rate, and campaign ROI. Expect some noise immediately after cutover. The pattern should stabilize within six to eight weeks. If it does not, validate that reporting definitions match the old system’s logic or that the new logic reflects your intended behavior.
Monitor user adoption beyond login counts. Examine create and update events for key objects, assess activity logging rates, and correlate training attendance with utilization. Adoption issues are solvable if you catch them early.
Vendor management without wishful thinking
CRM vendors want you to succeed, but incentives vary between product, support, and sales. Engage them with precise requests. Provide sample records that illustrate edge cases. Push for clear answers on limits and roadmap items that affect your design. If a needed feature is in “early access,” treat it as unavailable until your use case is verified in writing.
If implementation partners are involved, set decision rights. Your internal lead or the marketing consultant should own the call on scope trade-offs, with input from the partner. On standing calls, timebox rabbit holes and capture them as follow-ups. Migrations slip when every topic opens a new thread.
Finally, document everything. The design doc, data mapping, automation inventory, and training materials form your living playbook. They also serve as insurance if team members churn. I have walked into organizations where the person who knew why “Stage 3” meant two different things had left months earlier. The cost of that mystery shows up in your forecasts.
What a marketing consultant adds that no template can
Tools and checklists cannot substitute for judgment. A marketing consultant’s edge comes from seeing patterns across companies and from the willingness to ask uncomfortable questions at the right time. When someone demands a launch date that cannot support proper testing, you provide a firm, evidence-backed alternative. When a team clings to a field that no one uses, you show the downstream cost of keeping it. When leaders want a major process change and a CRM migration in the same month, you help them stage the work so performance does not crater.
You are also the translator between systems and outcomes. You explain to sales why tightening picklists boosts their commissions by making attribution credible. You explain to marketing why deduplication rules matter more than another nurture stream. You explain to leadership that clean data is not a vanity project, it is the bedrock of reliable decisions.
A final pass before you commit
Before you set the cutover date in stone, return to the essentials. Does the new data model reflect how you intend to sell this year, not how you sold two years ago? Are the five core reports in place and validated by the people who live by them? Do your integration tests reflect peak loads, not just the happy path? Have your champions used the system under live fire, with at least a week of parallel work?
If those answers are yes, you are ready. You will still find surprises. A handful of fields will need tweaking, and someone will discover that an email template renders oddly in a certain client. But you will have the structure and the confidence to resolve those issues quickly.
A CRM migration done with care pays dividends that compound. Marketing gets clearer attribution and cleaner segments, sales gets faster routing and fewer dead ends, customer success gets a reliable renewal engine, and leadership gets numbers they can trust. The system becomes a living record of how your company wins and serves. That is the point of moving in the first place, and it is well within reach when you follow a practical, grounded checklist built from lived experience.