Your CDP became a copy that drifts from the warehouse. Fix it in three steps. Make the data warehouse the single store. Resolve identity deterministically on top of it. Precompute audiences in the warehouse and activate them through reverse ETL, so the view runs the system instead of a copy that has to be synced. You retire the monolith by proving the composable path, not by buying a bigger platform.
Most CDP projects start with a purchase and a migration. This one starts by removing a copy. You already have the data in a warehouse. The work is making that warehouse the operational store and running services on top, not shipping the customer into one more place it can drift. Here is the sequence, with owners and what to measure.
Step 1: make the warehouse the single store
Name the data warehouse as the one place the customer lives. Not a copy destination, not a reporting mirror, the store. Every downstream service reads from it. Nothing gets its own private version of the customer to work from.
Start by mapping what the current CDP actually holds that the warehouse does not. Usually it is less than you think: some computed profiles, a handful of channel identifiers, and a lot of duplicated source data. Move the genuinely unique pieces into the warehouse as models. The rest is redundant the day the warehouse becomes the source.
This is the discipline that turns a pile of sources into a spine. At dunnhumby we ran Tesco Clubcard against roughly 12 million records connected back to one master, and that single spine is what made everything downstream trustworthy. The principle is the same here: one store, or you are back to arguing about which copy is right.
Owner: the data team, with the CDO or head of data accountable for the decision that the warehouse is the master. Measure: the count of customer stores in production. The target is one. Every additional store is drift waiting to happen.
Step 2: resolve identity deterministically on top
With the warehouse as the store, rebuild identity as a service that reads it, not a black box inside a platform. Match records on keys you can trust. Verified email first, then company domain, then precise address for a household. These are facts, so you can defend the matches you make.
Refuse probabilistic stitching as your default. A probability score that guesses two records are the same person will be wrong often enough to poison activation, and a composable setup activates those errors at warehouse scale. Deterministic matching keeps the resolved profile honest. Where you have no trusted key, leave the records unlinked rather than guess. This is the same rule that governs identity resolution everywhere in the stack.
Build the resolution logic as models in the warehouse, versioned and reviewable, so anyone can see why two records were joined. That transparency is what a monolithic CDP took away, and what you are getting back.
Owner: an identity or data-engineering lead who owns the matching logic as code. Measure: match rate on deterministic keys, and the share of your active profiles built without a single probabilistic join. You want that share high and rising.
Step 3: precompute audiences and activate from the warehouse
Now build activation without a copy. Precompute your segments in the warehouse ahead of time rather than scanning millions of rows every time a campaign needs an audience. The audience sits ready, refreshed on the same schedule as the data underneath it.
Then push those audiences out with reverse ETL: sync from the warehouse into the tools that act, like email, ads, and the CRM. The warehouse holds the truth and the precomputed segments. The channels receive current audiences. Nothing lives in a separate store that has to be reconciled back. The view becomes the operational system, not a report you look at after the fact.
When the warehouse updates, the audience is already current, and the next sync carries the truth to every channel. That is the whole point of the composable shape: activation reads the live store, so it stops drifting.
Owner: marketing operations for the audience definitions, data engineering for the reverse ETL pipelines. Measure: time from a data change to that change appearing in an activated audience. In the old CDP it was hours or days of sync lag. Drive it down and hold it there.
How to train your team to hold the fix
Composable architecture fails the same way the monolith did if the team treats every new need as a reason to spin up another store. The fix is a habit, not a migration.
Set one rule above all others: no service gets its own copy of the customer. New need, new model in the warehouse, read by a service. Make that the default answer, and make an exception something you have to argue for, not assume.
Teach the team to read and write the warehouse models, not just consume a dashboard. The value of composable is that identity, segments, and activation logic are visible as code. That only pays back if people can see and change it. Run a short session whenever a new model or pipeline ships, so the knowledge spreads instead of sitting with one engineer.
And defend the warehouse-as-store decision when the next platform sales pitch arrives promising to solve everything in one box. That pitch is how you got the last silo. The leader who holds the line is the difference between a composable setup that stays lean and a slow slide back to another monolith.
Where Morphy helps
We run a four to eight week composable CDP path. We name your warehouse as the single store, map what the current CDP holds that the warehouse does not, and rebuild one activation path end to end: deterministic identity, one precomputed audience, and reverse ETL into a live channel. You get a working proof against your existing CDP, not a slide.
The defined metric is activation latency: the time from a data change to that change reaching an activated audience. We baseline it against your current CDP sync lag and drive it down through the composable path. From there you widen, retiring the monolith one activation at a time rather than in a single risky cutover. No bigger CDP, because the fix is removing the copy, not buying a larger one.
Go deeper on customer data maximization
Three ways forward. Pick the one that fits where you are.
- Get the playbook. Practical notes on turning the customer data you already own into revenue, straight to your inbox. Join the newsletter at the foot of this page.
- Take the assessment. Score your customer data maximization in four minutes and see your top revenue blockers. Start the assessment →
- Book a meeting. Bring your data problem. Leave with a prioritised fix, not a platform pitch. Book a call →
The playbook companion to Why did your CDP become another silo, and what replaces it?. Post 17 of 25 in the Customer Data Maximization series.
Frequently asked questions
How do you move from a monolithic CDP to a composable one?
Make the warehouse the single store first, then rebuild identity, modelling, and activation as services that read it. Retire the CDP's copy last, once activation runs off the warehouse. You are removing the duplicate, not buying a bigger platform to replace it (Netguru, 2025).
What is reverse ETL in a composable CDP?
Reverse ETL pushes data out of the warehouse into the tools that act on it, like email, ads, and the CRM. It is how a composable setup activates. The warehouse holds the truth and precomputed audiences, and reverse ETL syncs those audiences to the channels that use them.
How long does replacing a CDP with composable architecture take?
Scope a first activation path in four to eight weeks: one warehouse as the store, deterministic identity on verified email, and one precomputed audience activated through reverse ETL. Prove it against the old CDP, then widen. You retire the monolith incrementally, not in a single risky switch.