# Moonhub was not acquired, and there is nothing to migrate

Salesforce told TechCrunch that Moonhub had not been acquired. Do not plan a move into a hiring product Salesforce did not buy.

**Published:** 2026-09-18
**Canonical:** https://synconai.com/moonhub-salesforce
**Author:** SynconAI Architecture Team

## In short

Moonhub was not acquired, on Salesforce's own account to TechCrunch. The company was shutting down, and only some of the team were joining. Do not plan a migration into a Salesforce hiring product. Confirm whether any Moonhub data export still exists. Do not hire a Moonhub Salesforce consultant for a product that was not bought.

## Sources

- **Salesforce buys Moonhub, a startup building AI tools for hiring** (retrieved 2025-06-02)
  https://techcrunch.com/2025/06/02/salesforce-buys-moonhub-a-startup-building-ai-tools-for-hiring/
  > A Salesforce spokesperson told TechCrunch that Moonhub has not, in fact, been acquired (by the company’s definition of the term). Rather, Moonhub is shutting down, and only some of the company’s team, not the whole team, as MoonHub implied in its post about the news, will be joining Salesforce.

## What to take away

- A Salesforce spokesperson said Moonhub had not been acquired. The company was shutting down, and only some of the team were joining.
- Do not tell a buyer to migrate off Moonhub into a Salesforce hiring product. That product was not bought.
- The action is to confirm whether any Moonhub data export still exists, and to close it lawfully if it does.
- Do not hire a Moonhub Salesforce consultant for a product that was not bought. Hire for the work you actually have.

## The guide

A talent leader sees a headline that Salesforce bought an AI hiring tool, and asks for a migration plan by the end of the month. The plan is supposed to move Moonhub data into "the Salesforce hiring product" and name a consultant who knows both. Recruiting operations starts a spreadsheet of candidate fields. Legal is not in the meeting.

Put the spreadsheet away. Read what Salesforce told TechCrunch. Then ask one operational question: does any export of Moonhub data still exist in your possession. Everything else in the headline is the wrong project.

## This was not an acquisition

TechCrunch's own account of the spokesperson is the record to use, not the headline beside it. "A Salesforce spokesperson told TechCrunch that Moonhub has not, in fact, been acquired (by the company’s definition of the term). Rather, Moonhub is shutting down, and only some of the company’s team, not the whole team, as MoonHub implied in its post about the news, will be joining Salesforce."

Read it in pieces. Not acquired, by Salesforce's definition of the term. Shutting down, rather than being folded in as a product. Some of the team, not the whole team. The post from Moonhub, as TechCrunch describes it, had implied a fuller move. The spokesperson corrected that implication. A buyer who briefs from the headline, and skips the correction, will fund a migration Salesforce's own words do not support.

People joining a company is an employment fact. It is not a product transfer. Some engineers moving across does not bring you a hiring application, a tenant, or a data-processing contract with Salesforce. If your company was a Moonhub customer, your contract was with Moonhub. What happened to that contract is a question for your papers and for whoever can still answer at the company that was shutting down. It is not a question a Salesforce implementation partner can settle by creating objects.

Do not smooth the name. The quote uses Moonhub and, once, MoonHub, because that is how the report refers to the post. Your files may use either. The spelling does not change the finding. The finding is that this was not an acquisition.

## Do not migrate into a hiring product

Do not tell a buyer to migrate off Moonhub into a Salesforce hiring product. Salesforce did not buy the product. There is no destination of that kind established by this source. A target system you cannot name is not a target. Drawing "Salesforce Recruiting" on the right-hand side of a map, because it sounds plausible, invents a SKU. Invented SKUs collect data. Candidate data is a poor kind of data to collect into an invented system.

The keyword "moonhub data migration to salesforce quote" has the same shape as a CRM cutover. Source, map, load, reconcile. That shape needs a source you hold and a target you have bought. Here the target was not bought. The source may already be gone. A quote in that shape is a quote for a diagram. Send it back before it becomes a sandbox full of CVs.

What a buyer may do, if they used Moonhub, is close their own affairs. Confirm whether the vendor is still obliged to return or delete data. Confirm whether you downloaded anything while the service still answered. Confirm whether a trial account is still reachable. Those are vendor-management tasks. They are not a Salesforce build. A Salesforce org does not become the system of record for a tool Salesforce did not acquire, merely because some of the people went there.

If a recruiter asks where the shortlists went, the honest answer might be that you do not know yet. That answer is uncomfortable in a steering meeting and it is still the right one. An uncomfortable blank is cheaper than a custom object full of candidates you had no right to reload.

## Confirm whether any export still exists

The right action is to confirm whether any Moonhub data export still exists. Not to hire a Moonhub Salesforce consultant for a product that was not bought. Start with a search you can finish.

Ask IT for backups and known shared drives. Ask recruiting for laptops and inboxes, including people who have since left, as far as your own access rules allow. Ask procurement for the contract, the data-processing terms, and any closure email. Ask finance for the last invoice, because a last invoice often sits next to the only copy of the notice that the service was ending.

Write the result as yes or no. Yes needs a path: which file, which machine, who can open it. No needs the list of places you looked, so the next person does not repeat a vague search and then assume the files must be in Salesforce. "No export found" is a successful outcome. It ends the migration conversation.

If the answer is yes, stop before you transform the file. Note the date of the export, the columns, and whether it contains contact details, assessments, recordings, or notes about people. You are identifying a store of personal data. You are not starting an integration. Duplication is the hazard. Every copy you make for a workshop is another copy to delete later.

## If a file does exist, scope the file

This is still not a Salesforce hiring implementation. It is a decision about a file you hold.

Lawful basis and purpose. Why you still have it, and what you are allowed to do with it now that the tool is not the reason. If the only purpose anyone can name is "in case we migrate", and there is no migration, the purpose has expired. Take that to the person who owns privacy. Do not take it to a developer first.

Retention. How long a candidate record may be kept in your organisation, and whether this export is already outside that period. An old export does not get a new clock because you found it in 2026.

Access. Who may open it this week. A project channel is the wrong place to drop a CSV of candidates so "the partner can see the shape". Show a column list with the rows removed, if a partner truly needs the shape. They rarely do, because there is no target product to shape it for.

Deletion. Where else it was copied: mail attachments, laptops, a sandbox someone already loaded. The sandbox load is the failure mode to look for. Well-meaning admins create a custom object so the data is "safe inside Salesforce". Salesforce is not a shredder. A custom object is another copy. If you find one, the work is to remove it under your retention rules, not to build a page layout.

What you will not do. You will not hire a Moonhub Salesforce consultant to configure a product that was not bought. You will not ask an agency to be the best at a Moonhub integration. You will not brief a migration. If the file must be kept for a dispute or a legal hold, the owner of that hold writes the instruction. A partner does not invent the hold to justify a project.

## Cost is the search and, maybe, the closure

There is no implementation fee to publish, because there is no implementation. Price the actual tasks.

- The search: IT, recruiting, procurement, finance. A named person. A date it ends.
- A yes/no note, with paths or with the places already checked.
- If yes: a privacy decision, a retention decision, and a list of copies.
- Removal of any sandbox or custom object created on the assumption of a migration.
- Letters or tickets you still owe the vendor, if the contract tells you to ask for deletion or return.
- Not in the price: a Salesforce hiring product, a field map into one, a consultant retained to "own Moonhub".

A firm that quotes a migration before your search has finished is quoting the headline. You can pay a short fixed piece for the search. You should not pay a build. The cost of a build is not only the invoice. It is candidate data in a place your privacy notice may not describe.

## The test, and the hire you should refuse

"Best moonhub salesforce integration agency" and "hire moonhub salesforce consultant" describe a role you do not need. Nobody is the best agency at integrating a product that was not acquired. The test is whether the firm refuses the work.

They can repeat the distinction between a headline and the spokesperson's account, in their own words, without softening "not acquired" into "acquired in a way". They will not propose a target object in Salesforce for Moonhub candidates. They will help you confirm whether an export exists, and they will stop when the answer is no. If the answer is yes, they will talk about access and deletion before they talk about fields. They will not ask you to paste sample rows into a chat.

A consultant who wants the engagement because they "know the Moonhub data model" is offering knowledge you cannot use. There is no Salesforce-side model to apply it to. Thank them and close the conversation. An implementation partner who treats every shutdown as a migration opportunity will treat this one that way too. The shutdown is the point. The product did not move across with the people who did.

If you do need Salesforce help, make it help you actually need: the org you run, the objects you already trust, the hiring process you run in some other system you can name. Keep Moonhub out of that statement of work so the next reader does not reopen the migration.

## What to finish this month

| Step | Done when | Do not proceed to |
| --- | --- | --- |
| Read the spokesperson's account | The brief says not acquired | A design workshop |
| Search for an export | Yes with a path, or no with places listed | A field-mapping session |
| Privacy looks at a yes | Keep, delete, or hold, in writing | A sandbox load |
| Copies listed | Including mail and sandboxes | A second extract for the partner |
| Consultant request | Refused, for this product | A retainer called Moonhub |
| Real Salesforce work | Scoped without the Moonhub name | A blended "hiring AI" programme |

:::warn
Do not hire a Moonhub Salesforce consultant, and do not migrate candidates into a Salesforce hiring product. Salesforce said Moonhub had not been acquired. The useful work is to confirm whether an export still exists, and to deal with that file under your own rules.
:::

When the search ends, send the yes-or-no note to the people who asked for the migration, in the same thread as the original request. A finding that lives only in an IT ticket will be invisible to talent, and talent will ask again next quarter. The note should be dull. Places checked. Files found, or none. Copies removed, or none. Next action, or stop. Dull is what you want. A vivid plan is how a shutdown becomes a programme.

Keep the note where a new recruiter can find it without access to the old vendor admin, because that admin may already be gone. The point of the note is to stop the next search from starting as a Salesforce project. If the note is missing, the keyword will hire a consultant you already decided not to hire.

A services firm that did join Salesforce is a different history, and it still does not create a source system to migrate. The contrast is [Acumen Solutions and Salesforce Professional Services](/acumen-solutions-salesforce-services). Do not brief the two names as one acquisition programme.

## The other searches

The project quote is on [moonhub implementation cost](/moonhub-salesforce-implementation-cost). That page does not print a figure. Who bought the company is on [what happened to moonhub](/what-happened-to-moonhub). The connector is on [integrating moonhub with Salesforce](/integrating-moonhub-with-salesforce). Whether to move is on [should I migrate from moonhub](/should-i-migrate-from-moonhub). The customer fee is on [moonhub licence cost](/moonhub-salesforce-licence-cost). Who to hire is on [hiring for moonhub](/hire-moonhub-salesforce-partner). This page does not rank an agency.


## Questions

### Did Salesforce acquire Moonhub?

No, on Salesforce's account to TechCrunch. A spokesperson said Moonhub had not been acquired by the company's definition. Moonhub was shutting down, and only some of the team were joining, not the whole team. Headlines that say "buys" are not the sentence to brief from. People joining is not a product you can implement.

### Should we migrate Moonhub data into Salesforce?

No. Do not plan a migration into a Salesforce hiring product. This source does not establish that Salesforce bought one. Confirm whether any export still exists. If it does not, stop. If it does, decide retention and access with the person who owns privacy. A custom object full of candidates is another copy, not a destination.

### What should we pay a consultant to do?

Not a Moonhub implementation. You should not hire a Moonhub Salesforce consultant for a product that was not bought. Pay, if you need help, for a dated search of your own archives and for closure of copies you already made. Refuse a quote that opens with a field map.

### A partner says they know the Moonhub model. Is that useful?

Not for a Salesforce build. There is no acquired product to configure, so a data model from the startup has nowhere contracted to land. The useful test is whether the firm will refuse the migration. A firm that leans on the model to keep the work has failed that test.

### What if we already loaded a sample into a sandbox?

Treat it as a copy of personal data, not as a head start. List who can see the sandbox, stop further loads, and ask the privacy owner whether the sample should be removed. Do not build a page layout on it while you wait. Finding the sample is part of the export search, not the start of an integration.

### Is moonhub owned by Salesforce?

No. A Salesforce spokesperson told TechCrunch that Moonhub was not acquired, by Salesforce’s definition. The full account is at https://synconai.com/what-happened-to-moonhub.

### When did Salesforce acquire moonhub?

The TechCrunch report is 2 June 2025. It is not an acquisition date.

### What happened to moonhub after the Salesforce acquisition?

Moonhub was shutting down. Only some of the team were joining Salesforce. There is no Moonhub hiring product inside Salesforce to implement.

### Should I migrate from moonhub to Salesforce?

Do not migrate off Moonhub into a Salesforce product this page cannot name. Ask whether any export still exists.

### What is the moonhub licence cost, or the price Salesforce paid?

There is no Salesforce purchase price, because there was no acquisition. The licence read is at https://synconai.com/moonhub-salesforce-licence-cost.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Salesforce consultancy (https://synconai.com/salesforce-consultancy).