The short answer
Elastic Workplace Search is gone, not deprecated. Elastic announced the retirement of Enterprise Search (which contained both App Search and Workplace Search) on April 15, 2025. There is no Workplace Search in version 9.0 or later: you cannot upgrade a standalone Enterprise Search deployment to 9.x at all. The 8.x line runs until End of Maintenance on January 15, 2027 and End of Support on July 15, 2027. Elastic's documented migration path is Elasticsearch itself, plus the Search UI library for the frontend and self-managed connectors for your content sources. Your data is not lost, but the product around it is.
Last updated: July 2026. Sources: Elastic product EOL schedule, Elastic 9.x migration guide.
If you run Elastic Workplace Search, you have twelve months of support left. Not twelve months until it gets worse, twelve months until it ends: Elastic's published End of Support date is July 15, 2027, which is one year from today to the day.
It is also not an isolated event. Elastic is one of four enterprise search vendors that changed shape in the last eighteen months, alongside Kendra freezing and both Sinequa and Moveworks being acquired.
This one is easy to underestimate, because the language around it is soft. Elastic describes the capabilities as being absorbed into core Elasticsearch rather than discontinued. That is a fair description of the engine. It is a misleading description of what you actually operate. Workplace Search was a finished, employee-facing product: connectors to Slack, Google Drive, Confluence and SharePoint that Elastic ran for you, document-level permissions, and a working search interface your staff could use. What replaces it is a set of building blocks.
What Elastic actually announced
The specifics, from Elastic's own retirement notice and EOL schedule:
- Announced April 15, 2025. That is the Software Product Retirement Notice date for Enterprise Search, covering App Search and Workplace Search together.
- Removed in 9.0. This is the part people miss. It is not deprecated in 9.x, it is absent. There is no standalone Enterprise Search 9.x build, so upgrading a standalone Enterprise Search deployment to 9.0 is not possible. You migrate off it first, or you stay on 8.x.
- End of Maintenance: January 15, 2027. Bug fixes stop.
- End of Support: July 15, 2027. Twenty-seven months after the announcement, and the real deadline.
- 8.19.x is the last line. Enterprise Search sits under retired products on Elastic's schedule. Patch releases continue, new features do not.
Deprecation notices started appearing inside the App Search and Workplace Search interfaces in 8.16.0, so if your admins have been seeing a banner for a while, this is what it was about.
Is my data lost?
No, and it is worth being clear about this because the retirement wording alarms people. Elastic has confirmed that data held in Enterprise Search instances remains available and queryable going forward. It lives in the .ent-search-actastic-* system indices: engines, documents, synonyms, curations and relevance settings are all still there and readable from Elasticsearch directly.
So this is a rebuild, not a data recovery exercise. That is genuinely better news than it could have been. The cost is not in moving bytes, it is in reconstructing everything that sat on top of them.
What Elastic tells you to migrate to
The recommendation is Elasticsearch itself. In Elastic's words, customers should "migrate to Elasticsearch directly and leverage the benefits of our new Serverless offering," on the basis that "the core capabilities for building search for the enterprise are all available in Elasticsearch Serverless."
Read that sentence carefully. The core capabilities for building search. The named building blocks are the Search UI library for the frontend, the language client libraries, semantic and vector search in the engine, Open Crawler for web content, and self-managed connectors for everything else. Every one of those is a component. None of them is a product your employees can open and use.
Elastic's own engineers have been reasonably candid about this on their community forum, conceding that the transition produces a stronger offering in some places and a few gaps in others. That is an honest read.
What you actually have to rebuild
Here is the practical inventory, mapped from what Workplace Search did for you to what you now own.
| Capability | Elastic Workplace Search (8.x) | Elasticsearch 9.x, after migration |
|---|---|---|
| App connectors | Elastic-managed content sources for Slack, Drive, Confluence, SharePoint and more | Self-managed connectors you host, run, patch and monitor yourself |
| Web crawling | Elastic Web Crawler, managed | Open Crawler, open-code and self-managed |
| End-user search app | Shipped and working out of the box | Build it on Search UI plus client libraries |
| Document-level permissions | Handled by the product | Reimplement against Elasticsearch primitives |
| Relevance tuning | Curations and relevance settings in the UI | Query-level engineering |
| Your indexed data | In Enterprise Search indices | Still there, queryable from Elasticsearch |
The connector line is the one that decides your budget. Elastic's migration guide is explicit: "Workplace Search content sources need to be replaced with self-managed Elastic connectors." The sync capability survives. The operations transfer to you. Somebody on your team now owns the hosts those connectors run on, the OAuth tokens they use, the failures at 2am, and the question of whether last night's Confluence sync actually finished. That last part is easy to wave away at design time and is exactly what bites eighteen months later, when nobody notices that a source has been silently stale for weeks. If you go this route, budget properly for monitoring the freshness of every sync rather than assuming a green deployment means current data.
The permissions line is the one that decides your risk. Document-level security is the difference between search you can roll out to the whole company and search you can only give to a team where everyone can already see everything. Getting it wrong does not produce a bug report, it produces an employee reading a document they should not have.
Your three real options
Option 1: rebuild on Elasticsearch
The path Elastic documents. It makes sense if search is a component inside a product you ship, or if you have engineers who know the stack and want the control. You keep the engine you already trust, you get semantic and vector search, and Serverless removes some of the operational floor. You are, however, writing and then owning an application: connectors, permissions, UI, relevance, and the pipeline that keeps it all fed. Be honest about whether that is a project your team wants to maintain for the next five years, because that is the real commitment, not the migration itself.
Option 2: stay on 8.x and decide later
Legitimate until January 15, 2027, when bug fixes stop, and defensible until July 15, 2027, when support does. The trap is that this is not a decision, it is a deferral, and the work does not shrink while you wait. If you take this option, take it deliberately: pick the month you will revisit it, and put it in the calendar now.
Option 3: buy a finished workplace search product
The question worth asking before you scope any rebuild is what the search was for in the first place. If the answer is "so people can find things," you are about to spend engineering quarters reconstructing a product category that you can buy. If the answer is "it is a feature inside what we sell," rebuild, and Elasticsearch is the right engine.
That is the fork. Workplace Search was in the first category for almost everyone who ran it. It existed so employees could type a question and find the answer across Slack, Drive and Confluence without knowing which one held it. Nothing about that goal requires you to own a connector fleet.
This is what InSearch does as a product: you connect Google Drive, Slack, Notion, Confluence, Gmail, Jira and Salesforce, and your team gets a written answer with inline citations back to the exact source. Item-level permissions are inherited from each app and enforced at query time, so a person only ever gets answers from content they could already open. There is no index to provision, no connector to host, and no search UI to build, and it never trains on your data.
How to decide, concretely
- Count your content sources. Each one is a self-managed connector you will host and monitor. Three is a project. Ten is a team.
- Write down who is allowed to see what. If the answer is more complicated than "everyone sees everything," document-level security is your critical path, not your last sprint.
- Price the frontend honestly. Search UI is a good library. It is not a finished application, and the gap between the two is where rebuild timelines usually go wrong.
- Ask who maintains it in 2029. The migration is finite. The ownership is not.
- Set the date. July 15, 2027 is the real one. Working back from it, a decision made after mid-2026 starts getting uncomfortable.
Frequently asked questions
Is Elastic Workplace Search discontinued?
Yes. Elastic announced the retirement of Enterprise Search, including Workplace Search, on April 15, 2025. It was removed entirely in version 9.0, so no 9.x version of it exists. The 8.x line reaches End of Maintenance on January 15, 2027 and End of Support on July 15, 2027.
Can I upgrade Workplace Search to Elasticsearch 9?
No. There is no standalone Enterprise Search 9.x build, so an upgrade path does not exist. Elastic's guidance is to migrate your content and search experiences to Elasticsearch before you upgrade the rest of your stack.
What replaces Elastic Workplace Search?
Elastic points you at Elasticsearch itself, with the Search UI library for the frontend, self-managed connectors for content sources, and Open Crawler for web content. Those are components rather than a replacement product, which is why many teams migrating off Workplace Search evaluate a finished workplace search tool instead of rebuilding one.
What happens to my Workplace Search data?
It stays. Elastic has confirmed data in Enterprise Search instances remains available, held in the .ent-search-actastic-* system indices and queryable directly from Elasticsearch. The engines, documents, synonyms, curations and relevance settings are all still readable. You are rebuilding the product around the data, not recovering the data.
How long do I have?
Until July 15, 2027 for support, and January 15, 2027 for bug fixes. Given that a rebuild involving connectors, permissions and a frontend is realistically a multi-quarter effort for most teams, the decision point is meaningfully earlier than the deadline.