On 20 October 2026, Salesforce agreed to acquire Braze for approximately $5.66 billion in enterprise value, or $47.50 per share in cash. Once the transaction closes, Salesforce will own two customer journey orchestration engines: Journey Builder within Marketing Cloud, and Braze Canvas. Salesforce has stated that Marketing Cloud will be Braze’s primary home inside Customer 360. It has not published a combined product roadmap, pricing or packaging, and it has not said how Braze will sit alongside Marketing Cloud’s existing journey tooling. The transaction is expected to close in Salesforce’s fiscal 2028, which begins in February 2027.

For the approximately 2,770 organisations running Braze, and for firms evaluating either platform, the immediate question is typically framed as a product choice: which engine survives, and on what terms. This analysis takes a different position. Orchestration engines are increasingly sold as components of larger suites, and the component a firm licenses today may be repackaged, repriced or merged within a single contract cycle. The decision that retains its value is where journey state, the customer profile and decisioning inputs reside. Where those assets are held in the firm’s own warehouse, the engine becomes replaceable. Where they are held inside the engine, the firm’s position depends on the vendor’s roadmap.

The sections below define the components of customer journey orchestration, compare three data placement patterns using Braze’s own documented integration options, estimate switching cost under each pattern, and set out the conditions under which suite-native orchestration remains the appropriate choice.

Market context: orchestration consolidating into suites

The Braze transaction is the most visible example of a broader pattern. Standalone customer engagement platforms are being absorbed into, or rebuilt as, layers of larger customer experience suites.

Salesforce describes the rationale in terms of its stack rather than Braze’s product. Braze is to be connected to Data 360, Customer 360 and Agentforce, with the stated aim of tying marketing messages to commerce, sales and service data. Braze’s chief executive has said the company will continue to build under the Braze name. Both companies describe their approach as open and composable, which is material for Braze customers whose customer data is held outside Salesforce. That commitment has not yet been tested through integration.

Adobe has moved in a comparable direction. At Adobe Summit in April 2026, the company replaced the Experience Cloud umbrella with CX Enterprise and introduced CX Enterprise Coworker, a persistent agent layer that coordinates Adobe and third-party agents across audience creation, journey orchestration, experimentation and content optimisation. Journey orchestration in that model becomes one capability among several that an agent invokes, rather than a product a marketer operates directly. Adobe’s own research, published in March 2026, found that 75% of organisations cite data integration and quality as their top challenge with AI.

The common thread is that the orchestration engine is becoming a feature of the suite. Its branding, packaging and pricing are now set by the suite’s strategy rather than by the engine’s own product roadmap. For buyers, this changes what counts as a durable decision.

Components of customer journey orchestration

Customer journey orchestration is frequently treated as a single capability. In practice it comprises five components with different portability characteristics.

1. Event intake. Behavioural and transactional signals that trigger journey entry or progression: a purchase, an app session, a lapsed payment. These typically originate in source systems, SDKs or a streaming pipeline, and are generally portable because the firm controls the source.
2. Profile and eligibility. The attributes and segment memberships used to decide whether a customer enters a journey and which branch they follow. This is usually the largest body of data and the one most often copied into the engine.
3. Journey state. The record of where each customer is in each journey: entry timestamp, current step, steps completed, exit reason, holdout assignment, and the suppression and frequency-cap counters that govern future sends. This is the component most often overlooked.
4. Decisioning. The logic or model that selects the offer, channel, content and timing for each customer. In current platforms this increasingly means a vendor model, such as BrazeAI, trained on the firm’s engagement history.
5. Channel delivery. The execution of the send across email, SMS, push, in-app and messaging channels such as WhatsApp.

Channel delivery and the journey canvas are the visible parts of the product, and they are what evaluation processes tend to compare. They are also the parts most easily replicated by another engine. Profile data, journey state and decisioning training data accumulate over time, are specific to the firm, and are the parts that are expensive to reconstruct. The architecture question is therefore which of these three accumulating assets sit inside the engine, and which sit in infrastructure the firm controls.

Data placement patterns

Braze’s documentation provides a useful reference because it supports all three patterns that are common across the market. Comparable options exist in other engagement platforms under different names.

Pattern 1: copied into the engine. Braze Cloud Data Ingestion reads a table or view in Snowflake, Redshift, BigQuery, Databricks or Microsoft Fabric and syncs rows into Braze user profiles. Syncs are incremental: Braze processes rows whose UPDATED_AT value is later than the last synced value. After the sync, Braze holds a copy of the profile data, and segmentation, eligibility and personalisation run against that copy. The warehouse remains the source, but the operational profile is the engine’s.

Pattern 2: queried in place. Braze connected sources run queries directly against the warehouse to build segments through CDI Segment Extensions, and Braze does not store the underlying data. The firm pays the warehouse compute cost of those queries, and classic or pro SQL warehouses can add a warm-up delay of two to five minutes. A related option, zero-copy personalisation, passes warehouse fields into a Canvas as entry properties that are not persisted on Braze user profiles. That option is limited to existing Braze users identified by external ID or user alias.

Pattern 3: warehouse-held state, engine as executor. In this pattern the firm treats the warehouse as the system of record for all three accumulating assets. Profile and eligibility are computed in the warehouse. Journey state is reconstructed in the warehouse from engine event exports, using Braze Currents to stream send, delivery, open, click and Canvas step events out of the platform. Suppression and frequency rules are defined against that warehouse history. The engine receives instructions and returns events; it does not hold anything the firm cannot rebuild.

The distinction that matters is between inputs and state. Patterns 1 and 2 differ in where profile inputs are read from, but in both cases Canvas step progression, frequency-cap counters and decisioning history are generated and held inside the engine. Zero-copy access to inputs does not make journey state portable. Only Pattern 3 places journey state under the firm’s control, and it does so through deliberate event export and modelling rather than through a platform setting.

Switching cost by placement pattern

Switching cost in orchestration is usually estimated as the effort to rebuild journeys in a new canvas. That effort is real but bounded: journeys can be documented and rebuilt. The larger cost is the loss of accumulated state, which cannot be rebuilt from documentation.

Under Pattern 1, a migration requires re-establishing the profile sync to the new engine, which is generally straightforward because the warehouse remains the source. Journey state is lost unless it has been exported. Customers mid-journey must be re-entered, and suppression and frequency-cap history restarts from zero, which in regulated sectors such as financial services can create contact-policy breaches in the first weeks after cutover. Vendor decisioning models restart without training history.

Under Pattern 2, profile inputs carry over with less effort because they were never copied. The state and decisioning losses are the same as in Pattern 1, because those assets were generated inside the engine regardless of where inputs were read from.

Under Pattern 3, the new engine is pointed at the same warehouse-held profile, eligibility logic and state history. Mid-journey customers can be re-entered at the correct step, contact-policy history is preserved, and decisioning features remain available to whichever model is used next. The residual cost is rebuilding journey logic and channel configuration.

The illustrative comparison below, which is not based on measured data, shows the shape of the difference: migration effort is broadly similar across patterns for journey logic, but diverges sharply for state and decisioning history.

For Braze customers, the pending transaction makes this calculation current. The firm does not need to assume Braze will be discontinued or repriced to benefit from Pattern 3; it needs only to recognise that the terms of the next renewal will be set by a different parent company with a second orchestration engine in its portfolio.

Where suite-native orchestration remains appropriate

Warehouse-held state carries real costs, and it is not the right design for every organisation.

Firms that run their service, sales and marketing estate on a single suite, and expect to remain on it, obtain integration benefits from suite-native orchestration that a warehouse-centred design has to engineer separately. For such firms, Marketing Cloud with Data 360, or the Adobe stack with Real-Time CDP, may offer a lower total cost than maintaining a parallel state model.

Use cases that depend on sub-second response, such as in-app messages triggered by in-session behaviour, are typically better served by profile and state held in the engine’s own low-latency store. A warehouse round trip is not suitable for these decisions, and Pattern 3 deployments generally retain an engine-side profile for this subset of journeys.

Pattern 3 also requires data engineering capacity: event export pipelines, a modelled journey state table, and ownership of contact-policy logic. Organisations without a functioning warehouse practice will find that the engine’s own data model is more reliable than a warehouse model they cannot maintain. In those cases, the practical step is to export engagement events to the warehouse for history and auditability, without moving operational state.

Conclusion

The Salesforce–Braze transaction does not change how journey orchestration works. It changes who sets the commercial terms for a widely used engine, and it shows that engines are now components whose packaging follows suite strategy. Under those conditions, the selection of an engine is a decision with a horizon of one contract cycle, while the placement of profile, journey state and decisioning data is a decision with a horizon of the customer relationship itself.

The practical first step is an inventory: for each live journey, record where its eligibility logic is computed, where its state is held, and whether the engine’s event history is being exported to the warehouse today. Journeys whose state exists only inside the engine represent the firm’s switching exposure. For Braze customers, the period before the transaction closes is the window to establish event export and to add state and history export provisions to the next renewal, while the current contract terms still apply.

Next step

The placement decision sits within a wider question of which marketing automation capabilities the firm should own and which it should license. Datawhistl’s capability-led planning guide to marketing automation sets out that decomposition and can be used to assess journey orchestration alongside the adjacent capabilities it depends on.