Heroku and Salesforce: the app stays separate

A release manager refreshes a full Salesforce sandbox on Friday afternoon and tells the team the Heroku app came with it. The slide for the project says the customer portal lives "in Salesforce" now, because Heroku was acquired years ago. On Monday a tester creates an order in the sandbox. The portal, which nobody re-pointed, still talks to production. A real customer sees a test note on their account. The tester, looking only at the sandbox, thinks the feature is missing, because the portal they opened is not the sandbox at all. Two failures, one cause. The team believed a CRM refresh clones an app. It does not.

The repair is messy in a way a quote rarely prices. Someone has to find the write, explain it to the customer, and only then change the config so the test app points at the test org. None of that is a Salesforce deployment. Heroku was acquired in 2010 and is still a separate developer platform. You release it on its own, with its own config, its own logs, and its own person who can roll a release back.

#Still a separate platform

Keep the names apart in the statement of work. Heroku is where the app runs. Salesforce is the org the app may call. A sentence that treats a Heroku release as a change set will send the wrong person to the wrong log when the portal misbehaves. The administrator who deploys a permission set cannot see why the app returned an error. The developer who can read the app log cannot see why the integration user was locked. Both logs matter. They are not the same log.

The acquisition in 2010 did not fold the app into the setup menu. Buying Salesforce does not start a Heroku app. Keeping the product separate means you still ask for it by the name Heroku, and you still decide, in a contract, whether you have it. If the contract is silent, the quote must say the app is out of scope or must name who provides the runtime. Silence is how a CRM project starts and then waits a month for a platform nobody ordered.

Write the process the app actually performs. Not "the portal". The step a person cannot finish inside Salesforce alone. A customer checks an order. A partner submits a form the org will not host. A worker starts a job that has to run outside the transaction limits of a button. If you cannot name the step, you may not need the app in this quote at all. Leaving it in because the logo is old is how scope grows. Take it out until the step has a name.

A migration service, in the search sense, often means "move the app into Salesforce". For this product the honest answer is usually no. The app stays on Heroku. Salesforce keeps the records the app is allowed to read or write. The work is the contract between them: which object, which user, which fields, what happens when the org is down. A proposal that rebuilds the app as Lightning pages on a deadline has changed the product. That can be a real project. It is not the acquisition, and it needs its own reason, written by the person who uses the screen today.

#A Heroku app is not a Data 360 pipeline

Another confusion arrives from the word data. A team draws the app as a pipe into Data 360 because both sit near Salesforce on a poster. They are not the same job. An app responds to a person. A pipeline lands a data set. If the poster uses one box for both, the poster is the defect.

The help page records a rename, and you may use it only to keep the labels straight: "As of October 14, 2025, Data Cloud has been rebranded to Data 360." That sentence does not mention Heroku. It does not move the app. It does not turn a web process into an ingest. On 14 October 2025, Data Cloud took the name Data 360. Update the poster if it still says Data Cloud. Leave the app where it runs. A rename of a different product is not a cutover for a developer platform.

If the programme truly includes both, write two sentences. One for the request the app serves, and the record it writes back. One for the data set Data 360 holds, and the person who waits on it. If the sentences match, delete one product from this quote. You will either pay twice or skip the log that explains Monday's bad write. Do not describe the app as harmonising profiles. Do not describe a Data 360 activation as a release of the portal. Different failures, different owners, different tests.

#A sandbox does not clone the app

A Salesforce sandbox copies metadata and, depending on the type, CRM data. It does not copy a Heroku app. It does not copy the app's config, its add-on attachments, its logs, or the habit of how you release it. Refreshing the sandbox gives you a new org id and a new set of users. The app finds out only if someone changes the config to match. Until they do, the app is still aimed at whatever it was aimed at on Friday, which may be production.

That is why the Monday incident happens in good teams. The CRM refresh is a calendar event. The app config is a file somebody has to edit, review, and release. If the quote mentions the sandbox and does not mention that edit, the quote is incomplete. Put the edit on the page. Name the person allowed to change which org the app calls. A shared password in a note is not that person.

There is a second trap. A partial sandbox does not contain every record production has. An app pointed at it for a test may fail because the account is missing, then succeed against production where the account exists. The test did not prove the feature. It proved the data set. Say which sandbox type you will use, and which records must be there, before anyone calls the test a pass. Do not invent a claim that the sandbox includes the app because production is "in Salesforce". Production is not the app either.

Rollbacks differ too. Rolling back a Salesforce change set does not roll back a Heroku release. Rolling back the app does not restore a field a tester overwrote in production because the config was wrong. Write both rollbacks down. Practise the app rollback on a non-production app before you need it. The practise is part of the bill. A team that has never rolled back will learn it during the incident, which is the expensive classroom.

#What the bill is made of

Implementation cost means the parts of the bill. This page will not invent a dollar figure, a dyno count, or a traffic ceiling. Those numbers belong in your contract and your runtime, or they do not belong in the quote.

Discovery names the process the app performs, the Salesforce objects it touches, and the owner of the app. An owner is a person who can approve a release this month. A team name is not an owner. If the owner has left the organisation, the first line of the quote is to name a new one. Building features on an app nobody can release is how a portal rots.

Config names, for each environment, which org the app calls and which integration user it uses. Production, a full test, and a sandbox are three lines, not one. The integration user is a permission set: objects it may read, objects it may write, fields it must not touch. A user with broad admin rights because the first developer needed them is a finding. Narrow it before the next release. The app will not hide a field the user can query.

Release names who may deploy, how you know which version is live, and how you undo it. Logs name where an error goes, and who reads them on a weekday morning. A log that only the original consultancy can see is a lock-in. Put access to the log in the quote. Testing names one path that must succeed against the sandbox and one path that must fail closed when the org rejects the write. Include the case where config still points at production. That case should be impossible after the test, because the test app's config does not contain the production target.

Cutover, when the app already exists, is often a re-point and a watch, not a rebuild. Hypercare is the days after, with the owner reading the log. Training is the next developer in the organisation who can roll back without the partner. Leave any of these off and the number you were given is a deposit.

#The week a refresh is mistaken for a release

The expensive week looks ordinary while it is happening. Friday's refresh completes. The release note mentions only Salesforce. Monday's tester files a bug that the portal ignored their sandbox order. Tuesday a customer complains about a note they did not write. Wednesday the team argues about which log is true. Thursday someone rotates a password on the integration user in production and the real portal stops, because the test and the live app shared a user. Friday is an apology and a new user.

None of those steps are fixed by a longer Salesforce deployment window. They are fixed by separate config, separate users, and a person who can read the app log. Put that week in the risk section of the quote. If the partner says it cannot happen because Heroku is "part of Salesforce", they have not understood the boundary. The acquisition did not remove it.

#The test a buyer should use

Searches ask for the best Heroku Salesforce integration agency, for a consultant to hire, and for an implementation partner. Use a test on your app, not a rank.

Ask which process runs on Heroku, in one sentence a customer would recognise. Ask which Salesforce record it writes, and which field it must not write. Ask what a sandbox refresh does to the app. The sound answer is: nothing, until someone changes config on purpose. The unsound answer is: the refresh clones the app, or the app is already inside the sandbox. Ask the firm to show you the config for the test app and to prove it does not contain the production org id.

Ask who rolls back a bad release, and whether that person works for you. A partner who is the only one with the log has not finished the job. Ask them to refuse a rebuild of the app as Lightning unless you have asked for that different project in writing. Hiring a consultant is this conversation. It is not a badge.

Do not accept a claim that any firm is the best, including the firm publishing this page. Two firms that can name the process and the config can be compared. Two slogans cannot. If neither can show the test config, you are not ready to sign.

#What you settle before the next refresh

Write five lines before the next sandbox refresh. The process the app performs. The org each environment calls. The integration user for the test app, which is not the production user. The person who may change config. The person who reads the log on Monday.

Then run one write against the sandbox and confirm production did not change. Read the record as the user who should see it, and as a user who should not. If the app can edit a field the second user must not edit, the permission set is wrong. Fix it before volume, not after a customer notices.

An integration flow is a different runtime from this app. Do not put both on one line because both "connect". The neighbouring page is MuleSoft, which a sandbox also does not include. A flow and an app can both be in the programme. They still need two owners and two rollbacks.

The quote is ready when a new developer can see the process, the config for each environment, and the rollback, without asking the partner who sold the work. If the page says the app moved into Salesforce in 2010, send it back. The acquisition kept Heroku as a developer platform. It did not put the app in the sandbox, and it did not make the app a Data 360 pipeline.

#The other searches

The project quote is on heroku implementation cost. That page does not print a figure. Who bought the company is on what happened to heroku. The connector is on integrating heroku with Salesforce. Whether to move is on should I migrate from heroku. The customer fee is on heroku licence cost. Who to hire is on hiring for heroku. This page does not rank an agency.