Why enterprise businesses are switching from legacy CDPs to Data Cloud

The search question assumes a rush. Old customer data platforms out, Data Cloud in, a market moving as one. This page will not invent the rush. No share of enterprises, no savings, no named customer, no peer who "already switched." If a business case needs a tide to make sense, it is not ready. A switch is justified when CRM, service, and any agent you intend to run must share one profile, and when you can say what the old platform will stop doing on a date.

#The product you would be landing in

The product is Data 360. Salesforce rebranded Data Cloud on 14 October 2025. The behaviour is unchanged. You may still see the old name in the application and in the documentation during the transition. The help page is plain about it: "While the name is new, the functionality and content remains unchanged." The rename does not carry your history across, and it does not turn the new profile into the survivor record your last CDP programme sold.

What the platform will do is the job already written down: ingest streaming and batch data, harmonise it, unify it, and analyse it. Unification here has a specific meaning. Identity resolution is the processing engine that generates unified profiles from source profile data stored in Data 360. Read the next two sentences in the workshop until they stick. Unified profiles are keys that relate your data. They are not a golden record. Identity resolution does not pick a winning value and does not override existing data.

#Identity is a key ring

A legacy CDP programme often sold the opposite of those sentences. One surviving row. One email. One version of the truth. The losers deleted or hidden. Marketers learned to trust that survivor, and the reports they defend in meetings are reports about it.

Data 360 does not work that way. The unified profile points back at the source records. It does not erase a duplicate inside the CDP and hand the CRM a single clean person. If your marketers expect that, the expectation is the first thing to retire, before anyone argues about connectors. Cleaning a survivor record is a CRM job, with a rule a person wrote and signed. The profile in Data 360 will then point at whatever you kept. It will not lead that cleanup, and it will not notice that you meant the other email.

That difference is the point of a switch, not a defect to talk around. The profile has to be good enough to ground CRM and an agent. Keys that point at contradictory emails will do that badly, and they will do it faithfully. Fix the sources, or accept that the profile will relate the contradiction in public. An agent grounded on the contradiction will sound sure. Grounding does not adjudicate. The help page tells you to ground your data for Agentforce. Ground the keys you are willing to defend, not a survivor you have not built.

The failure shows up in the first month, and it looks like a defect. A report of "engaged" no longer matches the number the old platform produced. Someone opens a profile and sees two emails, two consent flags, and a history that does not collapse. They file a ticket titled "unification is broken." Unification did what it was built to do. The ticket is the old definition, still walking around. Answer it by showing the source rows the profile points at. Do not answer it by promising a merge the engine will not perform.

#What you lose, and should not deny

A legacy platform holds campaign history, suppression lists, and segment definitions marketers can explain in a meeting. None of that appears in Data 360 because a contract was signed. History moves only if you map it, and only for the window you choose to ingest. Definitions move only if someone rewrites them against the new model and the new consent attributes. A suppression that lived as a list in the old tool does not become a flag in the new one by sympathy.

Inventory the loss before you promise parity. Which journeys must still be auditable in a year. Which segments are contractual, for a partner or a regulator, and must be reproducible from a written rule. Which scores are folk definitions, the word "engaged" with no formula, that only one analyst can recreate by memory. Folk definitions die in a migration. Write them down or let them die on purpose. Do not discover the death in the first month after cutover, when a steering pack no longer matches and the room treats the mismatch as a platform fault.

Also inventory what you will not migrate. A decade of impression logs is rarely worth the processing. Say so, in the kickoff, with the owner of the old report in the room. A switch that tries to become a museum of the old CDP will miss the date and still disappoint the people who wanted the museum. Archive outside Data 360 what you must retain and will not activate. State the archive's owner and the date after which nobody expects it to match a live segment.

Consent does not survive as an implication. If the old platform treated a purchase as permission to advertise, that implication does not become an attribute because you ingested the purchase. Carry an explicit flag, with a source and a time, or hold the person out. The stricter story, when two systems disagree, is to hold them out until a person resolves it. A migration is when teams are most tempted to default the blanks to yes so the first campaign matches the old volume. That default is an incident you scheduled.

#What "the same person" must mean again

The old platform's match rules do not travel. They were often looser than anyone now wants to admit, because a richer profile looked like success. Loose matching is worse than no matching. Under-matching leaves duplicate profiles, which is visible and reversible. Over-matching merges two people in the only way this platform merges: by pointing one profile at both, quietly. The profile looks healthier. It has more attributes. Nothing on a dashboard distinguishes it from a correct match until one person sees another's order, or a suppression on one silences the other.

Start strict. Build a small labelled set of pairs from real data before you configure the rules: pairs that must relate, and pairs that must not, including shared household inboxes, generic accounts mailboxes, and family members at one address. That set is the regression test when someone asks to loosen a rule because a count dropped. Read a sample of profiles that point at more than one source row. If a shared inbox glued unrelated people together, narrow the rule. Do not add a post-step that overwrites the losers. There is no such step. The detail of how a ruleset fails in silence is the subject of resolving duplicates.

Zero copy is federation, not a latency promise, and it is not a migration strategy. You can connect data using zero copy data federation and leave history in the system that already stores it. That avoids copying a museum into Data 360. It does not replay the old segment definitions, and it does not make a federated decade of logs into a profile. If someone argues for federation because "then we lose nothing," ask them which definition they will rewrite. The bytes can stay. The meaning will not move by itself.

Tableau Next does not replace Tableau. Rebuilding the old CDP dashboards on a new surface is a common way to pretend parity. The help page says you can expand Data 360 using Tableau or Tableau Next. Either tool will draw whatever the profile points at. Neither tool collapses two emails into the survivor your marketers remember. If the old chart was a count of survivor rows, the new chart is a count of keys. Label it as a different count. A polished visual of the new model, titled with the old metric, is how a steering group learns the wrong number with confidence.

#A switch plan that tells the truth

Name the sources that will feed the first unified profile. Two sources that disagree about identity teach you more than the largest source in the estate. Volume is not what resolves the argument. Name the match rules, in language a process owner can read aloud. Name the campaign history you will bring, the window, and the history you will archive outside Data 360. Name the person who signs the new segment definitions. Give the old platform an end date for new sends, and a later end date for read access, so nobody is surprised by a dark report.

Write what you will not call the profile. You will not call it a golden record. You will not say it overrides the CRM. You will not say the campaigns came too. Those three refusals, said in the kickoff, are the difference between a translation project and a dispute. The organisations that cope with the switch are the ones that say the new profile is a set of keys and the old definitions are a rewrite. The ones that struggle are the ones that keep the old slide.

The decisions that are cheap before the first ingest and expensive after it are the same ones any Data 360 programme owes itself: what unified means per use case, how strict the match is, which source wins per attribute, whether each object is copied or referenced, and who owns the ruleset. They are set out in getting Data 360 right the first time. A CDP migration that skips them, because the old platform "already decided," imports the old decisions without the old paperwork.

#The first month after cutover

Run the labelled pairs again. Read twenty profiles with the marketer who will defend the new segment in a meeting. Ask them to point at the source row they trust, and at the row they do not. If they cannot, the ruleset is not ready for a send, even if the count looks familiar. Familiar is the trap. The old count was a survivor count. This count is a key count. They should differ. If they do not, you may have rebuilt the old looseness without noticing.

Keep the old platform readable until the agreed date, and stop new sends on the earlier date you named. A long overlap with both systems sending is how consent gets exercised twice and blamed once. One system sends. The other is a reference. Write which is which.

Then stop adding sources. The second source after cutover is the moment match rules break, because it brings new identifier formats and a new population of shared mailboxes. Treat it as a change to identity resolution, not as a simple addition, and re-run the labelled pairs before it goes live. A switch that cannot survive its second source was a cutover, not an operating model.