Salesforce Marketing Cloud to Braze Migration Guide

Salesforce Marketing Cloud migrations are unlike any other. Not because the platform is difficult to leave — though it is — but because of the weight of what's been built on top of it over the years.

SFMC accounts at enterprise scale are archaeological sites. Layers of Journey Builder workflows built by teams that no longer exist. AMPscript logic that nobody fully documented. Data Extensions with column naming conventions that made sense in 2017. Suppression lists spread across multiple Business Units. Contact Builder data models that took months to design and are now held together by institutional knowledge rather than documentation.

When an enterprise team migrates from Salesforce Marketing Cloud to Braze, the technical migration is the second-hardest problem. The first is the audit. Understanding what's actually running before touching anything is what determines whether this is a 12-week migration or an 18-month one.

At Propel, we've managed migrations to Braze from SFMC for enterprise teams who've spent years accumulating complexity in their Salesforce instance. What follows is the operator-level guide — including the parts that most migration guides don't cover.

Why Enterprises Move From Salesforce Marketing Cloud to Braze

SFMC is a powerful platform. It's also one of the most operationally complex tools in the martech stack — and that complexity compounds over time in ways that eventually become a liability rather than an asset.

Operational overhead. SFMC's power comes with proportional operational cost. Maintaining Data Extensions, managing Business Unit structures, building and debugging SQL queries in Automation Studio, and keeping AMPscript personalization logic current requires dedicated SFMC expertise. As that expertise becomes harder to retain, the platform becomes harder to operate. Braze's model is operationally lighter — Canvas Flow's visual builder and Liquid templating have a lower ongoing maintenance burden for teams that aren't maintaining a dedicated SFMC team.

Real-time processing. SFMC's Journey Builder, in most implementations, processes contact entry and event triggers on a schedule — minutes to hours, depending on configuration. Braze processes events in true real-time from the SDK. For lifecycle programs where behavioral timing is a primary lever — particularly in fintech, health and fitness apps, and marketplace contexts — this processing gap has direct revenue implications.

Mobile and app channel depth. SFMC's mobile channel capabilities require MobilePush, which is licensed separately and sits somewhat outside the core Journey Builder experience. Braze's push, in-app messaging, and Content Cards are native to the Canvas Flow builder and deeply integrated into the same event stream powering email. For brands whose retention marketing for mobile apps is a primary lifecycle focus, Braze's unified model is meaningfully different.

The Salesforce ecosystem dependency. SFMC works best when deeply integrated with Salesforce CRM. For enterprise DTC or consumer product brands that aren't primarily Salesforce CRM shops, SFMC's architecture is optimized for a relationship that doesn't exist — creating friction that Braze's more flexible data model avoids.

One enterprise consumer brand we worked with had 67 active Journeys in SFMC at migration start. The audit revealed that 23 were completely inactive (their entry sources had been deprecated), 18 were duplicates of other Journeys created by different teams, and 11 were running with broken AMPscript personalization that had been silently failing for months. The actual active program was 15 Journeys. The migration scope contracted by 78% before a single Canvas was built.

The Architecture Shift: SFMC to Braze

SFMC's model: Business Unit-centric, object-relational, and message-sequence-focused. Contacts live in All Subscribers or Data Extensions. Relationships between data sets are managed through Contact Builder. Journeys trigger on data events, scheduled entry sources, or API calls. Personalization uses AMPscript (proprietary) or SSJS.

Braze's model: Profile-centric and event-driven. Every user has a unified profile with Custom Attributes and Custom Event history. Canvases trigger off Custom Events from any source. Personalization uses Liquid and Connected Content. There are no Business Units — the workspace is unified, with audience segmentation handling the multi-brand or multi-product separation that SFMC manages through Business Unit structures. This unified model is the foundation of genuine omnichannel orchestration rather than siloed channel management.

The migration consequence: every Data Extension used in active Journeys must be analyzed and its data either mapped to Braze Custom Attributes or replaced with Connected Content API calls. Every AMPscript block in active templates must be rewritten in Liquid. Every Journey entry source must be converted to a Braze Custom Event or API trigger.

What Transfers and What Doesn't

Transfers With Mapping ✅

Contact identity data. Email, phone, subscriber key, and standard profile fields transfer via CSV import or API. Map your SFMC Subscriber Key to Braze's external_id for consistent user identity across systems.

Suppression and opt-out data. This is the most complex suppression migration of any platform we work with. SFMC manages opt-outs at the Business Unit level, the Publication List level, and the All Subscribers level. Every layer must be mapped to the appropriate Braze mechanism: global email suppression, SMS Subscription Group opt-outs, or channel-specific suppression. This mapping must be documented and verified before any active contact imports. For brands with compliance obligations — particularly in telemedicine or other regulated verticals — this step has direct legal consequences.

Custom Data Extension fields → Custom Attributes. Fields used for personalization or segmentation in active Journeys must be mapped to Braze Custom Attributes. Fields used only for Automation Studio queries or reporting can be left in SFMC.

Purchase and behavioral event history (with planning). Historical behavioral data can be backfilled via Braze's /users/track API. For teams where SFMC's Synchronized Data Extensions pull from Salesforce CRM, the backfill source may be the CRM rather than SFMC itself — plan the data source explicitly.

Must Be Rebuilt 🔄

Every Journey becomes a Canvas. Journey Builder's architecture is fundamentally different from Canvas Flow's. Every Journey must be rebuilt as a net-new Canvas. The rebuild is not a translation — it's a re-architecture. Apply the lifecycle stage segmentation playbook to rethink how your audiences are defined in Braze before building any Canvas.

AMPscript → Liquid. Every AMPscript personalization block, conditional logic statement, and dynamic content function must be rewritten in Braze's Liquid dialect. This is a dedicated workstream for SFMC migrations. Teams with large template libraries should audit AMPscript usage across all active templates before the migration starts — the complexity varies enormously between accounts.

Automation Studio queries → Braze segments and Canvas triggers. SFMC's SQL-based Automation Studio queries are frequently used to generate audiences for Journey entries or to refresh Data Extensions. In Braze, these are replaced by dynamic segments (which update in real time based on Custom Attribute and event filters) and Canvas entry conditions (which trigger on events rather than scheduled query results).

Content Builder templates. SFMC's Content Builder templates and Blocks are proprietary. They must be rebuilt in Braze's Drag-and-Drop Editor or HTML editor. Apply the pre-send email QA checklist to every rebuilt template before it goes live.

Lost or Replaced ❎

Salesforce CRM data sync. If your SFMC instance uses Synchronized Data Extensions to pull CRM data into journey personalization, that data pipeline needs to be rebuilt. Depending on your stack, this may mean a direct Salesforce-to-Braze integration, or routing CRM data through your data warehouse into Braze via Currents or cloud data ingestion.

SFMC's Einstein features. Salesforce's Einstein Send Time Optimization and Einstein Engagement Scoring have Braze equivalents — Intelligent Timing and Predictive models — but they are calibrated differently and require a warm-up period before producing reliable outputs. Plan for 30–60 days before Braze's predictive features replace SFMC's Einstein-powered decisions.

Business Unit separation. If you've used SFMC Business Units to segment brands, regions, or product lines, Braze handles this through workspace configuration, audience segmentation, and subscription group management. The separation mechanism is different — plan how your multi-brand or multi-product architecture translates before building any Canvas.

Migration Checklist: SFMC to Braze

Pre-Migration Audit (Allow Extra Time)

• Inventory all active Journeys with entry source, channel mix, and entry volume — deactivate any Journey with zero entry in the last 90 days before counting scope.
• Audit all AMPscript blocks across active templates — document complexity per template.
• Map all Data Extensions used in active Journeys to their Braze Custom Attribute equivalent.
• Document Business Unit suppression structure — map every opt-out list to Braze mechanism.
• Identify Automation Studio queries used for Journey entry — convert to Braze event or segment entry logic.
• Assess Salesforce CRM data dependency — plan integration bridge if CRM data is used in personalization.

Data Migration

• Export suppression data from all Business Units — consolidate and import to Braze Subscription Groups and global suppression first.
• Export All Subscribers active contacts with mapped Data Extension fields.
• Segment contacts into engagement tiers before import.
• Backfill historical event data via /users/track API if needed for Canvas entry or predictive models.

Technical Setup

• Verify sending domain per Business Unit or consolidated domain in Braze — DKIM, SPF, DMARC. Reference email deliverability channel health standards.
• Configure Braze Subscription Groups to replace SFMC Publication List opt-out structure.
• Instrument Braze SDK for app channels — validate against event schema per events and attributes architecture spec.
• Build Connected Content endpoints to replace Data Extension-driven personalization where applicable.
• Set up Braze Currents for data warehouse integration.

Canvas Rebuild and Go-Live

• Rebuild Canvases in priority order — begin with highest-volume lifecycle touchpoints.
• Rewrite all AMPscript in Liquid — QA every personalization tag with a test user profile.
• Run full end-to-end Canvas QA before deactivating any SFMC Journey.
• Execute email deliverability warm-up over 4–6 weeks from first send.
• Connect Braze Currents to analytics stack and validate retention metrics dashboard data flow.

The AMPscript to Liquid Migration: What to Expect

AMPscript is SFMC's proprietary scripting language. Liquid is Braze's templating language (a standard open-source language also used by Shopify). They are not syntactically compatible — there is no automated conversion.

The practical scope: every AMPscript IF/ELSE conditional, every Lookup() function pulling from a Data Extension, every Format() date or number expression, and every ContentBlockbyID() dynamic content call must be manually rewritten in Liquid or replaced with a Connected Content endpoint.

The good news: Liquid is more readable than AMPscript for most use cases, and Braze's Liquid implementation is well-documented. The work is not technically complex — it is time-consuming and requires testing every template against real user data before any Canvas goes live.

For teams with 50+ active templates with AMPscript personalization, we recommend treating the AMPscript migration as a parallel workstream to the Canvas rebuild — not a prerequisite, not an afterthought. This is part of how building personalized email flows without manual work becomes the permanent state in Braze, rather than the AMPscript maintenance burden that SFMC personalization often becomes.

Stakeholder Expectations

Lifecycle and CRM team: SFMC migrations are the longest of any platform migration we manage. Budget 14–20 weeks for a typical enterprise program with multi-Business-Unit structure, active AMPscript templates, and app channels in scope. The audit phase alone is 3–4 weeks for complex accounts.

Engineering team: SDK instrumentation for app channels, Connected Content endpoint development, and potential Salesforce CRM integration bridge all require engineering involvement. This is a larger engineering scope than most other platform migrations.

Data and analytics teams: The SFMC-to-Braze data model shift requires direct data engineering involvement in schema design. The Currents event schema must match your warehouse table structure. Our events and attributes architecture service manages this as a formal pre-migration deliverable.

Leadership: The audit phase frequently reveals that the active program is significantly smaller than the apparent program. This is good news for migration scope but can create stakeholder confusion if the discovery isn't framed correctly upfront. We build a pre-migration scope briefing into every SFMC migration engagement. The campaign analytics and performance insights service maintains performance visibility throughout the transition.

Why Propel for Your SFMC to Braze Migration

Propel is a certified Braze partner with enterprise migration experience that includes the full complexity of large SFMC accounts. Our practice covers AMPscript-to-Liquid conversion, Business Unit suppression consolidation, Salesforce CRM integration bridging, and the lifecycle strategy review that every Canvas rebuild should include.

Talk to a Propel operator about your SFMC to Braze migration.