Migration planning
Heroku Connect is not shut down.
The direction is now visible.
In February 2026, Salesforce moved Heroku to a sustaining engineering model. That is not a shutdown, and no end-of-life date has been announced for the platform or for Heroku Connect. It is still the clearest signal yet that a data-integration layer many products depend on has stopped evolving—and integration layers take quarters to replace safely.
What was actually announced—and what was not.
The February 2026 announcement, reiterated in a March follow-up, put Heroku into sustaining engineering: the roadmap is defensive, focused on security patches, stability fixes, and infrastructure maintenance. New Enterprise contracts are no longer offered to new customers, while existing customers can renew. Nothing in the announcements names a shutdown date, and nothing specific has been said about retiring Heroku Connect.
Treat that distinction carefully. A vendor moving a platform to maintenance mode is not the same as a service termination notice, and planning based on invented deadlines produces bad decisions. Verify the current status against Heroku's own announcements before committing a plan—this page describes the state as of mid-2026.
The honest read: the platform keeps running, but the ecosystem around it—tooling, integrations, hiring, community answers—starts thinning immediately. For a dependency you can swap in a sprint, that matters little. For a data-integration layer, it matters early.
Why the sync layer moves before the dynos.
An application can often be re-platformed in weeks: containerize, redeploy, repoint DNS. A Salesforce data sync cannot. It carries an accumulated object and field mapping, implicit freshness expectations baked into application queries, delete and archive semantics, and—if you use writeback—conflict behavior your workflows silently rely on.
Replacing that safely means an inventory, a candidate mirror running in parallel long enough to trust, and a deliberate cutover with a rollback path. Teams that start that work when a termination notice arrives do it under pressure. Teams that start it while the existing sync is healthy get to compare systems side by side and cut over on a quiet week.
There is also a calendar nobody announces: your own contract renewal. A renewal date on a platform in maintenance mode is a natural decision point, and arriving at it with a proven candidate mirror is a very different negotiation from arriving with nothing.
Plan the migration in three moves.
Inventory what the sync actually does: the objects and fields mapped, which applications read them, the freshness each query genuinely needs, and where writeback to Salesforce is used. Writeback deserves special attention—decide whether each case belongs in a sync layer at all, or in application code calling the Salesforce API directly.
Choose a destination you own: the mirror pattern Heroku Connect made popular is worth keeping—Salesforce records close to the application that queries them. The infrastructure around it is the part to revisit: a Postgres, MySQL, or SQL Server database in your own cloud or network, rather than one attached to a platform. Our evaluation guide covers the operational contract to demand: backfill, Change Data Capture for a near-real-time change path, durable replay checkpoints, and scheduled reconciliation.
Run in parallel, then cut over deliberately: backfill the candidate mirror into shadow tables, run both streams side by side, and compare counts, source IDs, deletes, and the business fields your queries touch. Change the application read path only after the candidate has proven it can recover from a stop and pass a reconciliation run. Keep rollback as a read-path switch, not a Salesforce configuration change.
A sane timeline, without invented urgency.
This quarter: complete the inventory and pick the destination database—both are cheap, and the inventory is valuable even if you never migrate. Next: stand up the candidate mirror for one workflow and let the parallel run accumulate evidence. After that: cut over workflow by workflow, keeping the old sync alive until the last read path has moved.
The mistake to avoid is symmetrical: neither panic-migrate because a headline said Heroku is ending, nor wait for an official retirement notice to begin the inventory. The first wastes a quarter; the second guarantees the work happens under a deadline you did not choose.
Migration readiness checklist
Mapping inventory exists: objects, fields, owners, and the application queries that read them.
Writeback cases decided: each one assigned to the new sync layer or to direct API calls.
Destination chosen: a relational database your team already operates, in your own cloud or network.
Recovery proven: the candidate mirror has survived a stop, a replay, and a reconciliation.
Cutover and rollback rehearsed: read-path switch per workflow, with a named owner for drift monitoring.
Mapping a Heroku Connect exit?
Bring your current object mapping and renewal date. We can turn them into a scoped parallel-run plan with a destination you own.