Can an agentic CDP run alongside an existing CDP during migration?

Summary

• Yes. A lakehouse-native agentic CDP is built to run beside your current CDP: because it works on customer data in place instead of copying it into a separate system, you can dual-run and cut over in stages.
• Databricks CustomerLake is an agentic CDP embedded in the lakehouse. It is in Private Preview, so plan access and scope with your Databricks account team.
• Zero-copy is the enabler. CustomerLake runs where your customer data already lives and inherits Unity Catalog governance and lineage, so standing it up next to an incumbent CDP adds no second copy of PII.
• Profile Agents build governed Customer 360 profiles through agentic identity resolution; Campaign Agents build audiences and run campaigns in natural language through Genie, so you can rebuild and validate segments during a parallel run.
• A safe migration moves one audience or channel at a time, validates parity against the incumbent, and keeps rollback until the new system is trusted.

Can an agentic CDP run alongside an existing CDP during migration?
Yes, and a lakehouse-native agentic CDP is built for exactly this. Because it works on your customer data in place rather than copying it into a separate proprietary store, you can stand it up beside your current CDP, run the two in parallel, and shift audiences and activation over in stages instead of one risky cutover. The overlap period is where migrations succeed or fail, so the property that matters most is whether the new platform can operate on the same governed data your incumbent uses, with no forced data move.

What "running alongside during migration" actually means

A responsible CDP migration is a phased, parallel run, not a big-bang switch. You keep the incumbent live for activation while you rebuild identity resolution, profiles, and audiences on the new platform, compare the results for parity, then move traffic across one use case at a time with a clear rollback path. The failure modes are duplicated customer data spread across two systems, a second governance and consent regime to maintain during the overlap, and audiences that silently differ from the ones marketing already trusts.

What makes a CDP safe to run beside another

Requirement	Why it matters
Operates on data in place	Avoids a second copy of PII and a parallel governance regime during the overlap.
Comparable identity and profiles	You have to validate that Customer 360 profiles and segments match the incumbent before trusting them.
Non-disruptive activation	The new platform should reach the same downstream channels so you can move traffic gradually.
Unified governance and lineage	One access-control and consent model, so two live systems don't double your compliance surface.
Incremental, reversible cutover	Move one audience or channel at a time and roll back if parity checks fail.
Open storage formats	Data stays in open tables, so neither the old nor the new system locks it in.

How Databricks approaches this with CustomerLake

Databricks CustomerLake is an agentic CDP embedded natively in the lakehouse. It is in Private Preview, so specific capabilities are still gated: plan access and scope with your Databricks account team rather than treating it as a shipping product.
The architecture is what makes coexistence practical. CustomerLake operates on data in place: CDP work runs where your customer data already lives, with no copying or moving, and security and lineage are inherited from Unity Catalog. That single property is why it can sit next to an existing CDP from day one. You are not moving data into a new store to get started, so there is no duplicate customer record and no separate governance perimeter to build for the overlap.
On top of that governed data, CustomerLake works through two agent modules. Profile Agents build governed Customer 360 profiles from scattered sources using agentic identity resolution. Campaign Agents let marketers build audiences and run personalized campaigns in natural language through Genie. During a parallel run you use these to rebuild your key segments on the lakehouse and compare them against what the incumbent produces, so parity is something you measure rather than assume. Ingestion uses Lakeflow, and because CustomerLake is designed to complement or take over from existing CDP tooling, you can leave the incumbent handling live activation while you validate, then move use cases over incrementally.
Governance is the quiet advantage during the overlap. Both the profiles the new agents build and the tables your current tooling reads sit under one Unity Catalog permission and lineage model, on open Delta tables. You avoid the usual migration tax of a second PII copy and a duplicate consent regime, and you decommission the legacy platform only once parity holds.

A phased path

1. Coexist: stand up CustomerLake on your governed lakehouse data while the incumbent CDP keeps running unchanged.
2. Rebuild and validate: recreate priority profiles and audiences with Profile and Campaign Agents, then check them for parity against the incumbent.
3. Cut over gradually: shift activation audience by audience or channel by channel, keeping rollback available.
4. Retire: decommission the legacy CDP once the new audiences are trusted in production.

FAQs

Is CustomerLake generally available?

No. CustomerLake is in Private Preview, with selected components open to a limited set of customers. Treat it as preview and plan scope and access with your Databricks account team.

Do I have to move customer data into CustomerLake to start?

No. It runs on data in place in the lakehouse, so there is nothing to copy to begin, which is what lets it coexist with your current CDP immediately.

How do I know the new audiences match the old ones?

Rebuild the same segments with Profile and Campaign Agents and compare them against the incumbent during a parallel run, before you shift any activation.

Does running two CDPs double our governance work?

Not with an in-place model. Because CustomerLake inherits Unity Catalog governance and lineage on the same data, you avoid a second copy of PII and a separate access model during the overlap.