Leaving Marketing Cloud: A Migration Checklist for Brands Moving Off Salesforce

Brands rarely leave a major marketing platform because of one bad feature. More often, the pressure builds: rising costs, limited flexibility, brittle automations, and a growing sense that the marketing data governance model is too constrained for how the team actually works. The recent conversation about brands “getting unstuck” from Salesforce reflects a broader martech shift: teams want systems that are easier to integrate, easier to explain, and easier to change without rewriting every customer journey from scratch. If you are planning a Marketing Cloud migration, the real challenge is not exporting contacts. It is preserving the logic, timing, personalization, and deliverability that keep revenue flowing while you rebuild the stack.

This guide is a practical migration playbook inspired by the kind of operator thinking Stitch surfaced in its executive conversations: map the data before you move it, re-architect journeys instead of cloning them blindly, test aggressively, and protect the inbox at every step. If you are trying to avoid vendor lock-in while modernizing your martech stack, this checklist will help you sequence the work in a way that minimizes disruption. For teams also evaluating AI and automation dependencies, it pairs well with our guide on choosing an agent stack and our broader framework for data governance in marketing.

1) Start with the migration objective, not the platform swap

Define the business outcome before you touch data

A common migration mistake is treating Salesforce as a container problem. In reality, Marketing Cloud is often the center of identity, orchestration, measurement, and segmentation, so the move touches multiple teams. Before you write a technical plan, define the business reason for leaving: lower total cost, better journey orchestration, improved speed to launch, cleaner data workflows, stronger personalization, or simply reducing platform dependency. That clarity determines what you preserve, what you replace, and what you intentionally retire.

This is where a disciplined martech checklist matters. The checklist should capture owners, dependencies, risks, and the “must not break” revenue flows. If the business case is mainly operational, your success metrics should focus on marketer productivity, journey build time, and error rates. If the case is customer experience, then open rates, click-through rates, and deliverability will matter more than release velocity. For brands thinking in systems terms, our guide on winning operating rhythms is a helpful reminder that process design often beats raw effort.

Identify the journeys that are revenue-critical

Not every automation deserves the same migration treatment. Start by ranking journeys by revenue impact and risk: welcome series, cart abandonment, post-purchase education, renewal, reactivation, and transactional messaging should be at the top. Then flag anything with complex branching logic, time delays, conditional suppression, or multi-channel triggers. These journeys are where a naive lift-and-shift can break the customer experience in subtle ways that are hard to detect until performance drops.

A useful tactic is to build a “journey criticality matrix.” Score each flow by revenue dependency, contact volume, personalization depth, and operational complexity. The higher the score, the more likely you will need a redesign rather than a copy. That mindset aligns with the discipline behind game mechanics and state management: the visible interface matters, but the underlying state transitions determine whether the experience works. The same is true in email automation.

Set guardrails for scope, timing, and rollback

Before migration work begins, decide what will not move in phase one. That may include legacy segments, seasonal campaigns, or lower-value journeys that can remain in the old system until the core stack stabilizes. Establish a rollback plan for any cutover event, including how you will pause sends, reverse DNS changes, restore templates, and re-enable downstream integrations. If there is no rollback plan, the project is not ready for production.

For teams juggling multiple digital initiatives, this is also where a strong dependency map prevents chaos. The same logic appears in our article on long-term platform costs: switching systems is never just a software choice, it is a workflow choice. When you treat the cutover as a controlled operational change, not a one-time event, the odds of preserving performance go up dramatically.

2) Map your data before you migrate anything

Inventory every source of truth

Data mapping is the foundation of a successful Marketing Cloud migration. Create a complete inventory of every source feeding the current environment: CRM, order system, product database, CMS, CDP, website events, mobile events, customer support, loyalty, ad platforms, and offline sources. Then document which fields are authoritative, which are derived, and which are merely convenience copies used by marketers for targeting. Too many migrations fail because teams discover too late that the “same” field has different meanings in different systems.

Build a field-level dictionary with source, datatype, transformation, owner, refresh cadence, and destination. For example, “last purchase date” might come from commerce, but “lifetime value” might be computed in a warehouse, and “preferred category” might be inferred from behavioral signals. This is where the exporting model outputs into activation systems playbook is highly relevant: data only becomes useful when the scoring or attribute logic is portable and well-documented.

Normalize identities and deduplication rules

Identity is one of the most fragile parts of a migration. If Marketing Cloud currently uses a fragmented subscriber model, you need to decide what becomes the canonical person record in the new stack. Define the matching rules for email address, customer ID, phone number, device identifiers, and household relationships. Then decide how deduplication will behave when records conflict or arrive out of order. If these rules are vague, personalization quality will degrade immediately after cutover.

Strong identity design also means understanding lifecycle states. A record can be simultaneously a prospect in one system, a customer in another, and a suppressed contact for legal reasons in a third. Your migration plan should preserve those nuances rather than flattening them into one list. For a broader perspective on data trust and portable identity, see our guide to personal intelligence and credentialing, which highlights why consistency matters when multiple systems interpret the same entity.

Document compliance, consent, and suppression logic

Consent is not a footnote in a migration; it is a hard constraint. Map opt-in status, channel consent, regional privacy rules, suppression reasons, and legal holds before any transfer. Make sure consent state carries over exactly, not approximately. If a subscriber opted out of promotional email, your new platform must respect that status from the first send onward.

Build a suppression hierarchy that covers global unsubscribes, soft bounces, hard bounces, litigation holds, employee addresses, and VIP exceptions. Keep a clear audit trail for every suppression category. If your team is expanding into more regions, our article on policy-sensitive operations offers a useful analogy: when rules tighten, systems need explicit controls, not assumptions.

3) Re-architect journeys instead of cloning them

Use the migration as a chance to simplify broken logic

The fastest way to inherit old problems is to copy old automations line by line. Marketing Cloud journeys often accumulate exceptions over time: wait times added for edge cases, extra branches for ad hoc campaigns, and hidden suppressions that no one fully remembers. During migration, challenge each journey with one question: what is the simplest version that still produces the desired customer outcome?

That does not mean stripping out sophistication. It means separating core logic from historical clutter. A welcome journey might keep personalization by source, product interest, and geography, but drop obsolete split paths that no longer affect performance. The same strategic discipline appears in cultural-context campaign design: the best campaigns are not the most complicated ones, but the ones that align the message with the audience’s state and timing.

Translate triggers, delays, and branches into platform-agnostic rules

Before you rebuild anything, write each journey as a rules document. List the trigger, entry criteria, exclusions, wait logic, decision points, exit criteria, and success metrics. This makes it easier to replicate the intent in a new platform without getting trapped by the old UI’s structure. It also helps QA teams verify that the rebuilt journey behaves the same under different inputs.

Think of this as converting visual automations into executable logic. If you have ever had to move from one analytics or activation system to another, the lesson is the same: the interface changes, but the logic needs a portable specification. Our article on tracking social influence shows how measurement frameworks become more useful when they are explicit and portable, not buried inside one dashboard.

Plan for personalization parity, not just functional parity

Many migrations preserve send behavior but lose personalization depth. That is a hidden revenue leak. If the old system uses dynamic content blocks, predictive product recommendations, or complex profile attributes, make a parity map for every personalization element. Note what data powers it, where that data will live after migration, and whether the new platform can generate the same output natively or through an API.

In practice, personalization parity requires a close partnership between marketing ops, data engineering, and lifecycle marketers. Teams should stage examples for each major segment and compare the old output versus the new output before go-live. This mirrors the approach in our guide to influence and measurement loops: if you do not observe the output directly, you cannot know whether the system is actually doing what you intended.

4) Protect deliverability like a production dependency

Audit your sender reputation before the move

Email deliverability is often the biggest hidden risk in a martech stack migration. If you are moving domains, IPs, subdomains, or sending infrastructure, treat deliverability as a release-critical dependency. Start with a pre-migration audit of bounce rates, complaint rates, spam placement, domain alignment, authentication status, and engagement trends by segment. If some lists are already weak, do not use migration as a reason to send them more volume immediately.

Document your SPF, DKIM, and DMARC posture, as well as any IP warm-up requirements for the destination environment. Segment your sends carefully during the first weeks after cutover, and prioritize highly engaged audiences first. The operational principle is simple: reputation is earned by consistency, not by volume. For teams that need a broader lens on infrastructure readiness, our article on safe automation design offers a useful reminder that critical systems need containment, monitoring, and staged rollout.

Warm up carefully and monitor at the inbox level

Warm-up is not just about sender volume. It is about maintaining a positive engagement profile across mailbox providers while new infrastructure proves itself. Create a staged plan that starts with transactional and highly engaged campaigns, then expands to broader lifecycle sends only after metrics stabilize. Avoid the temptation to blast a full promotional calendar on day one just because the platform is live.

Your monitoring should go beyond opens and clicks. Track inbox placement, spam complaint rate, bounce patterns by provider, reply rates, unsubscribes, and conversion behavior. Use seed testing where possible, but rely on actual subscriber behavior as the primary signal. This is similar to how teams assess performance in benchmark-driven technical environments: the real result matters more than the synthetic demo.

Keep transactional email isolated from promotional risk

If your platform architecture allows it, isolate order confirmations, password resets, and account alerts from promotional sending. Transactional streams should have the cleanest possible path to the inbox because they carry trust. During migration, verify that these messages retain correct routing, sender identity, and template logic. A broken password reset is not a minor bug; it is a customer support incident.

For organizations with multiple distribution types, it can help to think in terms of separate lanes. Promotional campaigns, lifecycle automations, and operational notifications should have different controls, owners, and QA checklists. That same separation-of-concerns approach is echoed in our guide to capacity shifts and resilience, where different freight paths absorb different risks.

5) Build a testing framework that catches real-world failures

Test the data, the logic, and the content separately

A migration is only as good as its test plan. You need three layers of QA: data validation, journey logic validation, and content rendering validation. First, confirm that sample records land in the new environment with the correct values, consent states, and segment membership. Second, test each branch of each journey using controlled inputs, including edge cases that are rare in production but expensive when they fail. Third, verify rendering across major email clients and devices, because a technically correct message can still fail visually.

Build a test matrix that includes regular contacts, suppressed contacts, duplicate records, missing fields, international records, and records with conflicting attributes. Then make sure every test has an expected result and an actual result recorded in a shared tracker. A disciplined checklist is not glamorous, but it prevents the kind of silent regression that can take weeks to detect. If your team works with many internal stakeholders, our guide on selecting the right contractor offers a good project-management parallel: sequence, verification, and accountability matter more than optimism.

Run parallel sends before full cutover

Parallel testing is one of the safest ways to preserve revenue during a migration. For a defined period, run the old and new systems side by side for a subset of journeys or audience slices. Compare send timing, content, segmentation, deliverability, and conversions. The goal is not identical dashboards; it is operational equivalence where it matters.

Parallel sends also reveal hidden dependencies. For instance, a journey may look fine in the new platform until a downstream webhook or product recommendation call fails. By comparing outcomes in real time, you can catch issues before the old platform is fully decommissioned. If you need a wider systems lens, our article on early risk detection is a useful analogy: spotting problems early is much cheaper than explaining them later.

Use sign-off criteria that are specific and measurable

Do not allow “looks good” to become your launch standard. Define explicit sign-off criteria for each migration wave, such as zero broken links, no unauthorized list expansions, acceptable inbox placement, match rates above a threshold, and parity on personalization outputs. Tie every go-live decision to evidence, not enthusiasm. A launch is ready when the system proves it is ready, not when the calendar says so.

For teams that want a decision framework for platform evaluation, the weighted approach in evaluating analytics providers is a useful model. It turns subjective preference into a repeatable method, which is exactly what migration governance needs.

6) Rebuild your martech stack around clean integration patterns

Decide what belongs in the new core

Leaving Salesforce is often an opportunity to redesign the martech stack around clearer responsibilities. Ask which system should own customer identity, segmentation, orchestration, content, analytics, and activation. If the answer is “everything in one platform,” you may simply be recreating the lock-in you wanted to escape. A better pattern is to keep each layer focused and connected through stable APIs, events, or warehouse-native workflows.

That architecture also improves resilience. When a single vendor change no longer controls every layer, you gain flexibility to swap tools without reworking the entire customer experience. The tradeoff is that integration becomes more deliberate, which is a good thing. For a practical lens on architectural choice, see our guide to platform selection criteria and our article on governance without blocking teams.

Document event flows and activation paths

Your migration checklist should include an event map: what events are captured, where they are stored, how they are transformed, and which systems act on them. This matters because journey rebuilds often fail when the trigger source changes but the downstream assumptions do not. For example, if a purchase event arrives late, the customer may receive a follow-up offer after they have already converted. That is not just annoying; it is a signal that the orchestration layer is no longer aligned with reality.

Map activation paths with the same rigor you would use for any customer-facing release. Include webhook endpoints, failure retries, queue behavior, and fallback logic. If your stack includes predictive scoring or AI-assisted targeting, our piece on moving ML outputs into action shows why the final mile is usually where value is won or lost.

Preserve analytics continuity

Marketing leaders often focus on sending, then discover that reporting has broken. Before migration, define how attribution, campaign IDs, UTM conventions, and event naming will work across the old and new systems. If a campaign report cannot be compared pre- and post-migration, you will lose the ability to prove impact. That is a serious problem when leadership expects the transition to improve efficiency, not obscure it.

Continuity also means keeping historical baselines accessible. Preserve a mapping between legacy campaign structures and new structures so that trend analysis remains meaningful. If your organization cares about measurable outcomes, the discipline in tracking social influence as an SEO metric is a strong reminder that measurement only works when the definition stays consistent over time.

7) Build a cutover plan that minimizes disruption

Sequence migration in waves, not all at once

Unless the business is very small, a big-bang cutover is too risky. Instead, move in waves: first data, then segmentation, then low-risk journeys, then high-value journeys, then advanced personalization. Each wave should have its own QA, owner, rollback criteria, and sign-off. This reduces complexity and gives the team time to learn the destination platform before the hardest assets move.

A wave-based approach also improves stakeholder confidence. When business teams see one flow succeed, they are more willing to trust the next one. This is the same reason teams use phased operational changes in complex environments; gradual adoption creates evidence. For more on structured rollout thinking, our guide on systems that sustain performance is a useful complement.

Communicate what changes for marketers and what does not

Internal adoption is part of migration success. Marketers need to know which workflows will change, which templates will need rebuilding, how approvals will work, and what new limitations or improvements they should expect. If you do not manage expectations, the new platform will be judged against the old one unfairly or used incorrectly because no one knows the new rules.

Provide concise playbooks for campaign builders, lifecycle marketers, analysts, and executives. Include screenshots, field maps, journey diagrams, and “common mistakes” sections. This reduces support load and prevents shadow processes from reappearing in spreadsheets. The broader lesson is similar to the one in compounding content strategy: clear systems outlast heroic effort.

Prepare customer support and sales teams for edge cases

When a migration affects communications, support and sales often feel the impact first. Give them a heads-up on what users might experience, what messages are being sent, and how to identify anomalies. If an onboarding email is delayed or a preference center issue appears, frontline teams should know where to look and whom to escalate to. That reduces confusion and protects trust.

Make a short incident response guide for common migration issues: duplicate sends, missing emails, stale segments, personalization fallbacks, and unsub errors. The guide should explain what to do, who owns the fix, and how to communicate externally if needed. For another example of structured response under pressure, see our article on operating through leadership turnover.

8) Measure success after launch, not just during it

Track migration health metrics for at least 90 days

Launch day is not the end of the project. It is the start of a monitoring period where you validate whether the system behaves under real load. Track deliverability, segment freshness, journey completion, personalization error rates, conversion, time-to-launch, and support tickets for at least 90 days after cutover. If metrics dip, you need to know whether the issue is isolated, structural, or temporary.

Create a dashboard that compares old and new baselines. Segment the data by campaign type, audience quality, sending domain, and device where relevant. That level of granularity helps distinguish platform problems from audience mix changes. If you want a comparison mindset that surfaces real tradeoffs, our guide to weighted provider evaluation is a good reference point.

Watch for hidden regressions in personalization and conversion

Some of the most damaging migration regressions do not show up as obvious outages. Instead, they appear as slightly lower click-through rates, fewer repeat purchases, weaker dynamic content relevance, or longer delay windows that reduce urgency. That is why you need cohort-level and journey-level analysis after launch, not just aggregate reporting. A 2% drop across multiple flows can become a meaningful revenue loss.

Use controlled comparisons whenever possible. Compare matched audiences, similar send windows, and equivalent offers. If performance recovers after a few weeks, document whether the cause was warm-up, data latency, or journey calibration. That documentation becomes part of your institutional memory and makes future migrations easier.

Turn the migration into an operating model upgrade

The best outcome is not simply “we left Salesforce.” The best outcome is that the new stack is easier to operate, easier to measure, and easier to evolve. That means the migration should leave behind better documentation, cleaner data structures, clearer ownership, and more reusable journey components. If those things do not improve, the organization may have changed tools without changing habits.

For leaders committed to long-term resilience, the lesson mirrors the thinking in marketing data governance: control, visibility, and explainability are not overhead. They are what make scalable growth possible. In other words, migration is not just a switch. It is a redesign of how marketing works.

Marketing Cloud migration checklist: the executive summary

Use this condensed checklist as your launchpad:

• Define the business reason for leaving and the success metrics that prove it.
• Inventory all source systems, fields, consent states, and suppression logic.
• Map identity rules, deduplication behavior, and personalization dependencies.
• Rebuild journeys from documented logic, not by copying legacy complexity.
• Protect deliverability with staged warm-up, authentication checks, and mailbox monitoring.
• Test data, logic, content, and edge cases separately before go-live.
• Run parallel sends and phased cutovers to reduce disruption.
• Preserve analytics continuity so pre/post comparison remains possible.
• Monitor the first 90 days as a formal stabilization period.

For teams trying to understand the real cost of platform dependency, this checklist is the practical part most strategy decks leave out. It is also why so many brands are thinking beyond a single suite and toward a more modular operating model. If you can keep your data portable, your journeys explainable, and your deliverability stable, you can leave Marketing Cloud without leaving performance behind.

Migration checklist table: what to do, who owns it, and why it matters

Pro tip: Treat the old platform like a reference implementation, not a template. The goal is to preserve customer outcomes, not the historical shape of every workflow.

Related Reading

• From Predictive Scores to Action: Exporting ML Outputs from Adobe Analytics into Activation Systems - Learn how to move decisioning data into the tools that actually send.
• Elevating AI Visibility: A C-Suite Guide to Data Governance in Marketing - A useful companion for teams rebuilding ownership and controls.
• How to Evaluate UK Data & Analytics Providers: A Weighted Decision Model - A practical framework for comparing vendors without getting lost in demos.
• Governance for No‑Code and Visual AI Platforms: How IT Should Retain Control Without Blocking Teams - Ideal for organizations balancing speed with oversight.
• Tracking Social Influence: The New SEO Metric for 2026 - Shows why consistent measurement definitions matter during system changes.