A worked example for building a liftable Customer Data Control Plane alongside an incumbent CRM, without a forklift migration.
This note accompanies the main Thoraya memo on CRM lock-in. It illustrates the three-phase transition sequence against a realistic enterprise scenario, with enough technical specificity to ground the strategy without prescribing a single implementation path.
The design constraint is explicit: this approach must not replace CRM lock-in with a new “stack lock-in.” Technology choices are examples. The deliverable is portability.
In the agentic era, customer work will increasingly be executed by orchestration: intent interpreted, policies applied, actions taken across systems, and exceptions routed to humans. The limiting factor will not be model capability. It will be governance of execution: knowing what the agent did, why it did it, what data it used, what it changed, and how to reverse it.
A Customer Data Control Plane is what makes that possible. It gives agents a canonical customer truth, stable interfaces, portable identity and policy, and an evidence trail. Without it, agentic automation collapses into brittle point integrations, vendor-native “AI features,” and opaque workflow state you cannot audit or move.
A mid-market or enterprise company (1,500 to 5,000 employees) runs revenue operations on a major enterprise CRM platform. The environment is mature and deeply embedded:
The CRM is not failing. Reports run. Forecasts are produced. Renewals are tracked. But leadership recognizes the symptoms described in the main memo: the system reflects the vendor’s operating model more than the company’s, switching costs distort negotiation leverage, and customer truth is fragmented across vendor boundaries.
The question is how to move from this position to one where the company owns its customer truth and can recompose its operating system without a forklift migration.
Objective: quantify your current lock-in posture and create leverage for every subsequent decision.
A small team (typically a senior architect, a data engineer, and a business analyst) spends four to six weeks mapping the current state across four dimensions:
Data portability. Which customer entities live exclusively in the CRM with no independent copy? In many mature environments, core account and contact records, opportunity history, activity logs, custom object data, and case history are only accessible through the CRM’s API or reporting layer. Document which entities can be extracted in open formats and which are entangled in vendor-specific structures.
Workflow portability. Which business-critical workflows are defined entirely within the CRM’s automation engine? Common examples include lead assignment rules, approval chains, renewal reminders, escalation paths, and territory routing. Catalog each workflow and assess whether its logic can be reconstructed outside the CRM from a written specification, or whether it is implicit and brittle.
Identity and governance portability. Where does identity resolution happen today: deduplication, hierarchy management, merge logic, household or account relationships? If this logic is embedded in CRM configuration, it is a dependency. Similarly document permission models, audit trails, consent, and retention rules, and identify what is portable versus trapped.
Integration dependency. For each integration, map direction of data flow, sync frequency, transformation logic, and failure modes. The critical question: if the CRM were removed from the center, which integrations must be re-architected versus redirected?
Output: a one-page portability scorecard and a detailed dependency map. This becomes the reference for Phase 2 planning and the foundation for the next vendor negotiation. The audit changes the tenor of renewal conversations because it replaces vague dissatisfaction with quantified dependency.
Technology involved: minimal. Spreadsheets, metadata exports, and whatever documentation exists. No new infrastructure is required.
Objective: construct the Customer Data Control Plane in parallel with the incumbent CRM. Nothing is replaced. Nothing is disrupted. You are building a second foundation alongside the first.
The scaffold has four workstreams, corresponding to the container properties in the main memo.
Workstream 1: Canonical customer model. Build a unified customer model in a data platform that represents your canonical view of customer identity and history independent of any application. Common choices today include cloud data warehouses or lakehouse platforms (examples include Snowflake, BigQuery, or Databricks), but the choice matters less than the constraint: your canonical model must be defined and versioned as an asset you control. Use open, portable table formats where practical (for example Iceberg or equivalent) and manage transformations as code (dbt or equivalent).
Critical design choice: the control plane becomes the system of record for customer truth. The CRM becomes a system of engagement: one of several applications that reads from and writes to the canonical model, but is no longer the sole authoritative source.
Workstream 2: Event spine. Establish a CRM-independent event stream that captures customer interactions across touchpoints. This can be implemented via an event streaming platform (Kafka/Confluent or managed equivalents), or via a staged event-log pattern depending on maturity. The point is structural: events are captured once, outside any single application boundary, and then made available to the canonical model and to orchestration. The integration layer must point to the control plane as the destination, not back into the CRM as the hub.
Workstream 3: Portable identity and governance. Externalize identity resolution and governance logic that currently lives inside CRM configuration. Deduplication, merge rules, hierarchy logic, consent and retention policy, access controls, and audit posture must exist as portable artifacts: code, configuration, documented rules, and exportable logs. The target is not perfection. The target is independence: your customer identity and governance posture must be demonstrable without reliance on a vendor UI.
Workstream 4: Continuous replication and lift mechanics. Replicate critical customer entities and events into the control plane continuously and measure drift. But “replication” is not merely sync from CRM to warehouse. It includes exit mechanics: a scripted runbook that can rehydrate the control plane in a second environment, and a quarterly lift test to prove it. This can begin as a separate account and region, and mature toward a second provider for the most critical datasets as posture and economics justify.
Portability constraints (non-negotiables):
Technology involved: a data platform, portable table formats, transformation tooling, integration tooling, monitoring/alerting, and optionally event streaming depending on maturity. Most enterprises use an integrator in this phase. The SOW should specify container scaffolding and lift mechanics as primary deliverables, with a midpoint portability audit and a pre–go-live exit runbook.
Cost frame: this is a bounded investment in structural freedom. It is material, but it is not a multi-year capital program. The return is leverage: credible exit, credible negotiation, and faster recomposition over time.
Objective: use the control plane to change how you evaluate, negotiate, and operate your CRM, and to begin adopting agentic workflows against your own substrate.
Renegotiate from strength. Renewal conversations change when you can demonstrate that customer truth exists independently of the CRM, workflow logic is documented and portable, and your integration layer points to the control plane. Negotiation shifts from “how much will it cost to stay” to “why should we stay, and at what price.”
Externalize workflow logic. Migrate selected workflows out of CRM-native automation into an external orchestration layer (workflow engines, orchestration frameworks, or agentic orchestration patterns). Start with high-dependency workflows identified in Phase 1: lead routing, renewal processing, and escalation paths. The CRM becomes one execution endpoint among several, not the place where logic lives.
The goal is not “agents everywhere.” The goal is an execution layer that is policy-bound and auditable: every agentic action is traceable to a rule, a data snapshot, an authorization context, and a reversible change. That is why the control plane comes first. It turns agentic automation from improvisation into governed operations.
Pilot agentic workflows. With the control plane and externalized workflows, you can pilot agentic capabilities against real customer data on your terms. Early candidates include inbound lead qualification, support-to-expansion handoffs, and forecasting augmentation. The structural advantage is not novelty. It is independence from packaging decisions.
Evaluate the incumbent on operating merit. With switching costs reduced, the CRM becomes evaluable on its true merits: usability, adoption, and narrowly valuable features. Some organizations will stay and pay less. Some will shift to a lighter interface layer. Some will shrink seat counts as exception-driven interfaces replace manual data entry. All outcomes are valid. The point is that you chose.
Agentic readiness signals (what the control plane enables):
Eighteen to twenty-four months after starting, the target posture looks roughly like this:
You own:
You rent:
You can change rented components without a migration project because the control plane absorbs the switch. The data is already yours, the workflow logic is already external, the governance posture is already portable, and leaving has already been rehearsed.
This note describes a representative path. Actual timelines, technology choices, and costs depend on the complexity of your environment, the maturity of data and engineering capability, regulatory constraints, and vendor ecosystem specifics.
The intent is to show that the transition described in the main memo is concrete, sequenced, and achievable, not to provide an implementation specification. Organizations with limited internal engineering capacity should expect to lean more heavily on integrators in Phase 2. In that scenario, the primary deliverables must include portability constraints and lift mechanics, not merely “go-live” functionality.
This companion note is provided for illustration. It does not prescribe specific vendors or a required reference architecture. The consistent requirement is portability: open formats, portable governance artifacts, externalized workflow logic, and tested lift mechanics.
Thoraya can review your sequencing plan before renewal decisions harden: portability audit design, container scaffolding requirements for integrators, and lift-test criteria that make exit credible.