71/100Ready with planning
Readiness report — Parent BU, sample org
Nothing here blocks the move. Most of the work is deciding what not to bring: only 404 of 1,282 items are reachable from anything running, and 3 things need a decision before you can scope the rest.
Inventory
| Category | Items | Changed 90d | Live | Dead | Complexity |
|---|---|---|---|---|---|
| Emails | 684 | 118 | 231 | 309 | Medium |
| Templates & content blocks | 96 | 9 | 14 | 61 | High |
| Data extensions | 318 | 34 | 96 | 141 | High |
| Journeys | 41 | 6 | 12 | 21 | High |
| Folders | 143 | 2 | 51 | 37 | Low |
Dependencies
An inbound edge is not a dependency. Every object below is classified by whether it is reachable from a live root — a running journey, an active automation schedule, a triggered send that has fired recently — not by how many things point at it.
Live404
Reachable from a running journey, automation or triggered send. Migrate these.
Write-only38
Something is still writing here and nothing reads it — usually a broken integration, or a manual export nobody switched off.
Idle265
Referenced, but only by things that are themselves stopped. Follow the edge up before deciding.
Dead569
Unreachable and untouched. Leave behind. The cheapest win in the migration.
| Category | Dead | Of category |
|---|---|---|
| Emails | 309 | 45% |
| Data extensions | 141 | 44% |
| Templates & content blocks | 61 | 64% |
| Folders | 37 | 26% |
| Journeys | 21 | 51% |
Edges resolved: journey entry sources and activities, automation activities, query targets and sources, email → template, email → content block, triggered send → data extension, folder parentage.
Not resolved: References constructed inside AMPscript or SSJS at send time. Six emails contain LookupRows calls we could not resolve statically. The objects they touch are marked unverified rather than dead.
We publish this because the failure mode that matters is calling something dead when the edge keeping it alive was one we could not see. 6 named unverified objects is a better result than 569 confident ones.
Watch items
222 data extensions with no read or write in ninety days
Needs a decisionTwo-thirds of the data extensions in this business unit show no activity. Rebuilding all 318 on the target side is the expensive default. Somebody has to decide which of these are genuinely dormant, which are annual, and which are simply abandoned — and that decision is worth more than any amount of tooling.
Six of twelve active journeys use a Salesforce Data entry source
Needs a decisionEntry sources are modelled differently in Marketing Cloud Next, which builds on Data 360 rather than a direct Salesforce object subscription. These six need designing against the target model, not lifting across. The other six move with review.
82 of 96 templates have no email referencing them
Needs a decisionContent Builder's template model differs on the target side, so each template carried across is rework. Fourteen are actually in use. Deciding to carry those fourteen and archive the rest is substantially cheaper than porting all 96 — but it is a decision someone has to own.
Also worth knowing 11
Sendable data extensions relying on a Send Log join
Send Log is an optional data extension you opted into years ago, and suppression or frequency logic that joins against it has no target-side equivalent to join to. Export and archive the rows you need for audit, then rebuild the logic against something that exists on the other side.
AMPscript with server-side row lookups
Lookup, LookupRows and LookupOrderedRows resolve their target at send time, so a static scan cannot always tell what an email actually reads. These are the objects we mark unverified rather than dead — check them by hand before archiving anything they touch.
Data extensions with no primary key
Without a primary key a data extension can only be appended to or overwritten, never updated in place, and there is no natural key to reconcile rows against once they have moved. Decide the key before the migration, not during it.
Triggered send definitions pointing at deleted data extensions
The definition survives the deletion of its sendable data extension and then fails quietly on every send. It will fail the same way on the target side. Either delete the definition or recreate what it points at — but do it deliberately rather than discovering it after cutover.
Folder trees deeper than the target side recreates cleanly
Deep Content Builder and data extension trees do not always survive a move, and we cannot give you a documented depth limit for the target platform because Salesforce has not published one. Flattening the deepest branches before you migrate is cheap insurance; measure the depth in your own org and decide.
Journeys paused mid-flight with contacts in wait activities
A paused journey is still holding contacts inside its wait steps. Migrating around them either strands those contacts or silently drops them. Drain the journey, or accept the loss on purpose — but make it a decision rather than a side effect.
Content blocks referencing legacy Portfolio image paths
Portfolio predates Content Builder, and blocks still pointing at Portfolio URLs will render a broken image once those paths stop resolving. Re-point them at Content Builder assets before the move, because finding them afterwards means opening every email.
Emails still using Classic Content
Classic Content emails do not carry into Content Builder cleanly, let alone to the target platform, and Salesforce has been retiring the editor for years. Rebuilding them in Content Builder first turns one hard migration into two easy ones.
Data extensions with field names that collide on the target platform
Field naming rules and reserved words differ on the target side, so a name that has been fine here for nine years can be rejected there. Rename before the move and update everything that reads the field in the same change — AMPscript referencing an old field name fails at send time, not at deploy time.
Journeys with an SMS activity bound to a legacy MobileConnect keyword
MobileConnect keywords are bound to a code provisioned for this account, and that provisioning does not transfer. Treat it as lead time rather than rework: start the conversation with your carrier or with Salesforce early, because the journey cannot go live without it.
Data extensions carrying their own retention policy
A data extension with individual retention set is actively discarding rows, so what you inventory today is smaller than what the business thinks it has. Retention settings do not migrate — record each policy before you move, and re-apply it deliberately on the target.
This is our sample org. Run it on yours.
Every figure above is invented for a fictional business unit. What is real is the format — that is exactly what you get back for your own org.