> ## Documentation Index > Fetch the complete documentation index at: https://www.courier.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Migrate from Salesforce Marketing Cloud > Move your notification and customer messaging workflows from Salesforce Marketing Cloud Engagement to Courier. Covers concept mapping, data sync from Salesforce, and a step-by-step migration plan. This guide helps you plan a migration from Salesforce Marketing Cloud Engagement (SFMC) to Courier. It maps SFMC concepts to their Courier equivalents, shows how to keep Salesforce as your system of record while Courier handles delivery, and lays out a migration plan. The pattern most teams land on: Salesforce keeps the customer data, Courier does the sending. Engineers, marketers, and AI agents build and send messages in Courier, working from data synced out of Salesforce. ## Mapping Salesforce Marketing Cloud Concepts to Courier | Salesforce Marketing Cloud | Courier | | ------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | [Journey Builder](https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/journey-builder-api-overview.html) | [Journeys](/docs/platform/journeys/journeys-overview) | | Automation Studio (one-time and scheduled sends) | [Broadcasts](/docs/platform/broadcasts/broadcasts-overview) | | Automation Studio (recurring sends) | Your scheduler + [send to a list or audience](/docs/platform/sending/send-message) | | Automation Studio (SQL queries, imports) | Stays in your data stack; sync results to Courier | | Email Studio / Content Builder | [Design Studio](/docs/platform/content/design-studio/design-studio-overview) | | Data Extensions | [User profiles](/docs/platform/users/users-overview) (nested JSON) | | Contact Builder / All Contacts | [Users](/docs/platform/users/users) | | Filtered Data Extensions / segments | [Audiences](/docs/platform/users/audiences) | | [Triggered Sends / Transactional Messaging API](https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/transactional-messaging-api.html) | [Send API](/docs/platform/sending/send-message) | | [API Event entry sources](https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/journey-builder-api-overview.html) | [Journey triggers](/docs/platform/journeys/invocation): API, webhook, Segment, audience | | [AMPscript](https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/ampscript.html) / SSJS personalization | [Handlebars variables](/docs/platform/content/variables/inserting-variables) + `data` on send | | Subscription Center / publication lists | [Preferences](/docs/platform/preferences/preferences-overview) | | MobileConnect / MobilePush (SMS and push) | SMS and push channels through [your providers](/docs/external-integrations/integrations-overview) | | MobilePush inbox / in-app messages | [Inbox](/docs/platform/inbox/inbox-overview) | | Sender Authentication Package (SAP) | Domain configuration with your [email provider](/docs/external-integrations/integrations-overview) | | Installed packages (OAuth 2.0 client credentials) | [API keys](/docs/reference/api-overview#authentication) | ### Journey Builder and Journeys Salesforce Marketing Cloud Journey Builder runs multi-step campaigns from entry sources: a contact lands in a Data Extension, fires an API event, or matches an audience, then moves through waits, decision splits, and sends. Courier [Journeys](/docs/platform/journeys/journeys-overview) fill the same role. A journey starts from a [trigger](/docs/platform/journeys/invocation) (API invoke, inbound webhook, Segment event, or audience membership) and runs the user through the workflow. | Journey Builder activity | Courier equivalent | | ------------------------------------- | -------------------------------------------------------------------------------------------------- | | Email / SMS / push activity | [Send node](/docs/platform/journeys/nodes/send) (references a template) | | Wait activity | [Delay node](/docs/platform/journeys/nodes/delay) | | Decision split | [Branch node](/docs/platform/journeys/nodes/branch) | | Einstein STO / engagement splits | [Experiments](/docs/platform/journeys/experiments) on send nodes | | Journey exit criteria | [Cancel node](/docs/platform/journeys/nodes/cancel) + [cancellation API](/docs/platform/journeys/invocation) | | Update contact activity | [Profile updates via API](/docs/api-reference/user-profiles/update-a-profile) | | Custom activity (fetch external data) | [Fetch data node](/docs/platform/journeys/nodes/fetch-data) | Two things Courier journeys have that Journey Builder handles differently: * **[Throttle nodes](/docs/platform/journeys/nodes/throttle)** cap how many times a user (or all users globally) can pass a point in a journey within a time window. Salesforce Marketing Cloud Engagement has no built-in send-collision control; teams build exclusion logic by hand across journeys. In Courier, a throttle node expresses "max 3 marketing messages per user per 24 hours" directly in the workflow. * **[Batch](/docs/platform/journeys/nodes/batch) and [digest](/docs/platform/journeys/nodes/digest) nodes** collapse many events into one message, which in SFMC requires SQL queries and scheduled automations. ### Automation Studio Automation Studio does three different jobs, and they migrate to different places. **One-time and scheduled sends** become [Broadcasts](/docs/platform/broadcasts/broadcasts-overview): pick a template, pick a list or audience, send now or schedule it for 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 [send API](/docs/platform/sending/send-message) against a list or audience. Since your audience membership updates automatically as profiles change, 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, then sync the results to Courier as user profile attributes or audience memberships. The SQL that lived half-hidden in Automation Studio moves back into version-controlled code in your own stack. ### Email Studio, Content Builder, and Design Studio Templates move to [Design Studio](/docs/platform/content/design-studio/design-studio-overview). A Courier template holds content for every channel (email, SMS, push, in-app, chat) in one resource, built with drag-and-drop blocks or defined programmatically as [Elemental](/docs/platform/content/elemental/elemental-overview) JSON. For one-time campaign sends that lived in Email Studio, use [Broadcasts](/docs/platform/broadcasts/broadcasts-overview) with the template and an audience. ### Data Extensions and User Profiles Data Extensions are relational tables; Courier [user profiles](/docs/platform/users/users-overview) are JSON documents keyed by `user_id`. This is the biggest mental-model shift in the migration. The working translation: 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 fit naturally without a schema migration. **Relational Data Extensions** (lookup tables you join with SQL) stay in your database. Either 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 [bulk API](/docs/tutorials/sending/how-to-send-bulk-notifications) 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 [users API](/docs/api-reference/user-profiles/update-a-profile) 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 Salesforce Marketing Cloud's Triggered Sends and Transactional Messaging API map to the Courier [send API](/docs/platform/sending/send-message). One request sends to a user across any configured channel, with routing, provider failover, and delivery tracking handled by Courier. There's no separate transactional subsystem to configure; every send goes through the same pipeline. ### Subscription Center and Preferences Salesforce Marketing Cloud publication lists and the Subscription Center manage opt-outs mostly for email. Courier [Preferences](/docs/platform/preferences/preferences-overview) manage opt-in and opt-out per topic and per channel, and Courier enforces them automatically at send time. You get a [hosted preference page](/docs/platform/preferences/hosted-page) out of the box, or [embeddable components](/docs/platform/preferences/embedding-preferences) for building 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 [Handlebars variables](/docs/platform/content/variables/inserting-variables) plus data you pass on the send call. `Lookup()` and `LookupRows()` patterns, where a template reaches into a Data Extension at render time, invert: fetch the data before you send (or with a [fetch data node](/docs/platform/journeys/nodes/fetch-data) mid-journey) and pass it in `data`. Templates render from what you give them, which makes sends reproducible and testable. ### Authentication Salesforce Marketing Cloud authenticates through installed packages: OAuth 2.0 client credentials against a tenant-specific subdomain, with scoped tokens that expire. Courier uses [API key authentication](/docs/reference/api-overview#authentication): a bearer token per workspace, with separate keys for test and production environments. Server-side calls use the key directly; client-side surfaces like in-app inbox use short-lived [JWTs](/docs/tutorials/inbox/how-to-send-jwt) scoped to a user. ## Migration Plan 1. **Inventory what actually sends.** Export your active journeys, triggered sends, and automations. Most Salesforce Marketing Cloud 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, compare output, then cut the entry source over and pause the SFMC journey. 6. **Point triggered sends at the send API.** These cut over cleanly since they're 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. ## Migrating with an AI Agent If you're using Claude Code, Cursor, or another coding agent to run the migration, two things help: * **[Courier's MCP server](/docs/tools/mcp)** gives your agent direct access to your workspace: it can create templates, build journeys, upsert users, and inspect send logs while 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, and the [journeys API](/docs/platform/journeys/building-journeys-via-api) lets it build the result programmatically. A workable prompt: export the journey definition from SFMC's REST API (`/interaction/v1/interactions`), hand it to your agent with this page, and ask for the equivalent Courier journey plus the profile fields the sync needs to provide. ## FAQ Yes, and you should. Contacts, deals, and consent records stay in Salesforce CRM. A sync you control (platform events, Change Data Capture, or scheduled exports) pushes identifiers, channel addresses, and segmentation attributes into Courier as [user profiles](/docs/platform/users/users-overview). Courier replaces Marketing Cloud's sending layer, not your CRM. [Journeys](/docs/platform/journeys/journeys-overview). Entry sources become [triggers](/docs/platform/journeys/invocation) (API invoke, inbound webhook, Segment event, or audience membership), and Journey Builder activities map to nodes: waits to [delay](/docs/platform/journeys/nodes/delay), decision splits to [branch](/docs/platform/journeys/nodes/branch), sends to [send nodes](/docs/platform/journeys/nodes/send). Courier adds [throttle](/docs/platform/journeys/nodes/throttle) and [digest](/docs/platform/journeys/nodes/digest) nodes that Journey Builder has no equivalent for. Your sendable Data Extension becomes Courier user profiles: JSON documents keyed by `user_id` that accept nested attributes without a schema. Relational Data Extensions 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. No. Personalization uses [Handlebars variables](/docs/platform/content/variables/inserting-variables) in templates plus data you pass on the send call. AMPscript patterns that look up data at render time invert in Courier: fetch the data before you send, or use a [fetch data node](/docs/platform/journeys/nodes/fetch-data) mid-journey, and pass the result in `data`. Landing pages (CloudPages), ad audience activation (Advertising Studio), marketing attribution, and Automation Studio's data-transformation work (SQL query activities, imports, extracts). Those stay in Salesforce or elsewhere in your stack. Courier replaces message delivery and orchestration: journeys, triggered sends, campaigns, templates, and preferences.