Migrate from Salesforce Marketing Cloud

Plan a migration from Salesforce Marketing Cloud Engagement (SFMC) to Courier. Most teams land on the same split. Salesforce keeps the customer data, Courier does the sending. Engineers, marketers, and AI agents build and send messages in Courier from data synced out of Salesforce.

​

Map Salesforce Marketing Cloud concepts to Courier

​

Journey Builder and Journeys

Journey Builder runs multi-step campaigns from entry sources. A contact lands in a Data Extension, fires an API event, or matches an audience. From there it moves through waits, decision splits, and sends. Courier fill the same role. A journey starts from a : API invoke, inbound webhook, Segment event, or audience membership. Two Courier nodes Journey Builder handles differently:

• cap how many times a user (or all users globally) can pass a point in a journey within a time window. SFMC has no built-in send-collision control, so teams build exclusion logic by hand across journeys. A throttle node expresses “max 3 marketing messages per user per 24 hours” directly in the workflow.
• and nodes collapse many events into one message, which in SFMC requires SQL queries and scheduled automations.

​

Automation Studio

Automation Studio does three jobs. Each migrates somewhere different. One-time and scheduled sends become . Pick a template and a list or audience, then send now or schedule a date, time, and timezone. Scheduled broadcasts can be rescheduled or canceled until they fire. Recurring sends (a daily or weekly automation that sends to a refreshed Data Extension) have no direct equivalent, because broadcasts don’t repeat. Run the schedule where your other cron jobs live and call the against a list or audience. Audience membership updates automatically as profiles change, so the “refresh the Data Extension, then send” two-step collapses into one API call. Data workflows (SQL query activities, file imports, data extracts) don’t move to Courier. Courier is not an ETL tool. Run those transformations in your data warehouse, in Salesforce, or in your application. Sync the results to Courier as user profile attributes or audience memberships. The SQL that lived in Automation Studio moves into version-controlled code in your own stack.

​

Email Studio, Content Builder, and Design Studio

Templates move to . A Courier template holds content for every channel (email, SMS, push, in-app, chat) in one resource. Build it with drag-and-drop blocks, or define it as JSON. For one-time campaign sends that lived in Email Studio, use with the template and an audience.

​

Data Extensions and user profiles

Data Extensions are relational tables. Courier are JSON documents keyed by user_id. This is the biggest shift in the migration. Your sendable Data Extension (the one keyed by subscriber key with email, phone, and personalization fields) becomes the Courier user profile. Profiles accept nested JSON, so attributes like plan tier, care team, or order history need no schema migration. Relational Data Extensions (lookup tables you join with SQL) stay in your database. Flatten what a message needs onto the profile at sync time, or pass it in the data field at send time. Data that changes per event belongs in data. Data that describes the person belongs on the profile. Load users in bulk with the or create them inline: sending to an unknown user_id with profile data creates the user.

​

Keeping Salesforce as the system of record

You don’t migrate off Salesforce, only off Marketing Cloud’s sending layer. Contacts, deals, and consent records stay in Salesforce CRM. What SFMC did with Marketing Cloud Connect, you do with a sync process you control:

1. Outbound from Salesforce: platform events, Change Data Capture, or a scheduled export push contact changes to your backend.
2. Into Courier: your backend upserts profiles through the or bulk jobs, and audience membership recalculates automatically from profile attributes.
3. At send time: your application triggers sends and journeys with event data. Courier joins it with the synced profile.

The sync is one-directional and small. Courier needs identifiers, channel addresses, and the attributes you segment or personalize on, not your whole CRM.

​

Triggered sends and the Send API

SFMC’s Triggered Sends and Transactional Messaging API map to the Courier . One request sends to a user across any configured channel. Courier handles routing, provider failover, and delivery tracking. No separate transactional subsystem to configure. Every send goes through the same pipeline.

​

Subscription Center and preferences

SFMC publication lists and the Subscription Center manage opt-outs, mostly for email. Courier manage opt-in and opt-out per topic and per channel. Courier enforces them at send time. You get a , or to build the preference center into your product. Map each publication list to a preference topic during migration, and carry unsubscribes over before the first send.

​

AMPscript and personalization

AMPscript and SSJS blocks become plus data you pass on the send call. Lookup() and LookupRows() patterns invert. A template used to reach into a Data Extension at render time. Now you fetch the data first, or use a mid-journey, then pass it in data. Templates render from what you give them, which makes sends reproducible and testable.

​

Authentication

SFMC authenticates through installed packages: OAuth 2.0 client credentials against a tenant-specific subdomain, with scoped tokens that expire. Courier uses , a bearer token per workspace, with separate keys for test and production. Server-side calls use the key directly. Client-side surfaces like in-app inbox use short-lived scoped to a user.

​

Plan the migration

1. Inventory what actually sends. Export your active journeys, triggered sends, and automations. Most SFMC accounts carry years of dead journeys. Migrate the live ones.
2. Stand up the data sync. Salesforce to your backend to Courier profiles. Validate with a test audience before moving anything user-facing.
3. Recreate templates in Design Studio. Start from the highest-volume sends. Move AMPscript logic into send-time data.
4. Map publication lists to preference topics and import unsubscribes first.
5. Rebuild journeys, one at a time. Run the Courier journey in parallel against a test audience and compare output. Then cut the entry source over and pause the SFMC journey.
6. Point triggered sends at the send API. They cut over cleanly, because they are already API-driven in SFMC.
7. Decommission by watching send logs, not the calendar. When an SFMC journey has sent nothing in 30 days and its Courier replacement is live, retire it.

​

Migrate with an AI agent

If you’re running the migration with Claude Code, Cursor, or another coding agent, two things help:

• gives your agent direct access to your workspace. It can create templates, build journeys, upsert users, and inspect send logs as it works through the plan above.
• The concept-mapping table at the top of this page is the translation layer. An agent holding an SFMC journey export and that table can propose the equivalent Courier journey. The lets it build the result programmatically.

A workable prompt: export the journey definition from SFMC’s REST API (/interaction/v1/interactions), then hand it to your agent with this page. Ask for the equivalent Courier journey, plus the profile fields the sync has to provide.

​

FAQ