Your CRM vendor bought your engagement platform
Salesforce is buying Braze. Before you renew or migrate, decide whether your CRM and engagement platform should share one identity and event model.
If your CRM and your engagement platform now belong to the same vendor, the decision in front of you is a data-model decision, not a contract decision: settle whether the two systems should share one identity model and one event model before you decide whether to renew, merge, or migrate. Salesforce's announcement that it is acquiring Braze answers none of that. It tells you what the vendor intends to build, not what happens to your customer records when two systems that disagree about who a person is end up under one roof.
What the announcement actually says — and what it doesn't
On October 20, 2026, Salesforce announced a definitive agreement to acquire Braze for approximately $5.66 billion in enterprise value, at $47.50 per share in cash. The company said the deal is expected to close in its fiscal year 2028, subject to shareholder and regulatory approval, and that Braze's real-time engagement and AI decisioning capabilities are expected to complement Data 360, Customer 360, Agentforce and Marketing Cloud.
That is a strategy statement, not an architecture. Digiday's October 26 coverage frames the deal as putting marketers at an "ecosystem crossroads," with vendor lock-in and AI-differentiated execution as the open questions. MarTech's analysis is blunter: Salesforce says Braze will complement Marketing Cloud and connect with Data 360 — "that is the company's plan, not yet a demonstrated customer outcome."
So the roadmap that would let you plan a consolidation does not exist yet, in public. What exists is your current stack: a CRM that owns contacts, deals and lifecycle stages, and an engagement platform that owns behavior, journeys and channel delivery. When the vendor's own sales team asks whether you want to consolidate onto one contract this quarter, the honest answer is that you are not being asked a purchasing question. You are being asked a data-model question dressed up as one.
The four questions that decide consolidate or seam
Run these in order. Each answer names an owner, and the owners tell you whether consolidation is safe.
| Question | What "consolidate now" looks like | What "keep the seam" looks like |
|---|---|---|
| 1. Who identifies a customer? | Both systems resolve to one documented key — a stable identifier both sides can match on, not an email address that changes. | The two systems match on different fields, or one relies on anonymous device tokens the CRM has never seen. |
| 2. Which system records behavior? | One platform is the system of record for events; the other consumes a copy. | Both systems record overlapping events today, with different names for the same action. |
| 3. Which system decides the next action? | Journey logic lives in one place; the CRM reads outcomes back. | Journeys trigger from the engagement platform while CRM workflows trigger independently — two engines racing. |
| 4. Which number does the business quote? | One source defines conversion, revenue and lifecycle stage. | Sales reports one figure and marketing reports another for the same period. |
Four clean answers pointing at one owner for each: consolidate, and sequence it properly (below). Mixed answers: keep the seam deliberately, with one documented integration between the two, and revisit when the vendor publishes a real architecture. Mixed answers are not a failure — they are a diagnosis. A forced merge with an unresolved identity model produces duplicate records, inflated audiences and reports nobody trusts, which is the same failure that makes dirty CRM data so expensive long before any acquisition is involved.
Both vendors' documentation describes the same seam
The two companies' own docs are more useful than the press release, because they show where the seam actually lives.
Salesforce's identity resolution documentation works on rulesets: match rules decide which profiles unify (exact match, normalized match on email, phone and address, fuzzy match on first name), and reconciliation rules decide which value wins in a field that can hold only one — Last Updated, Most Frequent, or Source Sequence. The documentation is explicit that reconciliation does not delete or change source data, that published rulesets create unified profiles on a daily cycle afterwards, and — the line worth internalizing — that it is easier to fix a data stream before ingestion than after it.
Braze's documentation describes the same problem from the event side. Ingestion through /users/track is asynchronous: a successful response means the request was received and queued, not that the profile has been updated. Anonymous profiles are created from device tokens and merged into an identified profile when the user is identified — with fields that already exist on the identified profile winning. Braze's merge behavior documentation also spells out what does not transfer, including pre-merge history in surfaces powered by its data warehouse, and duplicate profiles that never merge are not eligible to receive messages.
Put the two documents side by side and the pattern is identical: whoever owns identity reconciliation and event ingestion owns the customer record. The contract you sign decides who invoices you. It does not decide which system's version of a person is true.
Migration sequence: identity, events, reporting, decommission
If you do consolidate, the order is not negotiable. Each stage's output is the next stage's input.
| Stage | What you do | Why it comes here | What you must not do at this stage |
|---|---|---|---|
| 1. Identity | Write the match rules and the reconciliation rule for every contested field before a single record moves. | Every later stage assumes one customer key exists. Salesforce's own guidance puts rule definition ahead of mapping and ingestion. | Bulk-import contacts "to see what happens." You cannot un-guess an identity decision once records are merged. |
| 2. Events | Run both event streams in parallel under one naming convention; confirm the new stream is landing before retiring the old one. | Event history is what journeys, segments and attribution are built on. Asynchronous ingestion means "accepted" is not "arrived." | Cut the legacy stream because the new API returns 200. Verify the profile actually reflects the events. |
| 3. Reporting | Pin every metric the business quotes to one source while both systems still run. | Two systems in dual-run will double-count by default. Reporting decides which numbers survive the migration. | Publish a dashboard from a moving target, then reconcile narratives afterward. |
| 4. Decommission | Export everything that does not transfer — merge history, message archives, fields excluded by merge behavior — before disabling the old system. | Decommissioning is irreversible; the vendor's own docs list which fields and surfaces do not survive a merge. | Delete the old platform as a "cleanup" step. Archiving is cheap; reconstruction is not. |
Teams that reverse stage 1 and stage 2 end up with clean event data attached to the wrong people. Teams that skip stage 3 end up arguing about numbers instead of customers. The sequence is the framework; the specific tool is secondary.
What breaks first
In production, the same four failures surface before anything visibly corrupts:
- Segments built on profiles that haven't finished ingesting. Because ingestion is queued, an audience built right after a data load can be silently incomplete.
- Reconciliation defaults. Last Updated means the loudest system wins, not the truest one. If your CRM is enriched nightly and your engagement platform updates in real time, real time wins every contested field.
- Anonymous-to-identified history. Fields already present on the identified profile are not overwritten, so early behavior recorded under a device token may never appear where you expect it.
- Rule changes on a daily cycle. A correction made to matching rules is not visible immediately; teams read stale unified profiles and conclude the fix failed.
- Duplicate profiles that never merge. They are excluded from messaging, which shows up weeks later as unexplained deliverability loss, not as an error.
None of these require an acquisition to happen. An acquisition simply puts them all in front of the same team in the same quarter — which is why exception lanes and disciplined data hygiene belong in the plan before migration, not after it.
Our stance: consolidate the model, go slow on the contracts
Consolidate the identity and event model first and let the commercial decision follow from it. A single documented key, one owner for behavior, one owner for the next action, one number the business quotes — once those are true, moving to one contract is bookkeeping. Reverse the order and you get a merged stack with two unresolved customer records and a renewal you signed to get there.
Keeping the seam is a legitimate outcome too. If identity cannot be agreed, a deliberate integration with one owner per system beats a migration that guesses — especially while the merged product's roadmap is still a press release. What we would not do is let a vendor's close date become your migration deadline. The transaction closes when regulators and shareholders say so; your data model should be ready long before anyone asks you to sign.
If you are staring at a CRM plus a separate engagement platform and a vendor asking you to choose, our CRM implementation work starts with exactly these four questions — before any tool, contract or import. And if part of the stack you are trying to unify is messaging, our WhatsApp + CRM comparison for Latin America covers the channel side of that decision.
Frequently Asked Questions
Should we consolidate our CRM and engagement platform after an acquisition?
Consolidate the data model before you consolidate the contracts. Answer four questions — who identifies a customer, which system records behavior, which system decides the next action, and which number the business quotes — and only merge when the answers point at one owner for each.
What order should a CRM and engagement platform migration follow?
Identity, then events, then reporting, then decommissioning. Agree on the match rules before any record moves, run both event streams in parallel until the new one is confirmed landing, pin every metric to one source while both systems run, and export what does not transfer before you turn anything off.
When is it better to keep two systems after a vendor merger?
When the two platforms cannot agree on a customer key, or when the merged roadmap is still unpublished. A deliberate seam with one documented integration is cheaper than a migration that guesses at identity — and it stays reversible while the vendor's plan is only a press release.
