Brands move from Salesforce Marketing Cloud (now Marketing Cloud Engagement, part of Salesforce’s Agentforce Marketing suite) to Iterable when the cost and technical effort of running it outgrow what the marketing team gets from it. The most common reasons are a dependence on SQL and AMPscript specialists for routine changes, Data Extensions that lag behind what customers are doing right now, and channels built in separate studios that are hard to coordinate.
This guide covers why brands switch, how Salesforce Marketing Cloud (SFMC) concepts map to Iterable, how a migration runs, what to plan for before you set a cutover date, and how to decide whether switching is right for you. For a head-to-head product comparison, see our enterprise comparison page.
Key takeaways
- Brands switch when specialist dependency and slow changes outweigh the value of their SFMC setup.
- A migration is a redesign, not a copy: identity, data, templates, and journeys are rebuilt around how you want to work.
- Most migrations run four workstreams in parallel: data and identity, programs and templates, integrations and channels, and launch.
- History, AMPscript, templates, and SMS short codes each need their own plan before you set a cutover date.
Why brands move from Salesforce Marketing Cloud to Iterable
1. Less dependence on specialists for everyday changes
In many SFMC setups, a lifecycle marketer opens a ticket for every new audience query, personalization change, or template update, because those changes require SQL or AMPscript.
In Iterable, marketers build segments without SQL and personalize messages with Dynamic Templates and Handlebars. Nova Agent helps marketers generate, check, and fix Handlebars personalization logic from a plain-language request. Technical teams still own identity, data feeds, and integrations, but routine campaign work no longer waits on them.
2. A faster path from customer signal to journey change
When a marketer spots a problem, such as customers dropping off after a setup step, the fix should take hours, not a sprint. In Journeys, marketers adjust branches, waits, and messages directly in the Visual Journey Builder, and can build or update a journey from a plain-language request.
3. Channels, content, and journeys in one place
Journey Builder can send across email, SMS, and push, but each channel is set up and managed in its own studio, with its own content tools and configuration. Launching or changing a cross-channel program means working across several of them. In Iterable, channel setup, templates, and journeys live in the same workspace, so one marketer can build the program end to end. A single journey decides the next step and sends on whichever channel fits: email, SMS, push, in-app, web push, WhatsApp, RCS, or embedded messages.
4. Real-time data without extra plumbing
SFMC can trigger journeys in real time through API Events and Salesforce Data entry, but many audiences still run on Data Extensions that are refreshed by scheduled imports and SQL queries. Keeping those audiences current takes ongoing technical work. Iterable acts on profile data and real-time events, such as a browse or a purchase, as they arrive, and uses Catalog for product, inventory, and other reference data, so segments and journeys stay current without a refresh job behind them.
5. Lower total operating effort
License price is only part of the cost. Compare the full effort of running each platform: specialist hours for SQL and scripting, implementation and training, integration maintenance, and the time it takes to launch or change a program. Brands often find that reducing that day-to-day effort is where most of the value comes from.
What changes: SFMC terms in Iterable
A migration redesigns each piece around its purpose rather than renaming it. Here is how the main SFMC concepts map to Iterable:
| SFMC concept | Iterable equivalent | What to do in the migration |
|---|---|---|
| Subscriber Key | userId and/or email | Decide how each person is identified, deduplicated, and matched to consent |
| Business Units | Projects, roles, and permissions | Redesign how brands, regions, and teams are separated and share data |
| Data Extensions | User profiles, events, Catalog, lists, and segments | Map each extension by what it’s used for |
| AMPscript | Handlebars, Dynamic Templates, and Catalog | Rebuild the business logic, not just the syntax |
| Journey Builder | Journeys | Rebuild entries, branches, waits, exits, and suppression |
| Automation Studio | APIs, webhooks, scheduled lists, and Journeys | Break each job into its purpose and rebuild it |
Example: a renewal program. In SFMC, a renewal reminder might use a Subscriber Key, an eligibility Data Extension, AMPscript for the offer, Journey Builder for timing, and an Automation Studio job to refresh the audience. In Iterable, eligibility becomes profile or Catalog data, the offer logic becomes a Handlebars template, the timing becomes a journey, and the audience refreshes automatically as data changes.
How the migration runs
Most SFMC migrations run four workstreams in parallel, with shared checkpoints. The timeline depends on scope: the number of programs, the complexity of your scripts, your channels, and whether you’re moving SMS short codes. Our migration guide covers planning in more depth.
| Workstream | What happens | Done when |
|---|---|---|
| Data and identity | Decide how people are identified, map data, and load current profiles and needed history | Sample records match between systems |
| Programs and templates | Rebuild priority programs and templates, starting with the highest-value ones | Each program passes testing |
| Integrations and channels | Connect data sources, CRM sync, sending domains, push credentials, and SMS senders | Data and messages flow end to end |
| Launch | Move programs over in waves, with one sending owner per audience during the overlap | Every program runs on Iterable and SFMC is retired |
Data and identity. Start by deciding who each record represents. One customer might have one Subscriber Key, two email addresses, an SMS opt-in, and loyalty events, and they need to resolve to one person before any program depends on them. Iterable’s Salesforce integration syncs CRM objects on a schedule and can backfill history per object.
Programs and templates. Don’t carry every legacy program forward. Rank programs by revenue and lifecycle importance, migrate high-value, lower-complexity ones first, and consolidate or retire the rest.
Integrations and channels. List every connection the programs depend on: CRM syncs, APIs, webhooks, file feeds, and warehouses coming in; email domains, IP addresses, push credentials, and SMS senders going out; and analytics and exports flowing back. Confirm consent is checked at both entry and send.
Launch. Move a lower-risk newsletter first, then triggered programs. During the overlap, assign one sending owner per audience so no one gets duplicate messages, and agree in advance on rollback criteria and deliverability ramp-up.
What to plan for before you set a cutover date
History. Move what active programs need, such as current profiles, consent, and the purchase events a win-back program uses, and archive older reporting history in your data warehouse.
AMPscript. Treat each script as business logic to review, not syntax to translate. Some logic can be simplified, some is better handled as data before the message renders, and the rest is rebuilt in Handlebars and tested against real records, including missing values and different locales.
Templates. Use the migration to consolidate. Instead of rebuilding every template one for one, move product and regional content into Catalog and let a smaller set of dynamic templates handle the variation. Stanley Black & Decker took this approach with Iterable Catalog, creating 80% fewer email templates while personalized emails drove 7% more clicks to ecommerce stores than non-personalized ones.
SMS short codes. A U.S. short code doesn’t move with your profiles or journeys. Transferring it requires a migration letter, carrier review, and HELP and STOP keyword testing. Carrier approval for a short code migration typically takes 8–12 weeks, according to Twilio, so start early and plan it as its own track. Our SMS compliance guide covers the steps.
Should you replace Salesforce Marketing Cloud at all?
Switching isn’t the right call for everyone. Use this table to check where you stand:
| Area | Staying makes sense when | Switching makes sense when |
|---|---|---|
| Team | Your specialists are productive and not a bottleneck | Routine changes wait on scarce SQL and AMPscript skills |
| Speed | Program changes ship fast enough | Simple journey changes take weeks |
| Channels | Your teams coordinate channels well | Logic is duplicated across studios |
| Data | Activation works and is easy to understand | Workarounds make audiences hard to trust |
| Cost | Operating effort matches the value delivered | Upkeep crowds out higher-value work |
| Timing | Migration disruption would outweigh the benefit | Current delays threaten important programs |
If your SFMC setup is complex because it needs to be, and it’s delivering reliably, staying may be the right decision. If your team spends most of its time working around the platform, it’s worth scoping a migration.
Frequently asked questions
What are the main reasons enterprise brands switch from Salesforce Marketing Cloud to Iterable?
Brands switch when routine marketing work depends on SQL and AMPscript specialists, when Data Extensions lag behind real-time customer behavior, and when channels built in separate studios make cross-channel programs slow to build. In Iterable, marketers build segments, personalize messages, and change journeys themselves, while technical teams focus on data and integrations.
How do you migrate from Salesforce Marketing Cloud to Iterable?
Run four workstreams in parallel: data and identity, programs and templates, integrations and channels, and launch. Start by deciding how customers are identified, rebuild your highest-value programs first, and move programs over in waves, starting with a lower-risk newsletter. See our migration planning guide.
What replaces Data Extensions, AMPscript, Journey Builder, and Automation Studio in Iterable?
Data Extensions become user profiles, events, Catalog, lists, or segments, depending on what each one is used for. AMPscript logic is rebuilt in Handlebars and Dynamic Templates. Journey Builder flows are rebuilt in Journeys, and Automation Studio jobs are replaced by APIs, webhooks, scheduled lists, or journeys.
Do I have to move to Marketing Cloud Next?
No. Salesforce has rebranded Marketing Cloud as Agentforce Marketing and offers Marketing Cloud Next as its next-generation platform. Even where the new products are included in an existing contract, moving to them is still a migration: new data foundations, rebuilt journeys, and retrained teams. Since you’ll be doing that work either way, compare the operating model, effort, and long-term value of each destination side by side before you commit.
How long does an SFMC migration to Iterable take?
It depends on scope: how many programs you have, how complex your AMPscript is, which channels you use, and whether you’re transferring SMS short codes. A single-brand email migration can move much faster than a global migration across email, push, and SMS. Short code transfers run on their own track and can take several weeks.
Can a U.S. short code move from SFMC to Iterable?
Yes, through a separate process with your SMS provider and the carriers. Plan for a migration letter, carrier review, and HELP and STOP keyword testing, and start early: Twilio describes a 6–10-week connectivity stage for this step.
Plan the migration around how you want to work
A successful move from Salesforce Marketing Cloud keeps what your programs are meant to do while redesigning how they’re built. Scope the four workstreams, name an owner for each, and plan history, scripts, templates, and short codes before you pick a date.
Next step: Get the migration guide