The Multi-CRM Problem: When You Inherit Two Platforms

Why You Have Two CRMs (And Why That Context Matters)

The technology leader who inherits a two-CRM estate did not choose it. The estate is the accumulated result of organisational decisions — acquisitions, divisional autonomy, failed rationalisation attempts, procurement decisions made without central oversight — that predate the current leadership. Understanding the history of how the organisation ended up with two platforms is not an academic exercise. It is the essential context for understanding what consolidation will actually require.

The most common origin story for a two-CRM estate is acquisition. A company running Salesforce acquires a company running Dynamics 365, or vice versa. The acquisition thesis was built on revenue synergies, market expansion, or technology capability — not on CRM rationalisation. The integration team dealt with ERP consolidation, identity management, and the more immediately visible technology debts. CRM was deferred: both platforms continued running, both were maintained, and the "CRM rationalisation" workstream was added to the future roadmap that never quite becomes the current roadmap.

The second origin story is divisional autonomy. A technology organisation with strong product divisions allows each division to select its own CRM. Sales in one division chose Salesforce because the VP of Sales had used it at a previous employer. Customer service in another division chose Dynamics because the IT team was already managing a Microsoft stack. Both decisions were made in isolation, without a central platform strategy, and both were entirely rational from the divisional perspective at the time.

The third origin story is a failed rationalisation. The organisation attempted to consolidate onto one platform, ran a programme, encountered resistance — usually from the team whose platform was being sunset — and ended in a political compromise that left both systems in production. This is the hardest two-CRM situation to resolve, because the failed rationalisation has consumed programme budget, generated organisational scar tissue, and made stakeholders on both sides defensive about the topic.

The Integration-Not-Consolidation Option

The integration option — connecting both CRM platforms so that data flows between them, maintaining both in production — is often presented as a pragmatic middle path. In a small number of cases, it genuinely is. In most cases, it is the path that minimises short-term political pain while maximising long-term operational cost.

Integration between two CRM platforms is technically achievable. Both Salesforce and Dynamics 365 have robust API surfaces. An integration layer — MuleSoft, Azure Integration Services, Boomi, or a custom middleware solution — can synchronise Account and Contact records, pass Opportunity data between systems, and maintain a consistent customer view across both platforms. Organisations have built and are running these integrations in production today.

The integration option is genuinely appropriate in a small number of scenarios. The clearest case is where the two platforms serve fundamentally different business processes — one manages enterprise account relationships and the other manages consumer customer service — and there is no realistic prospect of consolidating those processes onto a single platform. If the two platforms genuinely serve different populations of users who will never have overlapping needs, the integration overhead may be lower than the consolidation cost.

The second scenario where integration is genuinely appropriate is a short-term bridge while a consolidation programme is planned and funded. Running integration for twelve to eighteen months while the consolidation programme is scoped, approved, and resourced is a legitimate risk management strategy. The critical discipline is that the integration must be time-boxed — it must have a defined end date at which consolidation begins, not a conditional end date that depends on circumstances that may never align.

The Real Cost of Integration-Not-Consolidation

Integration between two CRM platforms does not replace the operational overhead of two platforms — it adds the overhead of maintaining an integration layer to the overhead of maintaining both platforms. You are now running three systems: Salesforce, Dynamics, and the integration layer that connects them. Each system has its own administration overhead, its own upgrade cycle, its own security model, and its own support contract. When a data synchronisation error occurs — and it will — diagnosing it requires expertise in all three systems simultaneously.

More importantly, integration does not solve the problem of conflicting master data. When an Account record is updated in Salesforce and the update does not successfully synchronise to Dynamics, you have two different versions of the same Account in two systems. Every integration model has conflict resolution rules, and every conflict resolution rule produces exceptions that require manual intervention. The exception management overhead in a two-CRM integration — even a well-designed one — is a continuous, ongoing cost that rarely appears in the initial integration business case.

The Full Consolidation Option

Full consolidation — migrating all users and data to a single platform and decommissioning the other — is the correct long-term answer for most organisations with a two-CRM estate. It eliminates duplicate licence costs, reduces the operational overhead of platform administration, removes the integration layer and its associated failure modes, and creates a single authoritative customer record. These benefits are clear and uncontested. The difficulty is not in the logic of consolidation — it is in the execution.

A consolidation programme from a two-CRM estate is more complex than either a greenfield implementation or a single-platform migration. It has two sets of users with different training needs, two data states that must be reconciled into a single target, two sets of integrations with upstream and downstream systems, two sets of business processes that must be mapped and in most cases redesigned, and two sets of organisational stakeholders with strong opinions about the outcome.

The Data Reconciliation Challenge

The hardest technical problem in a two-CRM consolidation is reconciling the master data from both platforms into a single, consistent data model in the target system. The same customer — the same Account — will almost always have different records in both CRM systems. Different names (the legal entity name in one, the trading name in the other). Different address formats. Different relationship structures. Different associated Contacts. The deduplication and master data management work required to produce a clean, consolidated Account and Contact dataset from two CRM sources is a substantial programme in its own right — and it must be completed, or at least substantially completed, before the main migration can proceed.

Organisations that underestimate the data reconciliation phase typically discover the problem during UAT, when users review the migrated data in the new system and find duplicates, missing records, and incorrect relationships. Fixing these problems in UAT is expensive. Fixing them in production after go-live is more expensive and operationally disruptive. The data reconciliation workstream must be fully resourced and treated as a programme-critical dependency, not an afterthought to the technical build.

Deciding Which Platform Survives

The platform survival decision is the most politically sensitive decision in a consolidation programme, and it is the one most likely to be made for the wrong reasons. The wrong reasons include: the CEO used this platform at their previous employer; the larger team uses this platform; the platform with the most recent implementation wins by default; the platform sold to the organisation most recently wins because the contract is newer. None of these are analytical reasons. All of them have determined platform survival decisions in real organisations.

The analytical framework for the platform survival decision should weight four factors. First, total cost of ownership over five years on each platform, incorporating current licence commitments, implementation cost for migration, and ongoing operational cost. Second, functional fit to the organisation's CRM requirements for the next three to five years — not the current requirements, but the expected future requirements, because the surviving platform must serve the organisation's growth ambitions, not just its current state. Third, technology estate fit: which platform integrates more naturally with the other systems in the organisation's technology stack — ERP, data platform, identity management, collaboration tools. Fourth, organisational capability: which platform can the organisation recruit for and operate sustainably, and which has the deeper existing internal expertise.

The Stakeholder Management Dimension

Every consolidation programme has a losing side: the users whose platform is being decommissioned. Managing this stakeholder group is as important as the technical delivery, and it requires a level of attention that programme managers often do not give it until the resistance becomes a programme risk.

The users of the sunset platform have a legitimate grievance: their system is being taken away, their established workflows are being disrupted, and they are being asked to relearn a platform that another part of the organisation chose. Dismissing this grievance — telling them the new platform is better, that they will love it once they learn it — is both disrespectful and ineffective. Acknowledging the disruption, involving the affected users genuinely in the design of the new system, and investing in their training and support are not optional acts of kindness. They are programme-critical risk management steps.

Managing the Transition Risk

The transition period — from the decision to consolidate to the point where the surviving platform is fully operational and the sunset platform is decommissioned — is the period of highest risk for a two-CRM consolidation programme. The risks are not primarily technical. They are operational, organisational, and commercial.

Operational risk during the transition centres on data integrity. While both systems are running in parallel during the transition, every update to a customer record in either system creates a divergence risk between the two data states. The integration that is maintaining consistency between systems is the critical path — every failure of that integration is a data integrity incident. The transition period must have a named data steward with authority to resolve conflicts, a defined incident response process for integration failures, and a monitoring framework that surfaces synchronisation failures in near-real-time rather than in the next day's data quality report.

Organisational risk during the transition is the regression risk: users reverting to the platform they are comfortable with, either because the new system is not yet configured to their satisfaction or because they find the transition difficult. The mitigation is a structured adoption plan that begins before go-live, includes champions in each affected team, and establishes specific workflows that are Salesforce-only from day one — pipeline reporting, forecast submission, deal approvals — so that the path of least resistance for critical workflows is the new platform, not the old one.

Commercial risk is the risk that the organisation is paying for both platforms for longer than planned. Dynamics licences, in particular, are typically held in Enterprise Agreements that cannot be exited mid-term without penalty. The consolidation programme timeline must be coordinated with the Microsoft EA renewal date to avoid paying for licences on a platform that has been decommissioned, or paying break fees that were not in the original business case. This coordination should begin at programme initiation, not at go-live — the EA renewal calendar is determined years in advance and cannot be moved to match a programme's convenience.

The organisations that execute two-CRM consolidations most successfully share a common characteristic: they treat the programme as a business change programme, not a technology migration. The technology is the mechanism. The business change — new processes, new ways of working, new data disciplines, new reporting structures — is the point. Programmes that are led by technology teams without strong business sponsorship consistently underinvest in change management and consistently deliver technically sound systems that businesses do not use effectively.