Salesforce Marketing Cloud migration checklist: what to inventory, rebuild and test

"Migrate to SFMC" and "migrate off SFMC" and "move between business units" are three different projects. Write down which one this is, who owns each decision, and the date that matters most (a contract renewal, a campaign season, a platform sunset). Migrations drift when nobody can say what "done" means.

1. Scope: channels in scope (email only, or SMS, push, CloudPages too).
2. Owner: one person who can approve scope changes.
3. Freeze: a date after which no new automations are built in the old system without being logged.
4. Success test: what must be true for cutover, for example "all transactional triggers firing from the new system, verified by seed list".

Build a spreadsheet with one row per asset. Most migrations underestimate how much is hidden in the account.

• Data Extensions: name, folder, sendable or not, primary key, retention policy, row count, and which automations read or write it.
• Automations (Automation Studio): schedule, every activity (SQL Query, Import File, Data Extract, File Transfer, Script, Send Email), and the data they touch.
• Journeys (Journey Builder): entry source, activities, goals, exit criteria, re-entry setting, and whether they are live.
• Content: email templates, Content Builder content blocks, landing pages and CloudPages, and any AMPscript or SSJS in them.
• Triggered sends: transactional and triggered send definitions, plus the systems that call them via API.
• Integrations: Marketing Cloud Connect, web forms, SFTP drops, API users, webhooks.
• Sender setup: send classifications, delivery profiles, sender profiles, reply mail management, sender authentication.
• Subscriber state: unsubscribes, bounces, holds, suppression and global exclusion lists.

Then mark each row keep, rebuild, or retire. Expect a large share of old automations to be retired. Do not rebuild things nobody can explain.

Data is where migrations stall. For each data extension, decide where that data lives in the target.

• Identify the unique key. Mismatched Subscriber Keys cause duplicate contacts and broken suppression.
• Decide what is master data (lives in CRM or warehouse) and what is marketing-only (can be rebuilt).
• Check field types, lengths, and date formats. Time zones in particular are a common silent error.
• Move consent and unsubscribe history first. Sending to someone who unsubscribed in the old system is the most expensive mistake available.

If the target is Braze, data extensions become attributes, custom events, or Catalogs depending on how the data is used. Our Braze implementation checklist covers that mapping.

AMPscript and SSJS do not translate mechanically. For each template, list what the code does (lookup, format, conditional content, API call), then rewrite it in the target's language and data model. Common traps:

• Nested Lookup and LookupRows calls that depended on a data extension that no longer exists.
• Default values for blank fields, which are easy to lose.
• Date and currency formatting that differs by locale.
• Hard-coded links, tracking parameters and preference-center URLs.

This is the work most teams should hand to a specialist. If you are an agency, this is the kind of work we take on white-label. See agency partners.

Rebuild by function, not by screenshot. A journey that does five things for historical reasons may be better as two cleaner ones. Decide for each whether it is event-driven (Journey Builder) or schedule-driven (Automation Studio). That split is explained in Journey Builder vs Automation Studio.

Document entry criteria, wait times, exit conditions and re-entry rules explicitly. They are the usual source of "why did this person get that email twice" after launch.

Sending reputation does not move with your templates. Plan for:

• SPF, DKIM and DMARC aligned on the sending domain, and a private domain or branded sending setup if you use one.
• A dedicated IP decision. High, steady volume may justify one; low or spiky volume often does not.
• A warm-up schedule that starts with your most engaged subscribers and ramps volume gradually.
• Seed-list and inbox-placement monitoring during ramp-up.

Start this early. It has the longest lead time and cannot be rushed at the end.

• Render every template in the clients your audience uses (Outlook desktop, Gmail, Apple Mail, mobile, dark mode). Our responsive email QA checklist lists the checks.
• Send to a seed list with edge-case records: blank fields, long names, non-English characters, missing images.
• Test every link, unsubscribe, and preference-center path.
• Confirm each triggered send fires from the real upstream system, not only from a manual test.
• Verify suppression: unsubscribed and bounced contacts must not receive anything.

Cut over in waves: lowest-risk programs first, transactional and revenue-critical last. Keep the old system able to send for a defined period. Write the rollback plan before you need it: who decides, what flips back, how queued sends are handled.

After cutover, watch deliverability, unsubscribe and complaint rates daily for the first weeks, and compare performance against the old program's baseline before declaring victory.

1. Define scope, owner, freeze date, success test.
2. Inventory data extensions, automations, journeys, content, integrations, sender setup.
3. Classify each asset: keep, rebuild, retire.
4. Map data and keys; move consent first.
5. Rewrite personalization and rebuild journeys by function.
6. Authenticate domains; plan IP and warm-up.
7. QA across clients, data edge cases and triggers.
8. Cut over in waves with a rollback plan.
9. Monitor and compare against baseline.

Comparing platforms first? Read Braze vs Salesforce Marketing Cloud.