Comparison guide
Keep the useful pattern.
Choose the infrastructure around it.
Heroku Connect made a powerful idea accessible: bring Salesforce records close to the application that needs to query them. A migration is an opportunity to revisit the constraints around that idea—especially the database, cloud, network boundary, and recovery behavior.
Why teams revisit the connection.
The original integration may have been the fastest way to expose Salesforce data to a Heroku application. Over time, the application can move to AWS, GCP, Azure, a private VPC, or a database that is not attached to the original platform. The question changes from “can we sync Salesforce?” to “what is the smallest dependable way to keep the product’s required CRM data local?”
That is a healthy reframing. It lets a team separate the application-data use case from a historical infrastructure choice. It also creates room to tighten object scope, review sensitive fields, and define how data drift is detected.
Evaluate the operational contract, not just the connector list.
Destination portability: can the mirror live in the Postgres, MySQL, or SQL Server environment the application already uses?
Freshness path: which objects use event-driven change capture, and what does the service do when an event is missed?
Recovery path: is there a durable replay checkpoint and a scheduled reconciliation rather than a hope that the worker never stops?
Network model: can a worker run inside a private VPC or on-premises network without public inbound database access?
Writeback semantics: if data needs to flow in both directions, how are conflicts, source ownership, and partial failures handled?
A latency claim alone is incomplete. The practical test is whether the system applies a change idempotently, resumes after an interruption, and reports the difference when source and destination do not agree.
Use a parallel migration, not a leap of faith.
Move one application workflow at a time. Start with the objects and queries that justify the migration. Backfill into a separate schema or shadow tables, then run the new stream alongside the existing one long enough to compare counts, source IDs, deletes, and important business fields.
Only change the application read path after the candidate mirror has proven it can catch up after a restart and a reconciliation run. Keep a rollback path that changes the application's read target, not the source CRM configuration.
Make deployment part of the decision.
A managed connector is a good fit when the database has approved network access and the team wants minimal operating work. A customer-network worker is a better fit when the destination stays in a private VPC or on-premises environment. In the latter model, the worker can make outbound connections while the database remains private.
Neither model is inherently “more enterprise.” The right one is the one that matches your network, compliance, and on-call ownership without creating an exception your engineers will have to maintain forever.
Decision checklist
List the application queries: do not migrate objects no code actually needs.
Choose a destination: prefer the relational database your service team already owns.
Prove recovery: backfill, stop the worker, replay, and reconcile before cutover.
Confirm source limits: validate the Salesforce edition, integration permissions, and selected CDC objects.
Cut over reads deliberately: keep a clear rollback path and a named owner for drift monitoring.
Planning a migration?
Bring your existing mapping and the application queries that depend on it. We can turn that into a scoped, portable replacement plan.