- The common patterns that appear in failed Salesforce migrations — the root causes, not the symptoms
- The data architecture mistakes that undermine programmes before they reach go-live
- The change management failures that allow technically sound systems to be rejected by the users they were built for
- The scope and expectation failures that turn achievable programmes into multi-year cost escalations
- The governance and programme characteristics that the successful migrations consistently share
The Pattern of Failed Migrations
CRM migration failure is one of the least studied and most instructive categories of enterprise programme failure. The vendor ecosystem has no commercial interest in publicising it. SI partners move on to the next engagement. Client organisations are reluctant to discuss programmes that cost millions and delivered little. The result is that each new generation of CRM leaders commissions programmes that repeat the same mistakes, because the lessons of the previous generation were never captured and shared.
This tutorial synthesises the patterns that appear consistently across failed Salesforce migration programmes — not from a single study but from the accumulated intelligence of practitioners who have been called in to rescue, remediate, or simply assess programmes that did not deliver. The names of the organisations are not relevant. The patterns are.
The first pattern is that failed migrations do not typically fail on technical grounds. Salesforce is a technically capable platform, and a competent SI can build a technically functional Salesforce implementation. Failed migrations fail on adoption, data quality, scope management, and business engagement. They fail on the human and organisational dimensions — and they fail there because the programme was designed as a technology implementation rather than a business change programme.
The second pattern is that the root causes of failure are almost always visible before the programme starts. Data quality debt is visible in a thorough discovery phase. Change management risk is visible in a stakeholder assessment. Scope volatility is predictable from the organisation's history of technology programme delivery. The problem is not that the root causes are unknowable — it is that they are not examined with enough rigour at programme initiation, because the commercial pressure to start is higher than the analytical pressure to understand.
Programmes that require rescue — where an external team is brought in to assess a struggling migration — almost universally report that the root causes were visible within the first month of the programme. Discovery findings that flagged data quality debt were acknowledged and not acted upon. Stakeholder assessment findings that identified low business engagement were noted and not escalated. Risk registers that contained the root causes of failure were maintained and never used to drive programme decisions. The governance gap between identifying a risk and acting on it is the difference between a managed programme and a rescue programme.
The Data Architecture Mistakes
Data architecture mistakes in Salesforce migration programmes follow a consistent pattern. They are all variants of the same underlying failure: the programme underinvested in understanding the source data state and overestimated the quality and consistency of the data being migrated.
The Clean Slate Fallacy
The most dangerous assumption a migration programme can make is that a new Salesforce org is a clean slate that will automatically produce better data than the legacy system. It will not. The data migrated into the new system carries the quality problems of the source system — duplicates, incomplete records, broken relationships, stale data — unless those problems are resolved before migration. Organisations that migrate without cleaning the source data discover, in the first three months of operation, that the new system is just as hard to trust as the old one. Sales managers who could not rely on pipeline data in the legacy system find that they cannot rely on it in Salesforce either. The promised "single source of truth" is a single source of poor-quality data.
The data quality investment required to avoid this outcome is substantial. It begins with a data quality assessment in the discovery phase that quantifies the debt: number of duplicate Account records, percentage of Contact records without associated Accounts, percentage of Opportunities without close dates or stages, percentage of records with required fields empty. It continues with a data cleansing programme — either automated deduplication tools or manual review processes, or both — that resolves the highest-impact quality issues before the first migration extract. It ends with data stewardship governance in the new system that prevents the re-accumulation of the quality debt that was just cleaned.
The Object Model Assumption
Organisations migrating from a non-standard CRM — or from a heavily customised Salesforce org — frequently assume that the source data model maps cleanly to the standard Salesforce object model. It rarely does. Custom entities in the source system that were created to handle specific business requirements may have no direct equivalent in standard Salesforce objects, requiring either a custom object build or a data transformation that maps the source structure to a different target structure.
The migration design phase must produce a complete field-level mapping document for every entity being migrated — source field, source type, target object, target field, target type, transformation rule, and exception handling. This document is the technical specification for the data migration build. Programmes that begin migration build without a complete mapping document — because the mapping document "takes too long" — consistently encounter migration defects that cost more to fix in build than the mapping document would have cost to produce.
The Hierarchy and Relationship Problem
CRM data is relational — records are valuable not in isolation but through their relationships to other records. Account hierarchies, Contact-to-Account relationships, Opportunity-to-Account relationships, and Activity linkages are the structural relationships that make the data meaningful. Migration failures in this area are particularly damaging because they are not always immediately visible — a Contact record that is linked to the wrong Account will produce incorrect reports and incorrect pipeline attribution months after go-live, when the damage to data trust is difficult to recover from.
The relationship migration must be validated before go-live with a representative sample of records that are manually checked by business users who know the expected relationships. Not by the migration team — by the people who use the data. A migration QA process that is entirely automated, testing technical field mapping without validating business-meaningful relationships, will miss the relationship errors that matter most.
The Change Management Failures
Change management failure is the most common cause of CRM migration programmes that are technically delivered but commercially unsuccessful. A technically sound Salesforce system that users do not adopt is not a successful programme — it is an expensive system that delivers no business value.
The Training That Did Not Change Behaviour
Standard CRM training programmes — classroom or online — consistently fail to change user behaviour in a sustainable way. Users attend training, understand the concepts demonstrated, and then revert to their established habits within two to four weeks of go-live. This is not a failure of the training content — it is a failure of the training design. Training that changes behaviour is not conceptual. It is workflow-specific, role-specific, and repeated at the point of use, not in a classroom before go-live.
The training programmes that produce lasting adoption change are built around the specific daily workflows of each user role — the ten things a territory sales representative does in Salesforce every day, the five things a sales manager does in Salesforce every week — and delivered in a way that allows users to practise in the actual system with their actual data. They are supported by champions who can provide peer support at the point of confusion, and by a feedback loop that captures adoption problems early enough to address them before they become embedded habits.
The Executive Sponsor Who Was Not Sponsoring
Almost every failed migration programme has a named executive sponsor. Almost every failed migration programme had an executive sponsor who was insufficiently involved — who attended kick-off meetings and steering committee meetings but did not actively drive business engagement, did not escalate when business participation fell below the required level, and did not make the programme a visible priority for their direct reports.
Active executive sponsorship means specific, visible behaviours: the CRO who presents at the sales team kick-off and explains why the new system matters for their targets. The VP of Sales who requires their direct reports to use the new pipeline reporting from day one of go-live. The CEO who mentions the CRM programme in the company all-hands. These are not large time commitments. They are high-leverage actions that signal to the organisation that the programme is genuinely important. Their absence signals the opposite.
The Change Network That Was Never Activated
Most migration programmes identify a network of "champions" or "power users" who are trained early and expected to support their colleagues during adoption. Most of these networks are under-resourced, under-supported, and under-utilised. The champions are identified but not given dedicated time for their champion role — they are expected to be champions in addition to their day jobs. They are trained on the system but not given the confidence to handle the range of questions their colleagues will ask. They are identified at programme initiation and not reconnected with the programme until go-live, by which point they have forgotten the specifics they were trained on.
The change networks that work are small, well-resourced, and given a structured support model. They receive additional training in the month before go-live. They have a dedicated escalation path to the programme team for issues they cannot resolve. They have scheduled follow-up sessions in the first four weeks after go-live to process the backlog of questions and issues that accumulate during the adoption period. These disciplines require investment — but they are the investment that determines whether the system is used or shelved.
The Scope and Expectation Failures
Scope failure is the most common cause of programme budget escalation and timeline extension. It takes two forms: scope creep during the programme, and expectation misalignment at programme initiation.
Scope Creep: The Mechanism
Scope creep in CRM migration programmes follows a consistent mechanism. The initial scope is agreed. Business users begin reviewing designs and prototypes. They identify requirements that were not in the original scope — requirements that are, individually, entirely reasonable and that the system should support. The programme team, under pressure to deliver a system that meets user needs, absorbs the additional requirements. The scope expands. The budget does not. The timeline does. By the time the programme reaches UAT, the scope has expanded by 30 to 50% from the initial design, the timeline has extended by three to six months, and the SI is seeking additional commercial recognition for work that was not in the original contract.
The mechanism of scope creep is not misunderstanding or miscommunication. It is the predictable result of starting a build phase without a sufficiently detailed, business-validated design. Requirements that are captured at a high level during the design phase — "the system should support territory management" — generate multiple lower-level requirements when the business sees the actual implementation — "the territory hierarchy needs four levels, not three; named account territories need to overlay geographic territories; territory alignment reports need to be available to regional managers, not just headquarters." These lower-level requirements are not scope creep in any malicious sense. They are the natural output of a design process that was not sufficiently detailed at the right time.
Expectation Misalignment: The Commercial Source
The commercial negotiation that produces a Salesforce migration contract frequently creates expectation misalignment that manifests as programme failure. The SI, competing for the contract, produces an implementation estimate that is optimistic on timeline and scope. The client organisation, comparing estimates from multiple SIs, selects the most optimistic. The contract is signed on terms that require extraordinary execution discipline to deliver. When ordinary programme challenges arise — and they will — the programme falls behind the plan. The client organisation, whose expectations were set by the contract, interprets the delay as programme failure rather than as the natural consequence of an optimistic original estimate.
The organisations that avoid this dynamic are the ones that commission an independent scope and estimate review before the contract is signed — a technical adviser who is not commercially tied to any delivery partner reviews the SI's estimate, challenges the assumptions, and produces an independent assessment of whether the estimate is achievable. This review is not expensive relative to the programme budget. It is the most valuable investment the organisation can make before committing to a multi-year delivery contract.
What the Successful Migrations Have in Common
Successful Salesforce migration programmes are not characterised by absence of challenges — every large programme encounters challenges. They are characterised by the governance and programme disciplines that allow challenges to be identified early and managed before they become programme-defining failures.
Discovery Depth and Honesty
Successful migrations invest heavily in discovery — more heavily than the commercial pressure to start building allows. They produce a data quality assessment that is honest about the debt rather than optimistic about the clean-up effort. They produce a business process inventory that captures the actual processes being run, not the idealised process that the steering committee believes is running. They produce a technical integration inventory that identifies every system touching the legacy CRM, every integration that must be replicated or redesigned, and every API endpoint that has never been documented. This discovery investment pays for itself in reduced change requests, reduced migration defects, and reduced integration failures in build.
Business Ownership of Design
The successful programmes have business owners — named individuals — who are accountable for specific design decisions, who attend design workshops with genuine engagement rather than nominal attendance, and who have the authority to make decisions without escalating every question to a steering committee. The pace of a Salesforce build phase is determined by the speed at which design questions can be resolved. Programmes where every design question requires a steering committee decision move slowly and accumulate the debt of deferred decisions. Programmes where named business owners make decisions at the right level and the right speed maintain velocity.
Governance That Acts on Risks
The successful programmes have steering committees that act on programme risks when they are first identified, not when they have become programme crises. This requires a risk management culture that treats the programme risk register as a live management tool rather than a compliance artefact. When a risk materialises — when data quality findings reveal complexity that was not anticipated, when business engagement falls below the required level, when an integration dependency slips — the steering committee must make a decision: accept the risk and its consequences, mitigate it with additional resource, or adjust the programme scope or timeline. Deferring that decision compounds the problem.
Programmes that report green status until they collapse are the predictable output of a reporting culture that incentivises optimism over accuracy. Programme managers who report amber or red status are held accountable for the problems. Programme managers who report green until the problems are unignorable are not held accountable, because by the time the status turns red the problems have been building for weeks and responsibility is diffuse. The governance discipline that prevents this pattern is a standing instruction to the programme manager: report the status that reflects the actual state of the programme, not the status that minimises escalation. Senior leaders who create a safe environment for honest status reporting — who treat amber reports as good governance rather than as failure — get better programmes.
The Post-Go-Live Investment
The final characteristic of successful migrations is investment in the post-go-live period that most programmes treat as a wind-down phase. The thirty to ninety days after go-live are the highest-risk period for adoption failure — users are encountering the real system for the first time in a live environment, without the safety net of the legacy system, and the gap between the system as built and the system as needed becomes visible. Successful programmes have a dedicated hyper-care team in this period: experienced system administrators who resolve configuration issues within hours, a change management team that is actively monitoring adoption and addressing barriers, and a business sponsor who is visible and accessible to the user community.
Programmes that treat go-live as the finish line — that scale down the delivery team immediately after go-live and return the business to BAU operation — consistently see adoption decline in the first three months. The users who were on the fence about the new system receive the implicit message that the programme has ended and the organisational attention has moved on. Their adoption slides. The data quality declines. The business case metrics are not achieved. The programme is judged a failure by the executives who approved it — not because the system was built badly, but because the investment in making it succeed was withdrawn too soon.
Key Takeaways
- Failed CRM migrations almost universally fail on adoption, data quality, scope management, and business engagement — not on technical grounds — because they are designed as technology implementations rather than business change programmes.
- The root causes of failure are visible before the programme starts: data quality debt is quantifiable in discovery, change management risk is assessable in a stakeholder analysis, and scope volatility is predictable from programme history — the failure is not in the detection but in the response.
- Data architecture mistakes — migrating without cleaning the source data, assuming clean object model mapping, and failing to validate relationship integrity with business users — produce systems that are technically delivered but operationally untrustworthy.
- Change management failures are characterised by training that does not change behaviour, executive sponsors who attend rather than lead, and change networks that are identified but not resourced or activated with sufficient support.
- Scope creep is the predictable result of a design phase that was not sufficiently detailed; expectation misalignment is the predictable result of a commercial negotiation that selected the most optimistic estimate — both are avoidable with independent scope review before contract signature.
- Successful migrations are characterised by honest discovery, named business ownership of design decisions, governance that acts on risk register items rather than filing them, and sustained post-go-live investment in the hyper-care period when adoption is most fragile.
Checkpoint: Test Your Understanding
1. A Salesforce migration programme reports green status until week 14, when it suddenly reports red, with data migration defects and a six-week timeline extension. What governance failure does this pattern most likely indicate?
2. A migration programme completes a technically sound Salesforce implementation and goes live. Three months later, CRM adoption is at 40% and the pipeline data is unreliable. The programme is judged a failure. What is the most likely root cause?
3. An organisation commissions three SI quotes for a Salesforce migration. The quotes range from £800K to £1.6M for the same stated scope. What should the organisation do before selecting a partner?
Discussion & Feedback