DE → Data Cloud Mapping Blueprint

Map, do not mirror

The instinct when moving from Marketing Cloud to Data Cloud is to recreate the Data Extensions as they exist today. It is the fastest path to a Data Cloud that cannot resolve a single identity.

Data Extensions are tables. Data Cloud is a model. The difference is not cosmetic — it determines whether identity resolution, consent enforcement and cross-channel personalisation work at all once you are there.

One person is many contact points

The central shift is in how a person is represented. A Sendable Data Extension treats one row as one person, keyed on Subscriber Key. Data Cloud separates the Individual from their Contact Points — the email addresses, phone numbers and device IDs through which that individual can be reached.

This is what makes cross-channel work. It is also what breaks if you flatten it back into one row per person during migration, because you have re-encoded the assumption the model exists to remove.

Relationships, not lookups

Relational and Lookup Data Extensions exist because Marketing Cloud had no real relational model — LookupRows() was the workaround. Data Cloud does have one, so those DEs become genuine related objects: a Relational DE holding orders becomes the Sales Order DMO, related to the Individual; a Lookup DE holding loyalty tiers becomes the Loyalty DMO, joined and queried live.

Porting them as flat tables keeps the workaround and discards the capability you migrated for.

Consent must be mapped explicitly

The highest-risk mapping is subscriber status. Unsubscribe and opt-out state in Marketing Cloud has to be deliberately mapped to the Consent DMO. It does not carry across implicitly, and consent that fails to migrate is not a data-quality issue — it is a compliance one.

The blueprint covers all five DE types with a one-page reference table, and states plainly what breaks if you mirror the structure verbatim.