Airship to Braze Migration Guide

Airship built its reputation on push notifications before most platforms treated mobile as a first-class channel. That heritage is also its constraint.

Teams moving from Airship to Braze have typically built a strong mobile engagement program and are now running into the limits of a platform that was architected around push-first thinking. They need email integrated into the same behavioral event stream as push. They need in-app messaging that responds to the same SDK events as their notification logic. They need Connected Content personalization that makes live API calls at send time rather than pulling from scheduled attribute syncs. They need a data infrastructure — Currents, cloud data ingestion, warehouse integration — that Airship's export capabilities don't match.

At Propel, we've managed Airship migrations for consumer app brands. The migration has a specific technical character: you're not just moving between platforms, you're upgrading from a push-centric model to a genuinely unified cross-channel engagement model. This guide covers what that upgrade involves.

TL;DR

• Airship is push-native. Braze is channel-native. Airship's architecture prioritizes mobile push and in-app notifications. Braze's Canvas Flow treats email, push, in-app, SMS, and Content Cards as equally native channels in a unified event stream.
• Airship Journeys and Braze Canvas Flow are different orchestration models. Airship's Journey builder is optimized for mobile-first sequences. Braze's Canvas Flow is a cross-channel orchestration engine. Every Journey must be rebuilt as a Canvas.
• SDK migration requires a coordinated app release. Airship's SDK and Braze's SDK cannot share the same push registration — the transition requires a planned release with careful push opt-in management to avoid losing notification permissions.
• Braze's data infrastructure depth is the primary upgrade. Currents, cloud data ingestion, and the breadth of native integrations represent a meaningful step up from Airship's data export capabilities.
• Propel is a certified Braze partner with consumer app migration experience across brands making this exact transition.

Why Teams Move From Airship to Braze

Email in the same event stream. Airship's email capabilities exist, but email and push in Airship do not share the same real-time event stream with the same Canvas logic depth that Braze provides. Teams running push in Airship and email in a separate tool are managing two systems, two segment definitions, two attribution dashboards, and two sets of frequency rules — for a single user's lifecycle. Braze unifies this in a way that produces omnichannel orchestration that is genuinely cross-channel rather than channel-parallel.

Connected Content. Airship's personalization is attribute-based — user properties injected into messages. Braze's Connected Content makes a live API call at send time. For brands whose messaging needs to reflect real-time product data — current recommendations, live pricing, dynamic content — the Connected Content model is structurally different from what Airship can support. This is particularly relevant for customer retention in media and social platforms where content personalization is the primary engagement lever.

Data warehouse integration. Braze Currents streams every engagement event to your warehouse in real time. Combined with cloud data ingestion, the bidirectional data flow between Braze and your warehouse enables the analytics infrastructure that growing programs need. This matters for DTC revenue and LTV attribution and for powering the kind of behavioral segmentation that requires warehouse-quality data as input.

Predictive capabilities. Braze's Predictive Churn and Predictive Purchases models run natively on your Custom Event data. For teams trying to identify users who are about to churn and act on that signal before it's too late, Braze's native predictive models eliminate the need for an external ML pipeline or a data science team maintaining a separate churn model.

The Architecture Difference: Airship vs. Braze

Airship's model: Channel-centric and mobile-native. Users are identified by named users or channel IDs (device-specific identifiers). Attributes are user-level properties. Events trigger Journey entry or message send. The data model is optimized for mobile channels — push, in-app notifications, message centers. Email and SMS are present but architecturally secondary to mobile channels.

Braze's model: Profile-centric and channel-agnostic. Every user has a unified profile with Custom Attributes and Custom Events. Canvases trigger off Custom Events from any source — SDK, API, data warehouse. Every channel — email, push, in-app, SMS, Content Cards — is a native Canvas component with equal access to the same event data. There is no channel-first bias in how the data model works.

The migration consequence: Airship's named user identity maps to Braze's external_id. Airship's user attributes map to Braze Custom Attributes. Airship's Events map to Braze Custom Events. Airship's channel IDs — device-specific push registration tokens — are replaced by Braze's device-level push registration, which happens automatically when the Braze SDK is initialized on a device. Every Journey must be rebuilt as a Canvas.

What Transfers and What Doesn't

Transfers With Mapping ✅

Named user identity. Airship's named users map to Braze's external_id. If your app uses Airship's anonymous channel IDs for pre-login users, map these to Braze's alias system for anonymous user tracking.

User attributes → Custom Attributes. Airship's user attributes map to Braze Custom Attributes. Document every attribute in active use across Journeys and templates. Use this as an opportunity to clean up attributes that accumulated during Airship's operation but are no longer referenced in active logic — they create noise in Braze.

Suppression and opt-out data. Email unsubscribes and SMS opt-outs transfer — they move first. Push opt-out status is managed at the device level via APNs/FCM — it is not a data import, it is a user permission that re-establishes itself when the Braze SDK initializes and the user's OS-level push permission is read. Managing the push permission transition is the most delicate part of the Airship SDK migration.

Must Be Rebuilt 🔄

Every Journey becomes a Canvas. Airship Journeys cannot be imported into Braze Canvas Flow. Rebuild in priority order: onboarding → activation → retention → re-engagement. Use the Braze onboarding Canvas template as the structural starting point. For re-engagement, the win-back campaign blueprint covers the Canvas architecture.

SDK instrumentation. The Airship SDK must be replaced with the Braze SDK. This is an app release — it requires engineering time and coordination with your mobile release schedule. Every Custom Event in your Braze schema must be validated as firing correctly with the right properties before any Canvas is built.

Templates. Airship's template and personalization syntax is proprietary. Every template must be rebuilt in Braze's composer with Liquid personalization. Run the pre-send email QA checklist on every rebuilt template.

Segments. Airship's segment definitions must be recreated in Braze's builder. Use the lifecycle stage segmentation playbook to rethink segment taxonomy in Braze's event-driven model.

Lost or Replaced ❎

Airship's Message Center. Airship's Message Center (inbox-style in-app messaging) has a direct Braze equivalent: Content Cards. Content Cards display as a persistent in-app feed and are managed as Canvas components. The user experience is comparable; the implementation requires Canvas and SDK setup specific to Content Cards.

Airship's predictive send time. Braze's Intelligent Timing serves the same function. Requires 30+ days of engagement data before producing reliable per-user timing recommendations.

Historical engagement data. Airship performance data stays in Airship. Set up your retention metrics dashboard template in your analytics stack and connect Braze Currents before the first Canvas goes live.

The Push Transition: Managing Notification Permissions

This is the highest-stakes technical moment in an Airship to Braze migration and deserves specific attention.

Push notification permissions in iOS and Android are granted by the user to the app, not to the push platform. When a user grants push permission on iOS, APNs issues a device token to that app. That token is what Airship holds — it cannot be transferred to Braze.

When your app releases with the Braze SDK, Braze requests a fresh device token from APNs/FCM at SDK initialization. For users who have already granted push permission, this happens automatically and silently — the Braze SDK receives the new token, and push capability is restored in Braze without any user action. For users who have explicitly denied push permission, no action by you or by Braze can restore it — their permission status must be respected.

The practical consequence: your push-opted-in user base will be fully accessible in Braze after the SDK release, assuming your app has a standard push permission flow. What changes is the token — Airship's token is deprecated, Braze's token is issued fresh. There is no gap in push capability for users who have granted permission.

For consumer app retention programs where push notification opt-in rate is a primary metric, plan a re-permission campaign for lapsed users as part of the migration launch — not before, because a re-permission campaign from Airship while Braze is being set up creates coordination complexity.

Migration Checklist: Airship to Braze

Pre-Migration Audit

• Inventory all active Journeys — channel mix, trigger event, entry volume, 30-day performance.
• Document all user attributes in active use across Journeys, segments, and templates.
• Map Airship event schema to Braze Custom Event schema — identify gaps and additional properties needed.
• Assess SDK release timeline — coordinate with mobile engineering for app release.
• Map Airship suppression states — email unsubscribes, SMS opt-outs — to Braze mechanisms.
• Identify Message Center usage — scope Content Cards implementation.

Data Migration

• Export email unsubscribes — import to Braze as email_subscribe: unsubscribed.
• Export SMS opt-outs — import to Braze SMS Subscription Groups.
• Export active users with all relevant attributes — map to Braze Custom Attributes.
• Segment import into engagement tiers before any Canvas is activated.
• Push opt-in status will re-establish via SDK initialization — do not attempt to import push tokens.

Technical Setup

• Verify sending domain in Braze — DKIM, SPF, DMARC. Reference email deliverability channel health standards.
• Integrate Braze SDK in iOS and Android — validate every Custom Event and property against schema per events and attributes architecture spec.
• Configure APNs and FCM credentials in Braze for push.
• Set up Content Cards if replacing Airship's Message Center.
• Configure Braze Subscription Groups for email and SMS channels.
• Set up Braze Currents for data warehouse integration.

Canvas Rebuild and Go-Live

• Rebuild all Journeys as Braze Canvases — priority order: onboarding, conversion, retention, re-engagement.
• Rebuild all templates — rewrite personalization in Liquid.
• Run end-to-end QA including push send validation with test device tokens.
• Deactivate Airship Journeys as Braze Canvases go live.
• Execute email deliverability warm-up over 4–6 weeks.

Stakeholder Expectations

Lifecycle team: Budget 10–14 weeks for a typical Airship migration with multiple channels and a Journey library of moderate complexity. The Canvas rebuild and SDK validation phases are the primary time investments.

Engineering team: SDK migration is an engineering task requiring a planned mobile app release. Push permission management must be understood and handled correctly — the wrong approach can result in push permission loss for users who granted it. Our events and attributes architecture service manages the technical specification.

Data and analytics teams: Currents integration closes the attribution loop that Airship's export capabilities leave open. Involve your data team in schema design from the start. Our campaign analytics and performance insights service maintains visibility through the transition.

Leadership: Push engagement metrics may fluctuate during the first two weeks as Braze's Intelligent Timing calibrates and the app release propagates across your user base. Set expectations before go-live. Use the customer retention impact calculator to establish the post-migration baseline.

Why Propel for Your Airship to Braze Migration

Propel is a certified Braze partner with consumer app migration experience that includes the specific push permission management and SDK transition planning that Airship migrations require. Our framework covers the full program — schema design, SDK transition, Canvas rebuild, Content Cards implementation, and lifecycle strategy review.

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