Migrating from SFMC to Braze: What to Expect + Full Checklist

Migrating from SFMC to Braze: What to Expect + Full Checklist

Migrating from Salesforce Marketing Cloud to Braze is one of the most common enterprise marketing platform switches in 2026 — and one of the most technically complex. Unlike simpler email-to-email migrations, this move involves fundamentally different data architectures, a shift from batch-based to real-time event processing, a completely different journey builder paradigm, and the replacement of SFMC's SQL-based Data Extension model with Braze's profile-and-event architecture.

Done well, the migration takes eight to sixteen weeks and results in marketing teams that launch campaigns faster, operate with less technical overhead, and personalise at a level SFMC's batch processing cannot match. Done without proper planning, it results in broken journeys, deliverability damage, and data loss that takes months to recover from.

This guide covers exactly what to expect at every stage — the data architecture differences you must understand before you start, the six migration phases, what transfers and what needs rebuilding, and the complete checklist your team needs to execute the migration without campaign downtime.

Why Teams Migrate from SFMC to Braze

The drivers are consistent across the enterprise brands that make this switch. Marketing teams report that SFMC requires filing developer tickets for tasks that should take minutes, that SQL knowledge is a prerequisite for basic audience building, that every new campaign idea takes weeks instead of days, and that the operational overhead of managing the platform has grown to the point where it is consuming more resources than the campaigns themselves.

Braze's architecture is fundamentally different. It was built for the way modern marketing teams actually work — event-driven, real-time, with a marketer-friendly Canvas Flow builder that does not require SQL to segment audiences or build complex journeys. The tradeoff is that SFMC's native Salesforce CRM integration and Advertising Studio cannot be natively replicated in Braze without third-party tooling.

The most commonly cited migration drivers include faster campaign execution, lower total cost of ownership, real-time personalisation that SFMC's batch architecture cannot deliver, leaner team operations without SQL dependency, and better mobile engagement capabilities including push notifications, in-app messaging, and Content Cards.

Braze itself documents that brands can send their first campaign within six weeks of starting migration — a timeline that reflects a Minimum Viable Product approach of migrating essentials first rather than attempting a complete lift-and-shift of the entire SFMC environment at once.

The Most Important Difference: Data Architecture

Before planning a single migration task, your team must understand this architectural difference — it shapes every decision about how to structure data in Braze and how to recreate SFMC logic.

SFMC's architecture is relational and SQL-based. Customer data lives in Data Extensions — database tables that you query using SQL. Segmentation is built by writing SQL queries against these tables. Dynamic content in emails uses AMPscript to pull values from Data Extensions. Journeys are triggered by entry conditions built on Data Extension membership. Everything assumes a structured, table-based data model.

Braze's architecture is profile-and-event-based. Every user has a Braze profile — a collection of attributes (key-value pairs) and a history of events (actions the user has taken). Segmentation is built through a visual audience filter builder without SQL. Dynamic content uses Liquid logic to pull values from user attributes and event properties. Canvas journeys are triggered by events — real things users do — rather than by membership in a database table.

The practical consequence is that you cannot simply export SFMC Data Extensions and import them into Braze. You need to decide which SFMC attributes map to Braze user attributes, which Data Extension queries should become Braze segments, and how your data pipeline will keep Braze user profiles up to date in real time. This data architecture planning is the most important pre-migration task and the most commonly underestimated.

A modern SFMC-to-Braze migration typically involves a Customer Data Platform or data warehouse — Snowflake, BigQuery, or Databricks — as the central data layer, with Braze receiving real-time event streams and profile updates through its API and native integrations. This composable architecture replaces SFMC's all-in-one data model with a more modern separation of data storage from campaign execution.

Phase 1: Discovery and Audit (Weeks 1–2)

The discovery phase establishes exactly what you have in SFMC and what it will become in Braze. Skip this and you will discover gaps mid-migration when they are hardest to fix.

Catalogue your SFMC environment: List every active Journey Builder journey — document the entry condition, the number of steps, branching logic, exit conditions, and the channels used. List every active Data Extension and note which ones power journey entries, segmentation, and personalisation. List every email template including those using AMPscript for dynamic content. List every triggered send and automation activity. List every integration — CRM sync, data warehouse connections, third-party tools connected to SFMC.

Identify what to migrate versus what to retire: Not every SFMC asset deserves to move to Braze. Some journeys may be outdated, some templates may be low-performing, and some Data Extensions may contain stale data no longer relevant to your current strategy. This is your opportunity to migrate forward rather than lift-and-shift — rebuilding selectively rather than replicating every aspect of your SFMC environment regardless of whether it was working.

Map your data model: For every SFMC Data Extension field that you need in Braze, decide whether it becomes a Braze user attribute, an event property, or lives in your data warehouse and is queried when needed. Document the mapping in a spreadsheet that your data engineering team can use to build the ingestion pipeline.

Audit your email sender reputation: Pull your SFMC deliverability metrics — bounce rates, spam complaint rates, and engagement rates by audience segment. Your sender reputation does not transfer from SFMC to Braze. Understanding your current metrics helps you plan the IP warm-up correctly.

Phase 2: Braze Environment Setup (Weeks 2–4)

Set up the foundational Braze environment before any data or campaigns are migrated. Getting this right from the start prevents architectural debt that is expensive to fix later.

Configure Braze workspaces: Decide how to structure your Braze workspaces — whether by brand, region, or product line. SFMC's Business Units map conceptually to Braze workspaces but with different implications for data isolation and user access.

Define your user identifier strategy: Decide what external ID you will use to identify users in Braze. This is typically the same user identifier used in your CRM and data warehouse — a customer ID or hashed email. Consistency across systems is essential for accurate profile matching and attribution.

Set up your data ingestion pipeline: Configure the mechanism by which user attributes and events flow from your data sources into Braze in real time. This typically involves Braze's REST API for profile updates and the Braze SDK for mobile and web event tracking. If you are using a CDP like Segment or mParticle, configure the Braze destination connector. If you are using a data warehouse activation tool like Hightouch or Census, set up the Braze connection.

Configure email sending domains: Add your sending domain to Braze, set up SPF and DKIM DNS records, and configure your Braze dedicated IP addresses. If you are migrating email sending from SFMC, you will use existing IPs that need warming on Braze's infrastructure — plan the warm-up before your first email send.

Set up subscription groups: Braze manages email and SMS opt-in through subscription groups. Map your SFMC email preferences and subscription statuses to Braze subscription groups. Consent data must transfer cleanly — emailing users who unsubscribed in SFMC from Braze is both a deliverability risk and a legal compliance issue.

Phase 3: Data Migration (Weeks 3–6)

Data migration is the technical foundation of the entire project. The goal is to populate Braze user profiles with the attributes and historical events needed to power segmentation and personalisation before any journeys go live.

Migrate user profiles and consent data: Export your SFMC All Subscribers list including subscription status, opted-out contacts, and bounced addresses. Import into Braze through the Users Track API or bulk import — mapping SFMC attributes to Braze user attributes according to your data mapping document. Suppressed and unsubscribed contacts must be imported before any email sends — email a suppressed SFMC contact from Braze and you create deliverability and compliance problems immediately.

Migrate engagement history: While full historical engagement data does not transfer natively, you can import key engagement signals — last open date, last click date, purchase history, and lifecycle stage — as Braze user attributes. This enables segmentation from day one rather than waiting for Braze to accumulate enough fresh data for meaningful audience filtering.

Validate data integrity: After the initial import, spot-check a sample of user profiles in Braze against your SFMC records. Verify that key attributes — email address, subscription status, custom fields — transferred correctly. Check that unsubscribed contacts are marked as opted out in Braze. Confirm that your data ingestion pipeline is flowing live events correctly by triggering test events and verifying they appear on Braze profiles in real time.

Phase 4: Journey and Template Migration (Weeks 4–10)

This is the largest body of work and the stage where the architectural differences between SFMC and Braze require the most careful thinking.

The journey migration principle: Do not attempt a direct lift-and-shift of SFMC journeys into Braze Canvas. The two builders work differently — SFMC journeys are triggered by Data Extension entry conditions and SQL-based segments, while Braze Canvas journeys are triggered by real-time events and audience membership. Recreating SFMC logic in Braze requires rethinking each journey in terms of Braze's event-driven architecture.

Priority journeys to migrate first: Start with your highest-revenue journeys — welcome series, abandoned cart, post-purchase — and get them live on Braze as your MVP. These are the journeys you cannot afford to have down during migration, and getting them working early in Braze reduces risk if the timeline extends.

Rebuilding SFMC journeys as Braze Canvas flows:

• SFMC Journey Builder entry conditions (Data Extension membership) → Braze Canvas entry based on a segment filter or a trigger event
• SFMC Wait activities → Braze time delay steps
• SFMC Decision Splits (based on Data Extension field values) → Braze Audience Paths (based on user attribute values)
• SFMC Engagement Splits (opened/clicked) → Braze Action Paths (performed/did not perform an action within a time window)
• SFMC Random Splits (for A/B testing) → Braze Experiment Steps

Email template migration: SFMC email templates using AMPscript dynamic content must be rebuilt in Braze using Liquid logic. AMPscript and Liquid are both server-side personalisation languages but with different syntax. Every %%=AttributeValue("fieldname")=%% in AMPscript becomes {{ user.first_name }} or equivalent Liquid in Braze. For complex AMPscript logic — conditional blocks, data lookups, date formatting — each must be rewritten in Liquid.

HTML templates without AMPscript can be imported into Braze's HTML email editor with minimal adjustment. However, rebuilding templates natively in Braze's drag-and-drop editor is recommended for templates that will be used long-term — it ensures compatibility with Braze's dynamic content blocks and preview rendering.

Triggered sends and API-triggered campaigns: SFMC triggered sends — emails initiated by external system events — map to Braze API-triggered campaigns. Identify every SFMC triggered send, document the API call that initiates it, and rebuild it as a Braze API-triggered campaign with equivalent personalisation attributes passed in the API request body.

Phase 5: Testing and Validation (Weeks 8–12)

No Braze journey should go live without thorough testing. This phase is not optional — it is the difference between a successful migration and one that surfaces problems in production.

Canvas testing: Activate each Canvas in test mode before setting it live. Braze's Canvas preview and test send functionality allows you to walk through the journey logic for a test user profile and verify that branching logic, personalisation, and timing work as intended. For each Canvas, confirm the entry trigger fires correctly, decision splits route users to the correct branch, personalisation tokens resolve to the correct values, and all channel sends (email, push, SMS) trigger as expected.

Suppression list validation: Before any email send, verify that all opted-out, bounced, and globally suppressed users from SFMC are correctly suppressed in Braze. Run a suppression audit — select a sample of known unsubscribed SFMC contacts and confirm they are marked as opted out in Braze's subscription groups.

Integration validation: Confirm that every upstream and downstream integration is working correctly in Braze. Data flowing from your data warehouse or CDP should be updating Braze profiles accurately. Downstream integrations — analytics tools, data warehouse event exports, CRM sync — should be receiving Braze events correctly. Braze's Currents event streaming product is the mechanism for exporting engagement data to downstream tools — confirm it is configured and flowing before go-live.

Deliverability pre-flight: Before your first real email send, use Braze's inbox preview tool to verify email rendering across Gmail, Outlook, Apple Mail, and mobile clients. Check all unsubscribe links, confirm your sending domain authentication is verified in Braze, and send test emails from your dedicated IPs to seed accounts at major inbox providers.

Phase 6: IP Warm-Up and Go-Live (Weeks 10–16)

IP warm-up is mandatory. Even if you have an excellent sender reputation on SFMC, that reputation is tied to SFMC's sending infrastructure. Braze uses different dedicated IPs and sending infrastructure. Inbox providers evaluate your reputation fresh from the first email sent through Braze.

Warm-up plan structure:

• Week 1: Send to your highest-engagement segment only — users who have opened an email in the last 30 days. Keep daily volume modest (5,000–10,000 sends per IP depending on your list size).
• Week 2: Expand to 60-day active contacts. Begin activating welcome series and abandoned cart journeys.
• Week 3: Expand to 90-day active contacts. Activate remaining lifecycle journeys.
• Week 4 and beyond: Gradually expand to your full active list, watching deliverability metrics weekly.

Throughout the warm-up, monitor bounce rates (keep below 2%), spam complaint rates (keep below 0.08%), and inbox placement using a third-party deliverability tool or Braze's built-in email performance dashboard.

Run SFMC and Braze in parallel during the warm-up period. SFMC remains live for contacts not yet migrated to Braze sending. Define a clear cutover date for each journey — the date when SFMC suppresses that journey and Braze takes over completely.

The Complete SFMC to Braze Migration Checklist

Discovery & Planning

• Catalogue all active SFMC journeys with entry conditions, steps, channels, and exit criteria
• Audit all Data Extensions — identify which are active and which can be retired
• Document all AMPscript templates — flag those requiring Liquid rewrite
• Map SFMC Data Extension fields to Braze user attributes
• Identify all SFMC integrations (CRM, data warehouse, third parties)
• Pull deliverability metrics — bounce rate, complaint rate, engagement by segment
• Define Braze workspace structure and user identifier strategy

Data Architecture

• Design data ingestion pipeline (API, SDK, CDP, or warehouse activation)
• Map subscription statuses and consent flags from SFMC to Braze subscription groups
• Document AMPscript to Liquid conversion for all dynamic content templates
• Plan historical data import — which attributes to seed into Braze profiles on day one

Braze Environment Setup

• Configure Braze workspaces
• Set up sending domain — SPF, DKIM, DMARC DNS records
• Configure dedicated IPs and warm-up schedule
• Set up subscription groups matching SFMC preference structure
• Configure Braze Currents for downstream data export

Data Migration

• Import all subscribers with correct subscription statuses
• Import suppressed, unsubscribed, and bounced contacts as opted out
• Import historical engagement attributes (last open, last purchase, lifecycle stage)
• Validate sample profiles in Braze against SFMC records
• Confirm live data pipeline is flowing events to Braze correctly

Journey & Template Migration

• Rebuild priority journeys in Braze Canvas (welcome, abandoned cart, post-purchase)
• Rebuild remaining journeys in Canvas — rewritten for Braze event-driven architecture
• Convert AMPscript templates to Liquid in Braze email editor
• Rebuild or import all email templates — validated for mobile rendering
• Rebuild API-triggered campaigns for all SFMC triggered sends
• Set all Canvas flows to draft/paused — nothing sends until testing is complete

Testing

• Test each Canvas using Braze test mode — walk through all branch paths
• Verify suppression list accuracy — spot-check known unsubscribed SFMC contacts
• Validate all personalisation tokens resolve correctly across test profiles
• Test all unsubscribe and preference centre links
• Validate downstream integrations — Currents, analytics, CRM sync
• Send test emails — check rendering across Gmail, Outlook, Apple Mail, mobile
• Run suppression audit before first live send

IP Warm-Up & Go-Live

• Execute warm-up plan — starting with highest-engagement contacts
• Monitor bounce rate (target below 2%) and complaint rate (target below 0.08%)
• Activate journeys progressively — not all simultaneously
• Define SFMC journey pause dates — when each journey stops sending from SFMC
• Complete cutover — SFMC journeys paused, Braze journeys fully live
• Decommission SFMC (on contract end date)

How Long Does an SFMC to Braze Migration Take?

The migration takes 30 to 180 days depending on the size and complexity of the SFMC environment. The most accurate way to estimate your timeline is to count the number of active journeys, the number of email templates requiring AMPscript-to-Liquid conversion, and the complexity of the data ingestion architecture.

The MVP approach — migrating your five to ten highest-priority journeys first, getting them live and tested, then migrating the remaining journeys in subsequent phases — is the most reliable method for large migrations. It reduces risk, generates early wins that justify continued investment, and avoids the scenario where a massive migration surfaces problems at go-live with no runway to fix them.

Common Mistakes to Avoid

Attempting a full lift-and-shift. Copying SFMC journeys directly into Braze without rethinking the architecture produces journeys that do not use Braze's event-driven strengths and often require immediate rework after launch.

Not migrating suppression data before the first send. Emailing unsubscribed or bounced contacts from Braze is both a deliverability catastrophe and a legal risk. Suppression data must be the first thing migrated — before any test sends.

Skipping IP warm-up. The most common cause of deliverability problems after SFMC-to-Braze migrations is skipping or rushing the IP warm-up. The reputation reset is real. Plan for it.

Underestimating AMPscript-to-Liquid conversion. Complex AMPscript — especially data lookups, nested conditionals, and date arithmetic — takes time to rewrite correctly in Liquid. Budget this as a significant technical task, not a quick find-and-replace.

Not running SFMC in parallel long enough. Cut SFMC off too early and you lose the safety net. Run both platforms in parallel until every Braze journey is live, tested, and delivering cleanly.

Conclusion

Migrating from SFMC to Braze is a significant undertaking — but it is one that consistently delivers meaningful results for teams that execute it well. Faster campaign launches, leaner operations, real-time personalisation, and a more modern architecture for AI-driven engagement are all achievable outcomes of a well-planned migration.

The key is preparation. Understand the data architecture differences before you start. Audit your SFMC environment thoroughly. Migrate your suppression data first. Use the MVP approach. Warm up your IPs properly. And work with a partner certified on both platforms who has done this before.

Work With a Certified Migration Partner

Rackwave is a certified implementation and account management partner for both Salesforce Marketing Cloud and Braze. We have managed SFMC-to-Braze migrations for enterprise clients across the USA, UK, Canada, Australia, and Singapore — delivering clean cutovers without campaign downtime or data loss.

Whether you need a fully managed migration, a data architecture review, or ongoing Braze account management after go-live — our certified team delivers it.

Explore Our Braze Migration Services →

Frequently Asked Questions

How long does an SFMC to Braze migration take?
Between eight and twenty weeks for most enterprise deployments. Small accounts with under ten active journeys can complete in six to eight weeks. Large enterprises with thirty-plus journeys, complex data architectures, and multiple business units should plan for twelve to twenty weeks. A phased MVP approach — migrating priority journeys first — is the most reliable method for reducing risk on large migrations.

What is the biggest technical difference between SFMC and Braze?
The fundamental difference is data architecture. SFMC is relational and SQL-based — data lives in Data Extensions and is queried using SQL. Braze is profile-and-event-based — data lives in user profiles as attributes, and journeys are triggered by real-time events rather than database table membership. You cannot copy SFMC Data Extension logic directly into Braze without rethinking how data is structured.

Do SFMC email templates transfer to Braze?
HTML templates without AMPscript can be imported into Braze's HTML editor with minor adjustment. Templates using AMPscript for dynamic content must have their AMPscript rewritten as Liquid — Braze's personalisation language. Complex AMPscript with nested conditionals, data lookups, and date arithmetic can take significant time to convert correctly.

What happens to SFMC suppression lists during migration?
All suppressed, unsubscribed, and bounced contacts from SFMC must be imported into Braze as opted-out profiles before any email is sent from Braze. This is a legal compliance requirement (GDPR, CAN-SPAM, CASL) as well as a deliverability necessity. Suppression data must be the first thing migrated — not the last.

Do I need to warm up my IP addresses when migrating to Braze?
Yes — without exception. Even with an excellent sender reputation on SFMC, Braze uses different sending infrastructure. Gmail, Outlook, and Yahoo assess your reputation fresh from Braze's IPs. Start with your highest-engagement contacts, send modest volumes in week one, and expand gradually over three to four weeks while monitoring bounce rates and spam complaints.

Can I run SFMC and Braze simultaneously during migration?
Yes — and this is strongly recommended. Running both platforms in parallel during the migration allows you to test Braze journeys thoroughly before cutting over, and provides a safety net if issues arise. Define a clear cutover date for each journey — the date when SFMC pauses that journey and Braze takes over.

What is the MVP approach to SFMC migration?
The MVP (Minimum Viable Product) approach means migrating your five to ten highest-priority journeys first — typically welcome series, abandoned cart, and post-purchase — getting them live and stable on Braze, then migrating remaining journeys in subsequent phases. This reduces risk, generates early revenue validation, and avoids the single-point-of-failure risk of attempting a full lift-and-shift simultaneously.

How does AMPscript convert to Liquid in Braze?
AMPscript and Liquid are both server-side personalisation languages but with different syntax. Basic attribute lookups — %%=AttributeValue("FIRSTNAME")=%% in AMPscript — become {{ ${first_name} }} in Braze Liquid. Conditional blocks, loops, and data extension lookups require more substantial rewriting. A certified Braze partner with SFMC expertise can manage this conversion efficiently.

Will my Salesforce CRM integration work in Braze like it does in SFMC?
Not natively. SFMC's Marketing Cloud Connect provides a native bidirectional sync with Salesforce CRM that Braze cannot replicate without third-party tooling. In Braze, Salesforce CRM integration is typically handled through a CDP (Segment, mParticle), a data warehouse activation tool (Hightouch, Census), or a custom API integration. Plan this integration architecture during the discovery phase — it affects your data model design.

Does Rackwave manage SFMC to Braze migrations?
Yes. Rackwave is a certified implementation partner for both Salesforce Marketing Cloud and Braze. We manage end-to-end SFMC-to-Braze migrations for enterprise clients across the USA, UK, Canada, Australia, and Singapore — including data architecture design, journey migration, template conversion, IP warm-up, and post-migration account management.