Know what moves from Marketing Cloud Engagement to Marketing Cloud Next — and what you can leave behind.
re:target reads every object in a Marketing Cloud Engagement business unit and builds a dependency graph of it. Then it walks the graph from what is actually running to show you what is live, what is orphaned, and what nobody has touched in years — so you scope the migration you need, not the org you happen to have.
No sign-up. The simulated run works against our sample org.
Ready with planning: 71/100
- Items inventoried
- 1,282
- Changed in last 90 days
- 169
- Active journeys
- 12 of 41
Four answers you cannot get from the Marketing Cloud UI.
Readiness score
One number, banded, with the reasoning behind it — not a vanity metric.
Complete inventory
Every asset, folder, data extension and journey, by category, with counts.
Dead nodes
We walk the graph from your running journeys and automations outward. Anything nothing reaches, and nothing has touched, does not need migrating. In our sample org that is 44% of it.
What needs a decision
The things that don't lift and shift, each with the reason and what the choice actually is.
A spreadsheet can count. It cannot tell you what is dead.
A reference is not the same as a dependency. A data extension referenced only by a journey that has been stopped since 2021 looks alive to anything counting references — and it is not. re:target walks outward from what is genuinely running, so "unused" means unreachable, not just unmentioned.
You are granting API access to a production marketing org. We treat that seriously.
Every scope we request is read-only and listed before you authorize. If your org cannot send metadata through shared infrastructure at all, private hosting runs re:target on a dedicated instance.
documentAndImages_read, automations_read,list_and_subscribers_read, journeys_read- Never written
- 0 write scopes
- Data retention
- The engagement
- Subscriber data
- Never read
- Hosting
- EU (Frankfurt)
re:target is what you do to an ExactTarget org: you re-target it at Marketing Cloud Next. We built it because the first weeks of any Marketing Cloud Next migration go into manual inventory work that a tool should be doing, and because nobody enjoys explaining to a client that the Send Log they have depended on for nine years is not coming with them.