A Marketing Cloud migration is a re-platforming, not a data export. Subscribers, consent state and content assets move across; journeys, automations and scoring logic are rebuilt, because they do not transfer between platforms. Twopir Consulting plans the migration around that reality — so the audience, the consent record and the sending reputation all survive the cutover.
Marketing automation platforms do not share a journey format, an automation model or a scoring engine. Data and creative assets move; logic is rebuilt. Any migration plan that assumes otherwise runs out of time in the week it discovers this, which is usually the week before go-live.
| Asset | What happens | Why | Where the risk sits |
|---|---|---|---|
| Subscriber records | Migrate, into a designed contact model | The data is portable; the model around it is not. Data extensions and their relationships are designed for the target, not copied from the source. | Duplicate identities surfacing only once both systems are compared side by side |
| Consent and preference state | Migrates — and is the highest-priority workstream | Channel-level opt-ins, global unsubscribes and regional obligations have to arrive intact and be honoured from the first send. | Consent modelled differently in the two platforms, so a mapping error becomes a compliance incident |
| Suppression and bounce lists | Migrate, before any send | Mailing an address the old platform had already suppressed is the fastest way to damage a new sending reputation. | Suppression treated as historical data and scheduled late in the plan |
| Email templates and content | Rebuilt in Content Builder | Template systems are platform-specific. Rebuilding is also the opportunity to consolidate the forty variants most estates have accumulated. | Underestimated volume — the count is always higher than the team believes |
| Journeys, programs and automations | Redesigned in Journey Builder and Automation Studio | No cross-platform journey format exists. The logic is re-expressed in the target platform's model. | Rebuilding logic nobody can still explain, because its author left |
| Lead scoring / engagement models | Rebuilt, and usually revised | Scoring is engine-specific. Einstein models in Marketing Cloud Engagement train on your own engagement history rather than importing a score. | Expecting parity on day one from a model that has no history yet |
| Send and engagement history | Archived, not migrated | Historical opens and clicks belong in a warehouse or reporting layer, not in the operational platform where they inflate storage and contact counts. | Losing the historical baseline entirely because nobody was asked to keep it |
| Integrations | Re-pointed and re-architected | Source and target authenticate differently and expose different objects. See Marketing Cloud integration. | Discovering an undocumented integration when it stops working |
Scroll the table sideways to see every column
Capabilities verified against Salesforce documentation Last reviewed 18 September 2026
The target is the same; the hard part is not. A B2B platform migration is a scoring and CRM-sync problem, a high-volume B2C migration is a deliverability and data-volume problem, and consolidating an existing Marketing Cloud estate is a governance problem. The plan is built around whichever one you have.
Programs, smart campaigns and the Marketo scoring model have no direct equivalent, so the logic is re-expressed in Journey Builder and Automation Studio. Where the destination is Account Engagement rather than Engagement, the CRM sync model changes fundamentally — that decision comes first, not during build.
Typically large, long-established estates: deep custom objects, elaborate campaign canvases and years of accumulated segmentation. The work is as much archaeology as migration — establishing what is still in use before deciding what is worth rebuilding.
High-volume consumer messaging, usually moving because the business is consolidating on Salesforce. The pressure points are event-driven trigger parity, mobile channel continuity and warming new sending infrastructure without a dip in inbox placement.
Merging business units after an acquisition, or rebuilding an org carrying years of configuration debt. Nothing changes platform, but the contact model, business unit structure and permission design are rebuilt from the data model up — with governance to stop the drift recurring.
Data migration is where a Marketing Cloud migration is won or lost. It is not one task but four, and they are sequenced deliberately: consent before subscribers, suppression before any send, and reconciliation before anyone declares the migration finished.
Each one below states what moves, how it is validated, and the failure it is designed to prevent. Volume is rarely the difficulty. Reconciling two systems that model the same customer differently is.
This workstream has its own page in depth — profiling, consent mapping, load order and reconciliation — at Marketing Cloud data migration.
Every channel opt-in, global unsubscribe and regional consent basis is mapped field by field into the target model and validated against the source before a single send is enabled. Where the two platforms model consent differently — one storing a global flag, the other per-channel records — the reconciliation rule is written down and signed off, not improvised during load.
Records land in data extensions built for the target architecture, with relationships defined in Contact Builder — not in a flat import that mirrors the old platform's tables. This is the point at which duplicate identities surface, and dealing with them here is far cheaper than after journeys are running against them.
Hard bounces, complaints and manual suppressions migrate before the first send, because mailing an address the previous platform had already suppressed is the fastest available way to damage a new sending reputation. This list is treated as operational data with a deadline, not as history to load later.
Counts, checksums and sampled record-level comparison against the source, repeated after each load rather than once at the end. The migration is finished when the numbers agree and someone named has signed that they agree — not when the last file has been uploaded.
No. Salesforce's published position is that Marketing Cloud Engagement and Account Engagement customers can access Marketing Cloud Next capabilities with no migration. Next layers new capability alongside the journeys, workflows, content and data that already exist in your org, rather than replacing them.
If a partner is quoting you a migration to Marketing Cloud Next, ask them to point at the Salesforce documentation that says one is required. What is genuinely worth planning is adoption — which capabilities to enable, in what order, and what has to be true in your data first. That is a readiness engagement and it is a fraction of the cost.
Every phase ends in a state you could stay in. That is what makes a migration safe: at no point is the business committed to a platform that has not yet been proven to work with its own data.
Everything in the source platform, catalogd and marked in use or dormant. Most estates discover here that a third of what they planned to migrate has not run in a year.
Contact model, business units, integration pattern and journey framework designed for the target — not reverse-engineered from the platform you are leaving.
Consent, subscribers and suppression loaded in sequence, each validated against the source before the next begins. Reconciliation after every load, not once at the end.
Journeys, automations and templates rebuilt in the target, then run alongside the source on matched audiences until the outputs agree. Discrepancies are found here, cheaply.
Volume moves across in stages on a documented warming schedule, with a defined rollback at each step and deliverability monitored throughout. The old platform stays available until it is provably unnecessary.
None of these are exotic and all four are avoidable in planning. They are listed because they are what we are called in to recover from, and because a partner who has not named them has not planned for them.
If you are mid-migration and recognize one of these, an audit is usually faster than a restart.
The reputation reset — Full volume moves to new sending infrastructure on day one. Inbox placement drops, the team blames the platform, and recovery takes months. A staged warming schedule prevents it entirely.
The consent gap — Preference state is mapped approximately because the two platforms model it differently. Someone receives mail they opted out of, and it becomes a compliance matter rather than a data issue.
The lift-and-shift data model — The old platform's table structure is recreated in data extensions to save time. Every limitation of the system you are leaving is imported along with it, permanently.
The undocumented integration — A feed nobody remembered stops working at cutover, and is discovered when a customer reports incorrect data. The inventory phase exists to find these while they are still cheap.
The practice page: edition selection, architecture, implementation and how an engagement runs end to end.
Re-pointing CRM, ERP and commerce feeds at the new platform — Marketing Cloud Connect, the APIs and Data 360 activation.
Baseline the source org before you migrate, or diagnose a migration that has already gone sideways.
The two quarters after cutover are when the failure modes surface. This is who watches them.
A worked example of the architecture-first approach on a real client engagement.
Marketing Cloud sits inside a wider Salesforce, HubSpot and revenue operations practice.
No. There is no cross-platform journey format — Marketo programs, Eloqua campaign canvases and Braze canvases do not convert into Journey Builder journeys, by any tool. The logic is re-expressed in the target platform's model, which means someone has to document what each journey currently does before it can be rebuilt.
This is usually treated as bad news and is often the opposite. Most estates are carrying journeys nobody has reviewed in years, and a rebuild is the only realistic moment to retire them.
It will if the migration is run badly, and it does not have to be. Sending reputation attaches to the sending infrastructure and domain, so new infrastructure starts without the history mailbox providers use to decide where your mail lands. The controls are a staged warming schedule, correct sender authentication on the new sending domains, migrating suppression and bounce data before the first send, and starting with your most engaged segments rather than your whole list.
The failure mode is always the same: moving full volume on day one because the contract with the old platform ends on Friday. That date is a planning input, not a reason to skip warming.
Historical opens, clicks and sends are archived rather than migrated. They belong in a warehouse or reporting layer, not in the operational platform where they inflate storage and contact counts without being used. What matters is that the archive happens deliberately and before the old platform is switched off — losing the baseline entirely is a common and irreversible mistake.
Suppression, bounce and complaint history is the exception. That is operational data and it migrates before the first send.
No, and you should not. The parallel run phase exists precisely so that lifecycle messaging continues on the source platform while the target is validated against matched audiences. Volume then shifts across in stages rather than in a single switch. The one thing that must be centrally controlled during that window is suppression state, so a customer who unsubscribes in one platform is not mailed from the other.
This is the decision to make before the migration plan is written, because it changes the plan completely. Marketing Cloud Engagement has its own data model, which means the migration includes designing that model and integrating it with CRM. Growth and Advanced Editions are built on the Agentforce 360 Platform with Data 360 as their foundation, so marketing shares the CRM's data model and a whole category of integration work disappears.
Volume, channel mix, data complexity and how many brands you run all bear on it. We would rather spend a week on this question than a quarter recovering from the wrong answer. Start on the consulting page.
Three variables set the duration, and none of them is record volume: how many journeys and automations genuinely need rebuilding, how differently the two platforms model consent, and how many integrations point at the platform you are leaving. A large subscriber file is a straightforward load; forty undocumented journeys are not.
The warming schedule then puts a floor under the cutover window that no amount of resourcing removes — reputation is built over time by definition. We scope against your inventory and give a range with the assumptions stated, rather than an average that fits nobody.
Tell us what you are migrating from, how many journeys are genuinely in use, and when your current contract ends. That is enough for a first conversation about whether the plan is realistic.
Serving: US | Canada | UK | UAE | Australia | New Zealand
