Decommissioning Legacy CRMs: Migration vs Coexistence Strategies

The Cost of Two CRMs Running Simultaneously

The most common pattern in large Salesforce implementations is a parallel running period that never ends. Salesforce gets deployed for new business or a specific team; the legacy system continues operating for the remaining users. Twelve months later, both are still running. The integration between them has become load-bearing infrastructure that nobody wants to touch.

The costs accumulate silently. Licence fees for the legacy system continue. The integration layer requires maintenance. Data quality diverges — the same account has different records in both systems, and neither is definitively authoritative. Reporting requires joining data from both systems, which creates complexity and inaccuracy. New starters learn two systems. Support teams answer queries about both. The organisation pays the full ongoing cost of the legacy system while also paying to run Salesforce.

The total cost of indefinite coexistence is typically 60-80% of the original legacy licence cost, indefinitely. For large organisations on expensive legacy CRM contracts (Siebel, SAP CRM, Oracle CRM On Demand), this can be hundreds of thousands of pounds per year. The business case for decommissioning is almost always positive — the challenge is the migration risk, not the economics.

Three Coexistence Models

Not all coexistence is equal. There are three distinct models, with different costs, risks, and exit paths.

Model 1 — Phased Migration (Temporary Coexistence). Salesforce is progressively taking over capabilities from the legacy system. A cutover roadmap exists. Users are migrated in waves — by business unit, geography, or capability area. The legacy system is on a formal deprecation timeline. This is the healthiest form of coexistence: it has a defined end date and a clear migration path. The risk is timeline slippage — each wave takes longer than planned and the end date recedes.

Model 2 — Functional Separation (Structured Coexistence). Salesforce owns certain capabilities (pipeline management, service case management) and the legacy system owns others (historical contracts, complex pricing). The boundary is explicit and stable. Integration keeps the two systems in sync for shared entities. This is sustainable if the boundary is genuinely clean and neither system is expanding into the other's territory. It breaks down when business requirements force the boundary to move.

Model 3 — Shadow Running (Unstructured Coexistence). Both systems contain overlapping data. Different users prefer different systems. There is no clear ownership boundary. This is the most common and most dangerous form of coexistence. It typically results from a Salesforce deployment that did not achieve sufficient adoption to justify decommissioning the legacy system. The resolution requires either a forced adoption campaign or an honest reassessment of whether Salesforce is fit for the use case.

When to Migrate vs When to Coexist

Full migration and decommission is the right strategy when: the legacy system's licence cost justifies migration investment, the data model is mappable to Salesforce without significant transformation, the legacy system's custom functionality can be replicated or decommissioned, and organisational change capacity is available to absorb the cutover.

Structured coexistence is the right strategy when: the legacy system hosts genuinely distinct capabilities that are not being replaced (historical archive access, regulatory reporting, complex billing), the migration cost exceeds the licence savings over a five-year horizon, or the organisational risk of a full cutover is too high given current business conditions.

The decision framework is a four-quadrant analysis: migration cost vs licence savings (economics), and data migration risk vs operational cutover risk (feasibility). High economics and low risk: migrate. Low economics or high risk: consider structured coexistence with a longer timeline. Low economics and high risk: this is where unstructured coexistence becomes permanent unless a trigger event forces resolution.

Data Migration Risk: The Four Factors

Data migration is the element of legacy CRM decommissioning that most frequently causes programme delays. Understanding the four risk factors allows you to scope them accurately before migration begins.

Data volume. The number of records is less important than the variety of data structures. A million clean account records can be migrated more quickly than 50,000 accounts with complex hierarchies, custom fields, and related objects. Assess data complexity, not just row counts.

Data quality. Legacy CRMs typically contain 5-15 years of data entered by users with varying discipline, validated by rules that changed over time. Deduplication, address standardisation, and field mapping are not one-time activities — they require iterative cleansing cycles. Budget for at least three full data extraction-transform-load cycles before go-live: an initial run to discover issues, a cleansing pass, and a final validated run.

Data transformation complexity. The data model of the legacy system will not map cleanly to Salesforce's object model. Account hierarchies, contact roles, opportunity stage mappings, and product catalogue structures require transformation logic that must be written, tested, and maintained across migration cycles. Underestimating this is the most common cause of data migration timeline overrun.

Regulatory and legal requirements. Financial services, healthcare, and public sector organisations often have legal obligations to retain data in its original form, or to provide audit trails from legacy systems. Understand what data must be archived (vs migrated), for how long, and in what format. Archive requirements affect the decommission timeline — a system may need to remain accessible for audit purposes even after it is decommissioned for operational use.

Cutover Approaches and the Decommission Roadmap

The cutover approach determines how disruptive the migration is to users and business operations. Three approaches are common, each suited to different risk profiles.

Big bang cutover — all users move to Salesforce on a single date; legacy system is turned off the next day. Highest operational risk, simplest integration story. Appropriate only when the user population is small (under 200), the legacy data model is simple, and leadership has the authority to enforce the change. Requires an intensive hypercare period immediately post-cutover.

Wave cutover — users migrate in planned waves over 3-9 months, typically by business unit or geography. Both systems run in parallel with integration maintaining data synchronisation. Lower per-wave risk, but integration complexity is high and the parallel running period incurs cost. The discipline risk: wave N slips, which pushes wave N+1, which makes the decommission date slip permanently.

Capability cutover — legacy system capabilities are turned off progressively as Salesforce equivalents are adopted. Users may access both systems for a period, but each capability has an explicit off date. Appropriate when the legacy system has genuinely distinct capability areas and adoption can be measured per capability. Requires strong governance to enforce off dates.

The decommission roadmap should include: milestone dates for each wave or capability, owner for each milestone, integration off dates (when each integration to the legacy system will be decommissioned), archive completion date, and the formal legacy system retirement date. This roadmap should be presented at programme governance level monthly and treated as a first-class project deliverable.