ChatGPT
Claude
Google AI
Copilot
Platform & ArchitectureA developer was told to rebuild the Heroku app as a Salesforce tab before the quarter closed, and the room had already agreed. The reason on the ticket was the acquisition. Someone had read that Salesforce bought Heroku in 2010 and concluded the app now lived in the CRM. A second slide mentioned Data 360, and the app had been drawn as a pipeline into that product. The agreement felt settled: a long-owned platform must already be inside the org. The app had not moved. The slide had.
The app was a customer portal with its own database, its own deploy, and its own on-call rota. Rebuilding it as a tab would have dropped the database and kept the logo. The release was paused, which was the right pause, for the wrong reason. The agreement is the problem. It is easy to reach from a year as old as 2010, and it fits a rename of a different product, which does not redeploy a portal.
The distinction that matters is where the process runs. Salesforce bought Heroku in 2010. Heroku is still a separate developer platform. Salesforce owns it. An app still runs where you deploy it. A Salesforce org is still a different runtime. A Salesforce sandbox does not clone a Heroku app. Heroku is not Data 360. The acquisition changed the owner of the product. On the facts used here, it did not turn every Heroku app into a set of CRM objects.
What follows are the questions that keep the portal where it runs. A good answer names the on-call owner, the year, the contract, or the database. A general answer schedules a rebuild the sandbox cannot perform.
The questions, and what a bad answer signals
| Question | Who has to answer it | What a bad answer usually means |
|---|---|---|
| 1. What happened, and is the app inside Data 360 | The person who opened the rebuild ticket | A rename is being used as a migration plan |
| 2. Who owns the app | The person on call, by name | The sandbox is being treated as a clone of the portal |
| 3. Which year is the acquisition | Whoever drew the timeline | 14 October 2025 is being drawn as a revision of 2010 |
| 4. Where the price is written | Procurement, from the Heroku contract | A 2010 rumour is standing in for this year's fee |
| 5. Whether there is an end date | Whoever asked for the tab | The age of the deal is being read as an expiry |
1. What happened, and did the rename move the app?
The question is not how old the deal is. It is whether the portal still runs where you deploy it, and whether the sentence in the pack names Heroku at all.
Salesforce bought Heroku in 2010. Heroku is still a separate developer platform. You still ask for Heroku by that name. The acquisition changed the owner of the product. Customers were not, on the facts used here, moved off the platform by the deal. If you move a feature, write the reason, the test, and the owner.
The help page cited here is about Data 360. It states the rename in one sentence: "As of October 14, 2025, Data Cloud has been rebranded to Data 360." Use that sentence only to keep the names apart. Data Cloud took the name Data 360. The sentence does not mention Heroku. It does not say a Heroku app became a Data 360 pipeline. It does not say the 2010 deal was revised in October 2025. It also does not say why Salesforce acquired Heroku, or why Heroku sold. A diagram that draws the app inside Data 360 because of that sentence has used a rename as a migration plan.
What happened, for a customer, is an ownership change in 2010 and a platform that stayed separate. What did not happen is a shutdown, a published price on the cited page, or a merger with Data 360. If a partner's timeline shows Heroku ending when Data Cloud was renamed, ask them to point at a sentence. The sentence they are holding is the Data Cloud rename. Put it on the Data 360 box. Leave Heroku on the 2010 line, still a separate platform.
A good answer sounds like the on-call owner saying the portal still deploys as a Heroku app, bought in 2010, still separate, and that the October sentence is the Data Cloud rename quoted above.
A bad answer sounds like the ticket: rebuild the app as a Salesforce tab before quarter close, because 2010 means it already lives in the CRM and the Data 360 box is where the pipeline goes. The database does not survive that drawing.
Keep the note short enough to survive a steering pack. Owner: Salesforce. Product name: Heroku. Year: 2010. Still separate: yes. A new engineer can read the note before they open a build ticket that says to move it into Salesforce.
2. Who owns the app, and who can see the logs?
Salesforce owns Heroku. You do not own the platform because you bought a Salesforce org. Your organisation owns the app you deployed, the data that app stores, the pipeline that ships it, and the person who is on call when it fails. Those are different from the vendor's ownership of the product. Say the difference when a security review treats the app as a CRM custom object.
Is Heroku owned by Salesforce? Yes. Did Salesforce buy Heroku? Yes. Who owns Heroku? Salesforce. Say the three answers the same way in the steering pack, the vendor form, and the support template. A form that still lists Heroku as an independent company, and ignores the Salesforce relationship, is stale. A form that lists the app as a tab the sandbox already contains is also wrong. Ownership of the company is not the same fact as a clone of the app inside an org.
The acquisition did not move the app's database into Salesforce. The app can read or write a record when you connect it on purpose. Who owns each field remains a design choice. Salesforce owning Heroku does not make Salesforce the system of record for the portal. If a supplier asks who owns the product, give them Salesforce, the year 2010, and the statement that it is still a separate platform.
A Salesforce sandbox does not clone a Heroku app. Refreshing the sandbox does not redeploy the portal and does not copy the app's database. Anyone who says the sandbox already contains the app should open the org and show the running process. The absence is the finding. The acquisition did not change that boundary.
A good answer sounds like the on-call owner opening the org, showing that the portal process is not there, and naming the deploy pipeline and the database that still hold it.
A bad answer sounds like "the sandbox already contains the app, because Salesforce owns Heroku." The incident then goes to a team that cannot see the logs, and the portal is still running somewhere else.
Heroku is not a Data 360 pipeline. The quoted rename says Data Cloud became Data 360. It does not say an app's request path is now an ingest. If both products are genuinely in the programme, give each a job in writing. One sentence for what the Heroku app does. One sentence for what Data 360 holds. If the sentences match, you have one job wearing two names. Do not describe a web request as harmonised profile data because the slide ran out of boxes.
3. Which year is the acquisition?
When did Salesforce acquire Heroku? In 2010. There is no day and month to add on top of that year from the record this guide follows. The parent record uses 2010. If a slide needs a day, it needs a document that states the day. A long gap between 2010 and today is not evidence that the product was absorbed. It is evidence that the platform has remained separate for a long time. The years since the purchase are not an expiry.
Put 2010 on the timeline as the acquisition. Put 14 October 2025 on the timeline as the Data Cloud rename, and label that line Data 360. Do not draw an arrow from the 2025 line onto Heroku. The dates are far apart, and people still join them because both words appear near Salesforce. They are not one event. A reader who merges them will schedule a rebuild for a rename that never named the app.
Your own cutover, if you ever move a feature, is a third date, and it is yours. The cited page is the Data 360 help page. It is not a 2010 press release. State the year. Send a reader who wants the legal instrument to the contract.
A good answer sounds like two lines: Heroku, 2010, still a separate developer platform, and Data 360, 14 October 2025, a rename of Data Cloud, with no arrow between them.
A bad answer sounds like a rebuild dated to October 2025, justified as a revision of the 2010 deal, with a day in 2010 the pack invented to look precise.
4. Where is the price written?
How much did Salesforce pay for Heroku? The page this guide cites does not publish a Heroku purchase price or a licence fee. How much was Heroku sold for? Same answer. A Salesforce Heroku acquisition price does not appear on that page. The age of the deal makes a rumour more confident, not more usable. A blank is still the honest line.
The deal price, even if another document later shows you one, is not your licence. A figure from 2010 would not tell you what you pay to run the app this year. Your licence is the contract in your drawer, for Heroku and for Salesforce, as separate papers if that is how you bought them. If a paper is silent, write that the price is not in the paper you are holding. Procurement can ask the account team. That paper is the price that binds you.
What you pay a team to keep the app where it runs, and to connect the records it must read or write, belongs in a statement of work. That figure is not the 2010 purchase price. A quote that starts with a historical deal number, and ends with "rebuild as a tab", has skipped the platform you still have.
A good answer sounds like procurement reading the Heroku contract and the Salesforce contract as the papers they are, and stating the fee, or the silence, on each.
A bad answer sounds like a business case that pastes a 2010 figure from a video or a forum and uses it to fund a tab the sandbox cannot deploy.
5. Is there an end date, and where does the portal stay?
Was Heroku shut down or given a sunset date? No end date is stated here. An acquisition is not a shutdown. A rename of Data Cloud is not a shutdown of Heroku. A keyword that pairs the product with sunset is a question. The answer is that no end date is stated.
If a vendor tells you to leave Heroku because Salesforce bought it, ask for the retirement notice. A year in a search box is not a notice. 2010 is the year of the purchase. It is not an end. Customers still run apps on Heroku as a separate platform. You still ask for it by that name. A support template that has already called the app a Salesforce tab will send the incident to a team that cannot see the logs.
Confirm your own contract term, your renewal, and the person who can deploy. Those are your dates. They are not a product sunset. A forced rebuild as a Salesforce tab, because someone said the platform was finished, drops the database and keeps a screen. Leave the app where it runs until you have a written reason to move a specific feature, tested, with the on-call owner named. That move is a project you choose. It is not a conclusion from 2010 or from October 2025.
The app has a codebase, a deploy, a config, and a data store. Salesforce has an org, metadata, and records. Keep the app where it runs. Connect the records it must read or write when that is a choice you have written down. You do not receive Data 360 because you have Heroku, and you do not lose Heroku because Data Cloud was renamed.
A good answer sounds like the on-call owner naming the renewal on the Heroku contract and the feature, if any, that has a written reason to move, with a test and their name on it.
A bad answer sounds like "leave Heroku, it was bought in 2010, and October 2025 folded the app into Data 360." The portal stays up. The ticket describes a tab that does not contain it.
A DVD, a Reddit thread, a YouTube clip, a TikTok, a course, a book, or a certification is not a source for the date, the price, or a shutdown.
Where the decision goes next
Where the app stays, and which records it may read or write, lives on the Heroku page. Read it before anyone opens a ticket that says to rebuild the portal as a tab. The acquisition question ends when the pack can say the owner, the year, the missing price, and the missing end date.
