Hiring a Heroku partner for Salesforce now that Heroku is in sustaining engineering

Heroku is the one platform on this list where the right hire depends on a decision you may not have made yet. For some Salesforce customers, Heroku hosts a customer portal, a data service, a batch process or a public API that has run for years and that nobody wants to touch. For others it is the platform for a new build, chosen because developers like it. A partner hired for the first job is a custodian and integrator. A partner hired for the second is a platform advisor. The two profiles overlap and are not identical, and recent news makes the distinction more important.

Salesforce acquired Heroku in 2010 and the product kept its name. In 2026 Heroku published a post saying: "Today, Heroku is transitioning to a sustaining engineering model focused on stability, security, reliability, and support." The same post says: "Enterprise Account contracts will no longer be offered to new customers." It also says existing Enterprise subscriptions and support contracts will continue to be honoured and may renew as usual, and that credit card customers can continue with no changes to pricing, billing or service. Read the full update yourself rather than relying on a summary, including this one, because it is the basis for your plan.

None of that says your apps stop working. It does say that the platform's emphasis is stability, security and support, not new features, and that a buyer who would previously have signed an Enterprise contract for a new project cannot assume that path exists. A good partner will raise this in the first meeting. If it does not, ask why.

#Decide what you are hiring for

Four jobs get called "Heroku work".

Keep it running. An app exists, and it needs patching, dependency updates, scaling decisions, monitoring and an on-call arrangement. The skill is operations discipline in a platform with dynos, add-ons, config variables and pipelines.

Connect it to Salesforce. The app needs to read or write Salesforce data, or Salesforce needs to call the app. The skill is integration design, and it spans Heroku and Salesforce.

Extend Salesforce with it. An Apex callout, a Flow action or an Agentforce action calls code you host on Heroku, because the logic does not fit in the org. The skill is API design and secure invocation.

Build something new. The skill is architecture, with a platform comparison as step one.

A partner may do all four, but pricing and staffing differ, and your buying criteria should too. Should I migrate from Heroku explains how to think about the last question for an existing app.

#The credential and what it covers

Salesforce lists a single Heroku credential, and the name to look for is Salesforce Certified Heroku Architect. Trailhead describes it this way: "Certified Heroku Architects are skilled at architecting scalable solutions, deploying and managing apps, and managing teams and build-workflows on Heroku." Note how much of that is operational: deploying, managing apps, and managing teams and build workflows. It is closer to a platform engineer's role than an application developer's.

The credential does not cover Salesforce. A Heroku Architect who has never designed against Salesforce API limits, sharing or Apex may build a service that works on its own and breaks under real Salesforce traffic. For the Salesforce side, look for Salesforce Certified Platform Developer or Platform Integration Architect credentials on the person designing the boundary, depending on the size of the work.

#The two Salesforce bridges

Two Heroku products connect to Salesforce, and they behave differently.

Heroku Connect synchronises data between Salesforce and Heroku Postgres. Heroku's add-on page says: "Using bi-directional synchronization between Salesforce and Heroku Postgres, Heroku Connect unifies the data in your Postgres database with the contacts, accounts and other custom objects in the Salesforce database." That makes it a natural fit when an app needs Salesforce data as a relational table, for example a customer portal that lists orders and accounts. The things a partner must be good at are the ones the sentence hides. Synchronisation consumes Salesforce API calls, so volume matters. Two-way mappings need a policy for conflicts when both sides change the same field. Deletes behave differently from updates. A mapping that is too broad slows everything. Ask how the partner decides which objects and fields to map, and how it will monitor lag.

Heroku AppLink goes the other way. Heroku's documentation says: "Heroku AppLink (formerly Heroku Integration) is an add-on that exposes Heroku apps as API services in Salesforce." In practice that means Heroku developers build APIs on Heroku that Salesforce administrators and developers can invoke from Apex, Flow or Agentforce. The skills are different from Heroku Connect: API design, authorisation between the two platforms and defining actions so a Flow builder can use them without reading code. A partner experienced here will talk about permission sets, invocation patterns and how errors are returned to a Flow.

A third option is to avoid Heroku for the integration and use MuleSoft or native Salesforce tools. A sound partner will compare and sometimes tell you that a requirement does not need Heroku at all. Integrating Heroku with Salesforce covers the technical options in more depth.

#Red flags specific to Heroku

Selling a new build without mentioning the sustaining engineering announcement. A buyer should hear about it from the partner, with a view on what it means for the specific workload.

Treating Heroku like a server. Heroku's dyno filesystem is ephemeral, apps are meant to be stateless, and config belongs in variables. A partner who writes files to disk or stores sessions in memory will see strange failures after restarts.

No plan for Postgres. Data is the part that cannot be redeployed. Ask about backup and restore practice, how often restores are rehearsed, and what happens to Heroku Connect mappings during a database change.

Ignoring API limits. A Heroku Connect mapping that polls a large object can use a share of the org's daily API calls that other integrations need. A good partner measures before and after.

Rewriting everything in Apex. Apex is the right place for logic that must run in the org's transaction. It is not a generic replacement for an app. If a partner proposes to rewrite a working Heroku service because it is "closer to the platform", ask for the requirement behind it.

No exit thinking. Because the platform's direction has changed, a partner should record what is Heroku-specific in the design, so a future move to another host is a bounded task.

#A realistic first engagement

For an existing app, the best first piece of work is a health review that takes a couple of weeks. The partner should read the app, the pipeline, the add-ons, the Postgres setup and the Salesforce connection, and produce a short document with four sections. What is the state of dependencies and security patches? What would fail at twice the load? How is the Salesforce connection performing against limits? And a recommendation for the app: keep, harden, connect differently or move.

For a new workload, the first engagement is a short architecture comparison on your actual requirements: expected traffic, data location, latency to Salesforce, team skills and the support arrangement you need. The output is a written recommendation, with the cases where Heroku is the right host and the cases where it is not.

In both cases ask for a proposal that ends with a decision point, not an automatic second phase.

#Ten questions for a bid or interview

1. Which of your people hold the Heroku Architect credential, and who will be on our work?
2. How does Heroku's move to a sustaining engineering model affect your advice for our workload?
3. Show us a run-book you wrote for a Heroku app. Who was on call, and what did the first incident teach you?
4. How do you handle Postgres backups, and when did you last rehearse a restore?
5. For Heroku Connect, how do you choose which objects and fields to map, and how do you monitor lag?
6. What is your policy for a conflict when both sides change the same Salesforce field?
7. When would you use Heroku AppLink rather than Heroku Connect, and why?
8. How will Salesforce users be authorised to invoke an action hosted on Heroku?
9. What in this design is Heroku-specific, and what would a move cost us later?
10. What will our own team be able to run without you after the engagement?

#Checking references and evidence

For a Heroku reference, ask how many incidents occurred in the last year and who handled them. Ask whether dependency updates are applied on a schedule. Ask how the partner behaved when Salesforce API limits were hit, because everybody who runs Heroku Connect at scale meets that day. Ask whether the partner ever told the client not to use Heroku.

Request artefacts: a run-book, a pipeline description showing review apps and promotion steps, a mapping design for Heroku Connect, an OpenAPI description for an AppLink service and a log of dependency updates. These are ordinary working documents for a good team. Public examples are scarce, so ask for sanitised copies.

Be sceptical of case studies that name throughput but not failure rates, and of logos from the period when Heroku was the default choice for new Salesforce-adjacent apps. What matters is current practice: who has maintained a running app through the last year.

#Commercial models and the statement of work

For a health review, fixed price. For a connection project, fixed price for a defined mapping or API list with a change process for additions. For operations, a monthly retainer with a defined response time and a list of what is and is not covered, such as patching, scaling changes and incident response.

The statement of work should list the apps, the add-ons, the database and the Salesforce objects or actions in scope. It should say that the code, configuration records, pipeline definitions and run-books are yours and are held in repositories and accounts you control, with your own named account owner on the Heroku team. It should define the monitoring and who is paged. It should include a handover and a defect warranty. Platform fees go on Heroku's own billing, and the project fee belongs with the work: see Heroku Salesforce implementation cost and the Heroku licence guide.

Finally, ask about people and continuity. A Heroku app often depends on one engineer who knows why a worker is scaled the way it is. Whoever you hire should name a second person who can take over, and should write down the reasons behind unusual settings, so that a holiday or a resignation does not turn into an outage on the platform you rely on.

#When you do not need a partner

If you have one stable app, an owner who understands it, and no plans to change how it talks to Salesforce, you may not need anyone. If the requirement is a simple outbound call from Salesforce, Apex or Flow with a named credential may serve without any external host. If your developers have run Heroku in production and the work is incremental, they do not need an outside architect.

Get a partner when the app is business critical and its builder has left, when a Heroku Connect mapping is straining your API allowance, when you want Salesforce to call logic you host, or when you must decide whether a platform that has announced sustaining engineering is the right home for something new.