Data Extensions to DMOs: Marketing Cloud Next Migration Guide
Marketing Cloud
5 MIN READ
July 8, 2026
Salesforce’s Marketing Cloud Next isn’t just a rebrand but a ground-up rearchitecture of how customer data is stored, related, and activated. The familiar scaffolding of Data Extensions, Subscriber Keys, and Send Logs is giving way to Data Model Objects, Unified Profiles, and Data Cloud-native constructs.
If you’ve spent years building your SFMC instance around Data Extensions, you’re not alone in feeling a mix of anxiety and curiosity. This blog breaks down exactly what’s changing, why Salesforce made these decisions, and how to map your existing data architecture to the new paradigm, step by step.
Why Salesforce Is Retiring the Data Extension Model
Data Extensions served SFMC well for over a decade. Flexible, SQL-friendly, and developer-familiar, they let teams build almost any data structure they needed. But that flexibility came at a cost of siloed tables, fragmented subscriber identity, and no native semantic layer.
- Only 13% of companies have a single, reliable source of customer intelligence across all products and activities.
- Just 23% can act on all or most of the customer data they collect.
Fragmented identity is a documented, industry-wide problem, and it’s exactly what Marketing Cloud Next’s architecture is designed to close.
Marketing Cloud Next, built natively on Salesforce Data Cloud, introduces a shared data fabric across Sales Cloud, Service Cloud, and marketing. The old model of “move data into SFMC for activation” is replaced by “activate data where it already lives.”
The core shift: Data Extensions were ETL destinations. You pulled data in and used it locally. DMOs are semantic representations of your Data Cloud objects, queryable and activatable without duplication.
Start your data inventory
The Legacy-to-Next Architecture Mapping
Here’s how the key objects in your existing SFMC architecture map to Marketing Cloud Next equivalents:
| Legacy SFMC (Data Extensions) | Marketing Cloud Next (DMOs) |
|---|---|
| Data Extension (contact data) | Individual DMO (Data Cloud) |
| Subscriber Key | Unified Individual ID |
| All Subscribers List | Unified Profile (Data Cloud) |
| Journey Builder Entry Source (DE) | Segment Entry (Data Cloud Segment) |
| Tracking / Send Log DE | Engagement DMO (native) |
| Einstein Profile / Predictive DE | Calculated Insights (Data Cloud) |
| SQL Query Activity | Data Cloud Flow / Segment SQL |
| Triggered Send DE | Event-triggered Flow (Data Cloud) |
A Detailed Look at Data Model Objects (DMOs)
DMOs are the native data objects of Salesforce Data Cloud. Unlike Data Extensions, which are essentially database tables you define and manage, DMOs come with semantic meaning baked in. Salesforce provides a standard DMO library (Individual, Contact Point Email, Engagement Event, etc.) and allows custom DMOs for brand-specific data.
What Makes DMOs Fundamentally Different
| Dimension | Data Extensions (Legacy) | DMOs / Marketing Cloud Next |
|---|---|---|
| Structure | Freeform SQL table; you define every field | Semantic objects with standard and custom fields; relationships defined in the data model |
| Identity | Subscriber Key per Business Unit; manual deduplication | Unified Individual ID resolved by Data Cloud identity resolution rules |
| Data Location | Stored inside SFMC; data must be imported or synced | Referenced in Data Cloud; no duplication, activates where data lives |
| Segmentation | SQL queries, filter criteria, Audience Builder | Data Cloud Segment canvas with drag-and-drop on DMO attributes and Calculated Insights |
| Cross-Cloud Access | Requires explicit sync via Marketing Cloud Connect or API | Natively shares data with Sales, Service, Commerce, and Analytics Clouds |
| Consent & Compliance | Manual via Profile Center preferences Data Extension | Consent DMO with automatic suppression at the activation layer |
Understanding Unified Profiles vs. the All Subscribers List
The All Subscribers list was the bedrock of SFMC. Every contact who ever received an email lived there, tied to their Subscriber Key. Marketing Cloud Next replaces this with the Unified Profile, a resolved identity record in Data Cloud that merges fragmented contact points (email, mobile, loyalty ID, CRM ID) into a single person view. This unified view is the same principle behind Salesforce Customer 360, extended natively into Data Cloud.
This is significant for teams that have historically battled the “ghost subscriber” problem: contacts that exist in a dozen different Data Extensions with slight variations of their email address. Identity resolution in Data Cloud handles that deduplication automatically, using match rules you configure once.
Key implication: Your send volume calculations will change. When you suppress or unsubscribe a Unified Profile, all associated contact points are suppressed, not just the email address used for that specific send. This is more accurate, but it means your “active subscriber” count will likely shrink on first migration.
Talk to migration experts
Journey Builder in Marketing Cloud Next
Journey Builder as a concept survives the transition, but its entry sources change fundamentally. Where you previously configured a Data Extension as the entry source and used Automation Studio to populate it, MC Next Journeys are driven by Data Cloud Segments or real-time event streams from the Engagement DMO. See a Marketing Cloud integration case study for how a similar multi-channel journey setup was rebuilt from the ground up.
What This Means for Multi-Step Programs
Existing journeys that rely on SQL-populated Data Extensions for entry will need to be rearchitected. The SQL query logic moves into either a Data Cloud Flow or a Segment definition. The good news: Data Cloud Segments are significantly more powerful. They can reference Calculated Insights (predictive scores, CLV buckets, churn probability) as first-class attributes without the need to pre-stage them in a DE.
- Audit all active journeys and document their DE entry sources
- Identify which entry DEs are populated by Automation Studio SQL vs. external API vs. data sync
- Map SQL logic to Data Cloud Segment or Flow equivalent
- Test Calculated Insights as segment attributes before decommissioning Einstein predictive DEs
- Update decision splits that reference DE attribute lookups to use DMO attributes instead
The Migration Roadmap: A Phased Approach
A Phased Approach”: If you’re coordinating this alongside a broader CRM transition, our Salesforce Migration Services team can help scope both efforts together.
1. Data Inventory and Dependency Mapping
Document every Data Extension, its source (manual, sync, API, SQL query), its consumers (journeys, sends, queries, reports), and its refresh cadence. This is the unglamorous work that determines migration complexity. If your DEs are populated by external pipelines, our roundup of Salesforce ETL tools can help you plan their replacements.
2. Data Cloud Provisioning and DMO Schema Design
Provision Data Cloud on your org and design your custom DMO schema to mirror your business-specific contact attributes. Salesforce’s standard Individual and Contact Point DMOs handle most common fields; your custom DEs map to custom DMOs or Calculated Insights.
3. Identity Resolution Configuration
Configure match rules and reconciliation rules to build Unified Profiles from your existing contact data. Run initial resolution and audit the results, especially for global brands with multi-regional contact fragmentation. Ksolves recently guided a client through a recent Data Cloud identity resolution project, mapping Service Cloud objects into unified DMOs.
4. Segment and Calculated Insight
Recreate your core audiences as Data Cloud Segments. Migrate Einstein Engagement Scoring DEs to native Calculated Insights. Validate segment membership counts against legacy DE-based equivalents before going live.
5. Journey Migration and Parallel Running
Rebuild high-priority journeys with DMO-backed entry sources. Run them in parallel with existing DE-backed journeys during a validation window, comparing send volumes, open rates, and suppression behavior before cutover.
6. Decommission and Governance
Retire legacy Data Extensions in a controlled sequence, non-critical first. Document the new DMO governance model: field naming standards, custom DMO request process, and Calculated Insight refresh schedules.
Common Migration Pitfalls to Avoid
Assuming a 1:1 DE-to-DMO lift-and-shift: Many Data Extensions are operational artifacts: mid-journey staging tables, temp query outputs, suppression lists. These don’t all need a DMO equivalent. Some become Flows, some become Calculated Insights, and some simply disappear when the process is redesigned natively.
Underestimating consent migration complexity: If your preference center is custom-built on SFMC pages writing back to a preferences DE, this is a significant rearchitecture. The Consent DMO has a specific structure and interacts with the activation layer in ways your custom DE does not. Start consent migration early.
Skipping the identity resolution audit: Running identity resolution on dirty contact data produces dirty Unified Profiles. Clean your email and phone data before ingesting into Data Cloud, or your match rates will be poor, and your Unified Individual counts misleading.
The Opportunity Inside the Migration
Migrations are disruptive, but Marketing Cloud Next’s architecture removes real pain that SFMC teams have lived with for years. No more replicating CRM contact fields into DEs via overnight syncs. No more separate suppression lists per Business Unit. No more rebuilding Einstein scores as DE attributes just to use them in Journey splits.
The teams that approach this migration as a data architecture redesign, rather than a technical translation exercise, will emerge with a leaner, more reliable, and genuinely cross-cloud marketing data layer.
How Ksolves Can Help You Make the Move
Migrating from Data Extensions to DMOs isn’t just a Marketing Cloud project. It touches identity resolution, consent architecture, journey logic, and governance across your entire Salesforce ecosystem, which is exactly why most teams don’t want to navigate it alone. As a Salesforce Summit Partner and an AI-first engineering team, Ksolves brings both the platform depth and the applied AI expertise to plan, execute, and validate this migration without disrupting your live campaigns.
Our Salesforce Consulting Services cover the full lifecycle: data inventory and dependency mapping, DMO schema design, identity resolution tuning, parallel-run journey validation, and post-migration governance. If your MC Next timeline is already on the calendar, or even if it’s still 12 to 18 months out, our team can help you start the inventory work now so you’re not solving architecture problems mid-migration. Talk to our Salesforce Consultants to scope your migration path.
Conclusion
Marketing Cloud Next represents the biggest architectural shift in SFMC’s history, but it’s one built to solve problems every marketing team already knows too well: siloed data, fragmented identities, and duplicated effort across clouds. Start with a full data inventory, treat identity resolution as a data quality exercise and not just a technical one, and rebuild journeys in parallel before you decommission anything.
Ksolves recommends beginning the data inventory phase immediately, even if your MC Next migration timeline is 12 to 18 months away. The inventory work alone surfaces technical debt you’ll want to address before migrating, not during it.
Connect with our experts to learn more about the migration or send us your query at sales@ksolves.com.
Frequently Asked Questions
What’s the difference between a Data Extension and a DMO in Marketing Cloud Next?
A Data Extension is a freeform SQL table you define and manage yourself inside SFMC, while a Data Model Object (DMO) is a semantic, standardized object native to Salesforce Data Cloud. DMOs come with built-in relationships and identity resolution, so migrating Data Extensions to DMOs means moving from siloed tables to a shared, queryable data layer. This removes the need to duplicate data just to activate it in campaigns.
What happens to my Journey Builder journeys when I migrate to Marketing Cloud Next?
Existing journeys built on Data Extension entry sources need to be rearchitected around Data Cloud Segments or real-time event streams instead. The SQL logic that populated your entry DE moves into a Data Cloud Flow or Segment definition. Most teams run the rebuilt journey in parallel with the legacy version before cutting over.
Will my active subscriber count change after migrating to Marketing Cloud Next?
Yes, it can shrink on first migration. Because Unified Profiles consolidate every contact point tied to one person, suppressing or unsubscribing a Unified Profile suppresses all associated contact points at once, not just the address used for a single send. This is more accurate than the old All Subscribers model, but it means your reported numbers will likely drop.
When should a company start preparing for Marketing Cloud Next migration?
Start data inventory and dependency mapping well before your formal cutover date, even if migration is 12 to 18 months out. Ksolves generally advises starting the inventory phase immediately, since it surfaces technical debt in your Data Extensions that’s easier to fix before migration than during it.
How is identity resolution different between Subscriber Keys and Unified Profiles?
A Subscriber Key identifies a contact within a single Business Unit and requires manual deduplication across Data Extensions. A Unified Profile is resolved automatically by Data Cloud’s identity resolution rules, merging fragmented contact points like email, mobile, and CRM ID into one person-level record. This removes the need to reconcile “ghost subscribers” scattered across multiple DEs.
Who can help migrate Data Extensions to DMOs for Marketing Cloud Next?
Ksolves, a Salesforce Summit Partner, provides end-to-end support for this migration, covering data inventory, DMO schema design, identity resolution tuning, and parallel-run journey validation. Because the migration touches identity, consent, and governance across the whole Salesforce ecosystem, most teams bring in a partner rather than navigating it alone.
What’s the biggest risk when migrating Data Extensions to DMOs?
The most common mistake is assuming every Data Extension needs a 1:1 DMO equivalent. Many DEs are operational artifacts, like staging tables or suppression lists, that become Flows, Calculated Insights, or disappear entirely once the process is redesigned natively. Treating the migration as a straight lift-and-shift instead of a data architecture redesign is what causes rework later.
Still have questions about your Marketing Cloud Next migration? Contact our team.
Author
About the Author Editorial Team The Ksolves Editorial Team includes certified Salesforce experts, Big Data engineers, AI/ML specialists, Zoho consultants, and experienced technology writers focused on delivering clear, actionable insights for modern businesses. With hands-on experience across Salesforce, Big Data platforms, AI/ML solutions, application development, software testing, and Zoho ERP/CRM, the team publishes practical guides, real-world use cases, and industry updates that support smarter decisions and faster growth. Every article is created to solve business challenges, guide technology adoption, and keep organizations aligned with evolving digital ecosystems.
Share with