- The organisational dynamics that make coexistence the default choice even when it is the wrong one
- The full cost of coexistence — including the costs that rarely appear in the initial business case
- The specific scenarios in which coexistence is genuinely the right strategic answer
- A structured decision framework for choosing between coexistence and consolidation
- How to execute a CRM sunset effectively, including the decommission sequencing and stakeholder management that determine whether the programme succeeds
Why Coexistence Is More Common Than It Should Be
In most organisations that are running two CRM platforms, coexistence was not a strategic decision. It is the accumulated result of deferred decisions — the rationalisation that was scheduled, delayed, descoped, and eventually normalised as the operating model. Understanding why coexistence becomes entrenched is necessary context for dismantling it.
The most common dynamic is post-acquisition paralysis. A company acquires another, both entities run different CRM systems, and the integration plan is clear: rationalise onto one platform within two years. The two-year mark arrives. The CRM rationalisation workstream was deprioritised in favour of ERP integration, HR system consolidation, and the operational demands of integrating the acquired business. The "we will rationalise CRM next year" statement is renewed annually without ever becoming a funded programme. The organisation that was meant to have one CRM platform now has two fully embedded ones, each with three years of additional development, integration, and user dependency since the acquisition.
The second dynamic is organisational politics. One CRM platform belongs to a powerful division — typically the acquired entity or the division that implemented it first — whose leadership is resistant to consolidation. The political cost of forcing the issue is judged to be higher than the operational cost of maintaining two systems. The coexistence continues not because it is the right answer but because the consolidation requires a level of organisational authority that no one is willing to exercise.
The third dynamic is risk aversion. A CRM consolidation programme is a significant undertaking with real programme risk. The CTO who approves it is accountable for the outcome. If the programme fails — if adoption is poor, if data quality is worse in the new system, if the go-live is six months late — the failure is visible and attributable. Maintaining two imperfect systems is low-visibility failure. Attempting consolidation and struggling is high-visibility failure. The incentive structure favours inaction.
The most valuable thing a CTO or technology leader can do when inheriting a coexistence situation is to be explicit about the real reason consolidation has not happened. If it is political — a powerful divisional stakeholder who refuses consolidation — name that clearly and address it at the executive level. If it is risk aversion — no one wants to own the programme risk — name that clearly and build the risk management framework that makes the programme governable. Coexistence is only a rational choice once you have genuinely examined the alternatives and found them worse. Most coexistence situations have not reached that stage.
The Real Cost of Coexistence
The business case for coexistence — insofar as one is ever made — typically compares the cost of coexistence to the cost of consolidation and concludes that consolidation is more expensive. This comparison is usually correct in Year 1. It is almost always wrong over a three-to-five year horizon, because it captures only the direct costs of coexistence and ignores the indirect and structural costs that accumulate over time.
The Direct Costs
The direct costs of coexistence are two licence contracts where one would suffice, two administration teams (or two sets of administration responsibilities for one team), two upgrade cycles to manage, two vendor relationships to maintain, and two security models to keep aligned. These costs are real and largely uncontested. A mid-sized organisation running Salesforce and Dynamics simultaneously pays £300,000 to £600,000 per year in duplicate licence cost alone, before counting administration overhead.
The Integration Tax
In most coexistence situations, some form of integration connects the two CRM systems to maintain data consistency. That integration has a build cost, a maintenance cost, and a failure cost. The build cost was incurred once. The maintenance cost — keeping the integration current as both platforms release updates, managing schema changes, handling authentication token renewals — is ongoing and typically underestimated in the initial integration budget. The failure cost — the operational disruption when the integration fails, which it will — is real but difficult to quantify in advance and therefore usually absent from the business case.
The Reporting and Insight Cost
An organisation running two CRM systems does not have a unified view of its customers. Sales data in Salesforce and service data in Dynamics produce a fragmented customer record. Analytics and reporting that span both systems require a data warehouse layer or a manual reconciliation process. The absence of a unified customer view degrades the quality of every decision that depends on customer insight: cross-sell strategy, churn analysis, account health scoring, and sales territory planning. This cost is structural and invisible — no budget line captures the quality of insight not obtained — but it is real and it compounds over time.
The Talent and Knowledge Cost
An organisation that runs two CRM platforms must recruit and retain expertise in both. Salesforce administrators and Dynamics administrators are different people with different skills and different salary expectations. The organisation is carrying the talent cost of two platform competencies rather than one. When experienced administrators leave, replacing them with staff who must maintain coexistence across both platforms is harder than replacing a single-platform specialist. The knowledge cost of two platforms also affects change delivery — every new business requirement must be assessed for its impact on both systems, doubling the analysis overhead for process and system changes.
When Coexistence Is Actually the Right Answer
Coexistence is the correct answer in a genuinely small number of scenarios. Claiming it applies more broadly is either analytically lazy or politically motivated. The scenarios where it is genuinely right are worth stating precisely.
The first scenario is permanently separated business units with no cross-sell or shared customer base. If an organisation has acquired a business that operates in a completely different market, has different customers, and has no commercial interaction with the acquiring organisation's customer base, the integration and shared view benefits of a single CRM are minimal. The cost of consolidation — migrating users who will see no benefit, disrupting processes that work, retraining a team that operates independently — is real. The benefit is theoretical. In this specific scenario, coexistence is a rational architectural decision.
The second scenario is an active and bounded transition. An organisation that has decided to consolidate and has a funded programme running needs both systems active during the transition. This is not a coexistence strategy — it is a consolidation programme with a defined decommission date. The critical distinction is that the timeline is fixed and immovable. The transition period ends. The old system is decommissioned. Calling this "coexistence" is a category error that normalises the dual-system state rather than treating it as a temporary programme constraint.
The third scenario is a regulatory or contractual constraint. Some industries and some contracts require data to remain in specific systems for audit trail purposes. A financial services firm with a regulatory commitment to its CRM audit trail may not be able to migrate historical data without regulatory approval. A customer contract may specify that CRM data is held in a particular system. These constraints are real, but they are typically time-limited — regulatory obligations for audit trail data have retention periods, and contracts eventually expire. They justify temporary coexistence with a defined endpoint, not permanent coexistence.
The Consolidation Decision Framework
The consolidation decision framework has three components: the strategic test, the TCO test, and the feasibility test. All three must support consolidation before committing to a programme.
The Strategic Test: Does the organisation have a coherent long-term CRM strategy that a single platform serves better than two? This is a straightforward question with a surprisingly high rate of non-answer. Many organisations that are running two CRM platforms do not have a documented CRM strategy — they have inherited the platforms without ever having decided what CRM is meant to do for the business. The strategic test forces that conversation. If consolidation is the right answer, the strategy will clearly identify a single platform as the vehicle for delivering the CRM vision. If consolidation is uncertain, the strategic test will identify what the organisation needs to resolve before the platform decision can be made.
The TCO Test: Build a five-year TCO model for three scenarios: coexistence maintained, consolidation onto Platform A, and consolidation onto Platform B. The model must include all four cost components — licence, implementation, operations, and staff — for all three scenarios. In most organisations, this model will show that both consolidation scenarios are cheaper than sustained coexistence beyond year two or three. The model will also clarify which consolidation platform is cheaper, which directly informs the platform survival decision.
The Feasibility Test: Is the organisation capable of executing a consolidation programme given its current capacity, leadership attention, and change management maturity? A consolidation programme for a 1,000-user multi-system environment is a large programme — typically 18 to 24 months, requiring significant business engagement, a dedicated programme team, and executive sponsorship at the CTO or COO level. If the organisation is mid-way through another major programme, or if the leadership team does not have the bandwidth to sponsor a programme of this scale, the feasibility test may return a "not now" answer. "Not now" should come with a specific date: "We will initiate the consolidation programme in Q3 next year when the ERP migration is complete."
Every deferral of a consolidation decision must be accompanied by a specific re-evaluation trigger — a date, a programme milestone, a business event — at which the decision is revisited. Deferrals without triggers become permanent deferrals. The organisation that says "we will revisit CRM consolidation when conditions are right" is not making a strategic decision. It is making a political one that normalises coexistence as the operational model. Conditions are never perfectly right for a consolidation programme. The correct discipline is to establish the conditions that are necessary and sufficient, agree when those conditions will be met, and commit to the decision process at that point.
Executing the Sunset
Once the consolidation decision is made and the target platform is identified, the decommission of the legacy CRM is the most critical and most frequently underplanned phase of the programme. Platform sunsets fail in a small number of predictable ways.
The Decommission Sequencing
The legacy platform cannot be decommissioned until all of its functions have been replicated in the target platform and validated by the users who depend on them. This sounds obvious, but programmes routinely attempt to decommission the legacy platform before completing the integration migration, before completing the data migration for all user populations, or before completing user training for all user groups. Each of these errors produces the same result: users who cannot perform their jobs in the new system and demand access to the old one, at which point the decommission is either reversed or the organisation runs both systems at full cost while the gaps are addressed.
The decommission sequencing must work backwards from the target decommission date. On that date, every user must be able to perform every required task in the target platform. The programme plan must identify each user population, each required task, and each dependency — integration, data, training — that must be resolved before that user population can operate on the target platform alone. Any dependency that is not on track becomes a decommission risk, and decommission risks must be escalated to programme governance before they become decommission blockers.
The Data Retention and Archive Decision
At the point of decommission, the legacy platform contains data that cannot all be deleted. Some data must be retained for regulatory compliance — typically a defined number of years for customer interaction data. Some data must be retained for contractual reasons. Some data must be retained because users will periodically need to look up historical records that were not migrated to the target system.
The data retention decision must be made before the decommission date, not at it. Options include: migrating all historical data to the target system (most expensive, cleanest), maintaining the legacy system in read-only archive mode (moderate cost, operationally clean), exporting data to a data warehouse or archive platform (requires archive query tooling), and applying a regulatory retention schedule with automated deletion after the retention period expires. Each option has different cost, complexity, and user experience implications. The decision should be made during the programme design phase and should have business and legal sign-off before implementation begins.
The Political Closure
Platform sunsets are not just technical events. They are organisational ones. The users of the legacy platform — particularly if they were the original advocates for it — need the decommission to be handled with recognition of what they are losing, not just efficiency commentary about what the new system delivers. A decommission that is executed without acknowledging the disruption to affected users, without genuine training investment for the transition, and without a support model for the adoption period will generate the adoption resistance and the escalations to senior leadership that delay the programme and damage confidence in the platform programme overall.
Key Takeaways
- Coexistence is almost always the result of deferred decisions — post-acquisition paralysis, organisational politics, or risk aversion — rather than a considered strategic choice.
- The full cost of coexistence includes duplicate licence cost, integration maintenance, the absence of a unified customer view, and the talent overhead of maintaining expertise in two platforms — a five-year model almost always favours consolidation.
- Coexistence is genuinely appropriate only in three scenarios: permanently separated business units with no shared customer base, a bounded transition with a fixed decommission date, or a regulatory or contractual constraint with a defined end point.
- The consolidation decision requires three tests: the strategic test (does a single platform serve the CRM vision better?), the TCO test (is consolidation cheaper over five years?), and the feasibility test (can the organisation execute the programme given current capacity?).
- Every "not now" deferral of a consolidation decision must have a specific re-evaluation trigger — a date or milestone — or it becomes a permanent deferral that normalises coexistence as the operating model.
- Platform sunset execution requires backwards planning from the decommission date, a formal data retention decision made before decommission, and a stakeholder management approach that acknowledges the disruption to affected users rather than treating the event as purely technical.
Checkpoint: Test Your Understanding
1. A five-year TCO model for a two-CRM coexistence situation shows that coexistence costs £2.8 million more than consolidation over the period. The CTO argues that consolidation should still be deferred because the programme risk is high. What is the correct response to this argument?
2. Which of the following scenarios represents a genuinely appropriate use of long-term CRM coexistence?
3. A consolidation programme plans to decommission the legacy CRM at go-live of the new system. What is the primary risk of this approach?
Discussion & Feedback