Should you migrate from Heroku?

A release plan said the Heroku app would be rewritten as Apex before the next quarter. The reason was the acquisition. The app took bookings from a public page, checked a limit the org did not store, and wrote one opportunity when a person confirmed. Around the table everyone already agreed the rewrite was due. On the Monday the rewrite was due, the public page was still the Heroku app, because the Apex version could not run the page for people who were not users. Someone pointed the domain at a Salesforce site anyway. The page failed for guests. The opportunity never arrived. The sandbox, refreshed that morning, did not contain the app. The agreement is the problem. It is easy to reach, and it fits a slide that said one platform was enough, which is not a guest who can finish a booking.

A failed page is compatible with an app that still serves people who are not users, Apex that already sets a field on a record, a Data 360 rename that does not host a booking, and a sandbox that copied metadata and did not keep the app's address. Only one of those is a decision about a named behaviour. The 2010 acquisition had been used as a rewrite order. The app was still a separate platform.

What follows are the questions that separate those explanations. Each has a good answer and a bad answer, and the difference is whether the answer names something specific: a behaviour, a guest, a class, a field. A general answer at this stage is what turns into a domain pointed at a page guests cannot open.

#1. Which behaviour is actually in the room?

The question is not whether to migrate Heroku. It is something a person can do: submit a booking, read a status, calculate a figure the org does not hold.

A good answer sounds like one behaviour, named by someone who used the public page, with a sentence a guest could recognise.

A bad answer sounds like rewrite the app. If you cannot name the behaviour, you are not ready to rewrite anything. You are ready to leave the app where it is. A programme that starts by rewriting the whole app as Apex has chosen the guest outage. Send it back.

Heroku was acquired in 2010 and kept a life of its own. It is still a separate platform. An app runs there. People reach it without being Salesforce users. The org can be a system the app reads or writes. The app is not a Lightning page that appeared because the companies share an owner. Buying Salesforce does not turn the app into metadata. The name you deploy is still Heroku. 2010 is a date. It is not a destination. The acquisition did not fold the app into a tab.

#2. Who is the person, and are they a user?

Stay when the app serves people who are not Salesforce users, or when it runs work the org does not store. Apex runs inside the org. That fact does not make Apex the app. You still ask for Heroku by that name when the work lives there.

A good answer sounds like a line that says users, guests, or both, written with someone who tried the guest path, and a statement that a guest who is not a user is still in the decision.

A bad answer sounds like everyone is a user. A class that tries to be the public site will either demand a user the guest does not have, or it will be a different product you have not finished. Both can be projects. Neither is justified by 2010. Read the six lines of the decision to someone who used the public page. If the guest has vanished, you have rewritten them out of the decision. Put them back, or state that this decision is only the field write.

Move one behaviour only after you have named the object, the field, and the user, and only if that behaviour is already a change to Salesforce data. Moving "write the confirmed booking onto the opportunity, in the field the seller reads" might be that sentence, if the public page can stay where it is until that write is proven. Moving "the Heroku app" is not.

#3. What does Apex already do?

Name the native behaviour before you compare an app with it. Apex is code that runs in the Salesforce org. It can run when a record is created or when a field changes. It can run when a page in the org calls it. It reads and writes Salesforce data as a user the org controls, under the limits that org enforces. A Lightning page shows fields of a record to a user who is logged into the org. An administrator can open the class and the page in that org. A sandbox can contain them, because a sandbox copies metadata. That is what native application code already does. It runs where the records live.

Apex already changes records the running user may change. It already reacts to those records. It already fails in the org, where an administrator can read the error. It does not already run a public page for a guest who has no user. It does not already keep the process that was running on Heroku last night. It does not already appear because a sandbox was refreshed. Those are not lines in a class you have not opened. They are a separate platform.

A good answer sounds like four lines from a class that exists, or an honest statement that there is no class: which object it touches, which fields it may change, which user it runs as, and what a guest is supposed to do.

A bad answer sounds like use Apex. If the fourth line needs a guest and the class has no guest, you do not yet have a native replacement. You have Apex that does a different job. If the behaviour is "when this opportunity changes, set a field on the same record", you may not be migrating. Apex, or a Flow, may already do it. Write the field. If that is the whole need, leave the app alone. Do not call a field update a Heroku migration. If the behaviour is the public page, the check the org does not store, or the process that must run when no user is logged in, Apex is the wrong destination for the app. Do not rewrite Heroku apps as Apex because of the acquisition. The app stays until the one behaviour you named has a home you have opened.

#4. Why is Data 360 beside a booking page?

People searching for what the software is now sometimes land on Data 360, because both are talked about beside the platform. They are not the same product. The help page states a rename, and the sentence is quoted once: "As of October 14, 2025, Data Cloud has been rebranded to Data 360."

Use that sentence to correct a label. It does not mention Heroku. It does not say an app became a Data 360 pipeline. It does not revise 2010. Put the rename on the Data 360 line. Leave Heroku on the 2010 line, as a separate platform.

A good answer sounds like two lines kept apart: Data 360 renamed as of 14 October 2025, Heroku still the separate platform from 2010, written by the person who mixed them.

A bad answer sounds like the rename is a reason to move the app. Data 360 is not Heroku, and it is not Apex. The quoted sentence does not host the booking page. Do not move the app into Data 360 because the label changed. Keep the app on its platform. Keep Apex on the record it actually updates. If both sentences describe the booking page, you have not decided. Delete one.

There is no end date for Heroku in the material this decision is allowed to use. Do not invent a shutdown. An acquisition in 2010 is not a sunset. If a vendor tells you the app must be rewritten because Salesforce owns the company, ask for a retirement notice that names the app. A Data Cloud sentence does not qualify. Until a notice like that exists, the software is the platform it was. Do not describe the app as Apex that has not been written yet.

#5. What is the plan using instead of the guest path?

A Salesforce sandbox does not clone Heroku. Refreshing a sandbox copies Salesforce metadata and, depending on the type, some CRM data. It does not copy the app. It does not keep the app's address, its running process, or yesterday's guests. Anyone who says the sandbox includes the app should open it and show the page a guest used. The absence is the finding. A sandbox refresh is not a migration off Heroku. Pointing the public address at a page guests cannot open is not a cutover. Rewriting the app as Apex because the company was bought is a new build wearing an old ticket.

A good answer sounds like a refusal, written by someone who tried the guest path, of four things: a sandbox as a clone, a rewrite dated from 2010, a listing as the app, and a ranked shortlist.

A bad answer sounds like a listing will replace the app you run. No listing is invented here. An app that replaces the one you run is not described. A catalogue page is not a decision. If a proposal cites a listing that was never named here, ask them to show the guest path on it. Until they can, the listing is a rumour. The shapes here are not ranked. Keep the Heroku app where it runs. Use Apex for a change to records inside the org, after you have named the object, the fields, and the user. Keep both, when the app owns the guest path and Apex owns a field the seller reads. Firms are not ranked. Listings are not ranked. Two options can be compared by whether a guest can still finish the booking. A league table cannot. The 2010 deal did not produce a ranked replacement, and it is not proof the app should move.

Stop after one behaviour. The next behaviour is the next decision. A diagram of the whole app is not this decision. Cross out the paths this decision will not touch. If a document is a list of classes to create, it has skipped the guest. Do not let the class list retire the app.

#What staying actually looks like

All five answers are measured against an alternative, and the alternative is usually left unstated, which flatters the rewrite.

State it. Staying means the public page keeps running on Heroku for the guest who is not a user, and Apex, if it is used, changes only the field on the record you have named. The cost of a false move is the Monday you already had: the domain pointed at a page guests could not open, the opportunity that never arrived, and a sandbox that did not contain the app.

There is a version of staying that is simply the correct decision. If the fourth line needs a guest and the class has none, the app stays. An organisation that names one behaviour first reaches any later class with the guest still able to finish.

A good answer sounds like the behaviour, who does it, what Apex already does, the gap, and a choice to keep the app, use Apex for that field, or keep both, with a date and a person who will try the guest path again.

A bad answer sounds like we cannot keep a separate platform after 2010. The acquisition left Heroku separate. It did not turn the app into a class.

#Where the neighbouring questions live

Cost and hiring sit on the Heroku implementation page. The purchase story sits on what happened to Heroku. The connector sits on integrating Heroku with Salesforce.