Heroku Retired Its Data Bridge Add-On. The 'Smooth' Migration Path Is the Real Warning.

Here's the irony: the Heroku add-on that just got killed is the one that existed specifically to keep data around. Heroku Data Bridge — the storage layer behind Salesforce Privacy Center's legacy Retention Store — stopped being renewable on October 1, 2025. Customers who don't act before their contract runs out don't lose a feature. They lose the data, permanently, per Salesforce's own retention policy. A tool built to satisfy legal data-retention requirements is the one on a vendor-set deletion clock.

Salesforce did offer affected teams a way out, and that's the part worth sitting with. It isn't "no replacement, stitch together your own ETL before the lights go off" — there's an official migration path. But look closely at who designed that path, who's running the clock, and who had zero say in either, and the lesson gets sharper than a simple "the add-on died" story.

What actually happened​

Heroku Data Bridge is not the general-purpose Salesforce-to-Postgres sync tool — that's Heroku Connect, a separate, still-supported product with its own devcenter docs. Data Bridge is narrower: it's the plumbing Privacy Center uses to replicate Salesforce records into Heroku-hosted storage so they can be retained for compliance, encrypted at rest with AES-256, with up to 4TB of purchasable headroom. It's infrastructure for satisfying data-retention law, not for running an app.

The timeline, pieced together from Salesforce's own help documentation and Heroku's blog:

When a Data Bridge contract lapses, Salesforce gives customers exactly three options:

1. Migrate to the new Hyperforce-based Privacy Center using Salesforce's own Migration App (or its "premier partner," Cervello, for complex cases) — the sanctioned path.
2. Convert to a Heroku Direct Account with monthly usage-based billing, to keep the existing data without the Privacy Center wrapper.
3. Do nothing — the subscription lapses and the retained data is permanently deleted per Salesforce's Trust and Compliance documentation.

Option 3 is the one that should stop any compliance-minded team cold. This isn't a deprecated API returning a 410 — it's data your legal or compliance team put there specifically to satisfy a retention obligation, deleted on a timer if nobody runs the migration in time.

A migration path is not the same as not being locked in​

Options 1 and 2 are real, and Salesforce deserves some credit for not just switching Data Bridge off. But notice what a team affected by this retirement actually has to do, even in the "smooth" case:

• Identify every object and retention policy currently living in the legacy store.
• Either stand up the Migration App against Salesforce's new Hyperforce architecture (Salesforce's target platform, Salesforce's schema, Salesforce's timeline), or add a credit card and switch to usage-based billing on a product you didn't choose to run that way.
• Verify retention rules re-apply correctly post-migration, because a retention feature that silently drops records defeats the entire point of having one.
• Do all of this before their contract-end date, not a date your own roadmap picked.

None of that is optional busywork — it's real engineering and compliance-review hours, spent not because your product needed a new capability, but because a vendor decided a bundled add-on was no longer worth maintaining. That's the actual cost of "there's a migration path": you still pay in hours, you still move on someone else's calendar, and you still land on infrastructure someone else designed. A replacement path removes the "abandoned with nothing" horror story; it does not remove the lock-in. It just makes the lock-in polite.

This isn't an isolated incident​

Data Bridge's non-renewal date predates the bigger announcement, but the two are clearly part of the same arc. On February 6, 2026, Heroku SVP Nitin T Bhat wrote in "An Update on Heroku" that the platform is "transitioning to a sustaining engineering model focused on stability, security, reliability, and support" — Salesforce's own words for: no new features, no new enterprise contracts for new customers, existing customers renew as-is. Reporting on the announcement (TechRadar, DevClass) framed it plainly as Salesforce redirecting platform investment toward AI products instead.

A platform in sustaining-engineering mode doesn't kill everything at once. It trims the least-used, least-defensible bundled pieces first — and Data Bridge, a narrow compliance add-on serving a legacy retention model, was an easy first cut. Heroku Connect, the far more widely used Salesforce-Postgres sync product, is still alive today. But it sits inside the exact same maintenance-mode roadmap, with the exact same incentive structure that already retired its narrower sibling. Nothing about "more customers use it" makes an add-on immune once a platform stops investing in net-new development — it just moves it further back in the queue.

A decision framework for bundled integrations​

The generalizable question isn't "should I use Salesforce Privacy Center" — it's "should I depend on any platform's bundled integration for something I can't afford to lose." Run a candidate integration through these before you build on it:

1. Is it compliance- or data-integrity-critical? If losing it means data gets deleted or a legal obligation goes unmet (not just "a feature stops working"), the retirement blast radius is existential, not inconvenient.
2. Is the vendor still actively investing in the surrounding platform? A feature bundled into a platform in maintenance mode inherits that platform's incentive to trim scope, not add it.
3. Can you swap the underlying primitive without the vendor's blessing? A managed cron add-on, a log drain, a scheduled-sync tool — if the only way to replace it is the vendor's own migration tooling on the vendor's target architecture, you don't control the exit, even when one exists.
4. What's your actual notice window? Data Bridge customers got roughly the length of their existing contract term — for some, that's ample; for a team on a multi-year enterprise deal renewed just before the cutoff, it's shorter than it sounds.
5. Does removing it downgrade your billing model too? Note that option 2 above wasn't just "keep the data" — it was "keep the data, but move to usage-based billing." Retirements often bundle a pricing change into the migration, not just an architecture change.

Score an integration low enough on 1–3 and high-risk enough on 4–5, and the honest answer is: don't let a marketplace add-on be the only thing standing between your data and permanent deletion.

Run Heroku Connect itself through the same five questions and the risk is already visible, even though nothing has happened to it yet. It's data-integrity-critical for any team using it to keep Salesforce and Postgres in sync (1). It sits inside a platform that's explicitly not investing in new development anymore (2). Swapping it out means either standing up your own polling sync against the Salesforce API or adopting whatever migration tooling Heroku ships when its turn comes (3). Nobody knows the notice window in advance — Data Bridge's was roughly a contract term, and there's no reason to assume the next one will be longer (4). And a retirement notice for a paid add-on is a natural moment for the vendor to also revisit how it's billed (5). None of that means Heroku Connect is getting cut next month. It means a team depending on it today has no more visibility into its future than a Data Bridge customer had a year ago.

What owning the pipeline looks like​

The durable alternative isn't heroic — it's a scheduled job you run yourself, against storage you control, using primitives that don't disappear when a platform vendor deprioritizes them. Concretely: a Postgres instance you provision, a small worker that runs on a cron schedule, and a sync or retention routine you own end to end. It's more setup than clicking "add-on" once, and it's exactly the setup that never shows up in a vendor's retirement notice.

This is the shape of infrastructure Bex.co is built around: push a git repo, define your app and its scheduled jobs declaratively, and get a running service on machines you own — no bundled marketplace add-on standing between your compliance data and a vendor's roadmap decision. Bex.co is the open-source, AI-native Render alternative; a scheduled sync job is just another App in the same repo you already deploy, not a separate product with its own end-of-life notice.

The pattern to watch for next​

Data Bridge won't be the last bundled integration a maintenance-mode PaaS quietly sunsets — it's just the first one small enough to cut without headlines. The teams that won't get caught by the next one are the ones auditing their own bundled dependencies now, against the five questions above, instead of waiting for a retirement notice to make the audit mandatory. If an integration fails that audit, the fix costs an afternoon today. Waiting for the vendor's contract-end date to force the question costs a scramble, on their schedule, through their tooling.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Sources​

• Heroku Data Bridge Retirement — Salesforce Help
• Heroku Storage: Data Retention Store — Salesforce Help
• Provision Heroku Resources for Privacy Center — Salesforce Help
• Heroku Connect — Heroku Dev Center
• An Update on Heroku — Heroku Blog
• Heroku future in doubt as Salesforce freezes features to focus on AI — DevClass
• Salesforce halts development of new features for Heroku cloud AI platform — TechRadar