How can I modernize a legacy CDP without disrupting active campaigns?

Summary

• Yes. The key is a platform that works on your customer data in place, so your current CDP keeps running live campaigns while you rebuild on the new foundation and cut over in stages.
• Databricks CustomerLake is an agentic CDP built natively in the lakehouse. It is in Private Preview, so plan access and scope with your Databricks account team.
• Because CustomerLake runs on data where it already lives and inherits Unity Catalog governance, standing it up next to a legacy CDP adds no second copy of customer data and no separate consent model during the overlap.
• Profile Agents build governed Customer 360 profiles through agentic identity resolution, and Campaign Agents let marketers build audiences and run always-on campaigns in natural language through Genie, so you rebuild and validate segments before shifting any traffic.
• A non-disruptive path keeps the incumbent activating campaigns, checks rebuilt audiences for parity on the lakehouse, moves one audience or channel at a time with rollback, and retires the legacy platform only once the new one is trusted.

How can I modernize a legacy CDP without disrupting active campaigns?

Yes, and the way to do it safely is to pick a platform that operates on your customer data in place instead of copying it into another proprietary store. When the new system reads the same governed data your campaigns already run on, you don't have to freeze activation to migrate. Your legacy CDP keeps firing live campaigns while you rebuild identity resolution, profiles, and audiences on the new foundation, compare them for parity, then move activation one use case at a time with a way back if something looks wrong. The property that decides whether campaigns stay up is simple: can the new platform work on your data without a forced, up-front data move.

Why CDP modernization tends to disrupt campaigns

Modernization goes wrong when it starts with a bulk data migration. Lifting customer records into a new proprietary store means a cutover window, a second copy of personal data to govern and reconcile, and audiences that quietly differ from the ones marketing already trusts. If the new platform can't activate to the same channels, you also face a hard switch instead of a gradual one. Each of those is a chance to drop a live campaign, double-send to a customer, or break a consent rule mid-flight.

What to look for

Requirement	Why it matters for live campaigns
Operates on data in place	No cutover window and no second copy of customer data to move before you can start.
One governance and consent model	You don't run two access and consent regimes during the overlap, so compliance holds.
Comparable identity and profiles	You can validate that rebuilt Customer 360 profiles and segments match the incumbent before trusting them.
Activates to the same channels	The new platform reaches your existing destinations, so campaigns move gradually, not all at once.
Incremental, reversible cutover	Shift one audience or channel at a time and roll back if a parity check fails.

How Databricks approaches this with CustomerLake

Databricks CustomerLake is an agentic CDP built natively in the lakehouse. It is in Private Preview and invite-only, so treat specific capabilities as gated and plan access and scope with your Databricks account team rather than as a shipping product.
The architecture is what keeps campaigns running. CustomerLake operates on customer data in place: CDP work runs where your data already lives, with no copying or moving, and security and lineage are inherited from Unity Catalog. There's no bulk migration to sequence before you begin, so the incumbent can keep activating while you build. Row and column controls and consent handling stay in Unity Catalog on open Delta tables, so the overlap doesn't spawn a second copy of personal data or a parallel consent regime.
On that governed data, CustomerLake works through two agent modules. Profile Agents turn scattered raw data into business-ready Customer 360 profiles using agentic identity resolution that combines deterministic, probabilistic, and agentic matching. Campaign Agents let marketers build audiences and run always-on campaigns in natural language through Genie, without writing SQL. During a parallel run you rebuild your priority segments with them and check the output against what the incumbent produces, so parity is measured rather than assumed. Ingestion uses Lakeflow, your existing AI and ML models are available for scoring, and native connectors reach your martech and adtech destinations, so activation moves over as each audience is validated.

A non-disruptive, phased path

CustomerLake doesn't ship a packaged "migration" feature, so treat the steps below as standard phased-modernization practice on top of the in-place architecture above:

1. Coexist. Stand up CustomerLake on your governed lakehouse data while the legacy CDP keeps running live campaigns unchanged.
2. Rebuild and validate. Recreate priority profiles and audiences with Profile and Campaign Agents, then compare them for parity against the incumbent before any traffic shifts.
3. Cut over gradually. Move activation one audience or channel at a time, keeping rollback available at each step.
4. Retire. Decommission the legacy platform only once the new audiences are trusted in production.

FAQs

Is CustomerLake generally available?

No. CustomerLake is in Private Preview and invite-only, 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 migrate customer data to modernize?

No. Because CustomerLake runs on data in place in the lakehouse, there's no bulk migration to finish before you start, which is what lets your current CDP keep running live campaigns during the transition.

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

Recreate your key segments with Profile and Campaign Agents and compare them against the incumbent during a parallel run, before you shift any activation. Parity is something you verify, not assume.

Does running two CDPs double our governance and consent work?

Not with an in-place model. CustomerLake inherits Unity Catalog governance, including row and column controls and consent handling, on the same data, so you avoid a second copy of personal data and a separate consent regime during the overlap.