Amazon Kendra Is in Maintenance Mode: Your Migration Options in 2026

If you run internal search on AWS, this is the year you have to make a decision. Amazon Kendra, the managed enterprise search service AWS launched to index company content and answer natural language questions over it, is being put out to pasture. Not deleted, not switched off, but frozen: no new features, and no new customers after the end of July.

The announcement is easy to miss because of how gently it is worded, so it is worth being precise about what is actually changing, what it means for you, and what the realistic landing spots are.

What AWS actually announced

The facts, from AWS's own availability change notice, are narrow and specific:

• Maintenance Mode from June 30, 2026. No new feature or capability development for the service. New feature requests will no longer be considered.
• Closed to new customers from July 30, 2026. If you have not signed up by then, you cannot start using Kendra.
• Existing customers stay supported. AWS says it will continue to provide bug fixes and security updates. Your index does not stop working.
• The recommended path is Amazon Bedrock Managed Knowledge Base. AWS advises migrating existing Kendra applications there, and implementing any new search application there. Worth noting the timing: that service only reached general availability on June 17, 2026, less than two weeks before Kendra was frozen.
• There is no shutdown date. AWS has not published an end-of-life, retirement or termination date for Kendra. Maintenance Mode is not deprecation, and nobody is going to turn your index off.

So there is no cliff edge for current users, and no forced migration date. What there is, instead, is a service that will not improve again, on a platform where everything around it is improving quickly. That is a slow problem rather than an urgent one, which is exactly the kind that tends to get ignored until it is expensive.

What is Amazon Bedrock Managed Knowledge Base, and is it a like-for-like replacement?

Amazon Bedrock Managed Knowledge Base (AWS abbreviates it BMKB) is a managed retrieval-augmented generation service that reached general availability on June 17, 2026. It handles the whole RAG pipeline: it ingests your documents, chunks them, embeds them with a model you choose, stores the vectors, performs hybrid keyword-plus-semantic search, and can generate an answer with citations through a RetrieveAndGenerate API. The figures below describe the managed knowledge base specifically, since that is the service AWS names as the migration target.

On the generative side it is genuinely a step up from Kendra, which returned ranked passages and left you to wire in your own language model to turn those into an answer. Bedrock does that natively, and adds agentic multi-step retrieval on top.

It is not, however, a like-for-like replacement, and AWS does not claim it is. Its own migration guide is candid about the gaps. The headline one is connector coverage:

Read that table as a work estimate. Every "not supported" line is a feature your users may already rely on that you now own the implementation of. The connector gap is the biggest single item, and the numbers are AWS's own: Kendra ships 32 native connectors, the managed knowledge base ships seven (S3, Confluence, SharePoint, Google Drive, OneDrive, Web Crawler, and a custom connector). The custom document enrichment line deserves particular attention if you redact PII or tag metadata at ingest, because those Lambda hooks have no equivalent and that logic has to move upstream. For anything else, AWS's recommended pattern is to build a pipeline that pulls content out of the source system via its API, writes it to S3 with metadata sidecar files, and triggers an ingestion job. That is a real service to write, monitor and keep running. If the content you need happens to live on public web pages, you can at least turn those pages into clean, structured data without hand-rolling a scraper, but internal systems will need bespoke work.

What are my migration options?

There are three honest paths, and the right one depends on why you were using Kendra in the first place.

Option 1: migrate to Bedrock Managed Knowledge Base

If you are leaning this way, we have broken the job down in detail: what you actually have to rebuild covers the API remap, the connector pipelines, the metadata redesign and the chunking decision.

This is AWS's recommendation and the natural choice if you were using Kendra as infrastructure: you had engineers, you built a custom search application on top of the Retrieve API, and you want to stay inside your AWS account with your own VPC, IAM and data boundary. You get native RAG and agentic retrieval, which Kendra never had.

Be clear-eyed about the work. Migration means re-ingesting every data source, choosing a chunking strategy Kendra used to handle for you, translating metadata to sidecar JSON files, rewriting API calls, and implementing workarounds for the feature gaps above. AWS estimates this is achievable for most workloads with careful planning, which is fair, and also means it is a project, not a config change.

Option 2: move to another search platform you build on

If you want to stay in build-it-yourself territory but are not wedded to AWS, this is the moment to look around, because you are re-platforming anyway. Elasticsearch and OpenSearch remain the default for teams that want control over ranking. Vector databases plus your own retrieval layer are the other common shape. Both mean you own relevance tuning, permissions and the interface.

Option 3: stop building search and buy a finished one

This is the option most Kendra users overlook, and it is worth stating plainly: a large share of Kendra deployments existed for one reason, so employees could find answers across company systems. If that was your goal, the migration question is not "which index do I provision next" but "why am I building a search product at all?"

A finished workplace search connects to the source apps directly, handles retrieval, ranking, permissions and citations, and gives your team a search box that works on day one. There is no index capacity to provision, no chunking strategy to pick, and no connector pipeline to maintain. If the goal is answers rather than infrastructure, this collapses a multi-month project into a connection step. That is exactly the gap our Amazon Kendra alternative page walks through in detail, with an honest comparison of when building is still the right call.

Is Amazon Kendra deprecated?

Strictly, no. "Deprecated" implies a removal date, and AWS has not announced one. Kendra is in Maintenance Mode, which in AWS's language means fully supported but frozen: bugs get fixed, security gets patched, and nothing new gets built. The service stops taking new customers on July 30, 2026.

The practical reading is that a frozen managed service is a depreciating asset. Your competitors' search will keep improving while yours holds still, and the ecosystem of tutorials, integrations and hiring pool around Kendra will thin out. You do not need to panic, but you should not plan a five-year roadmap on it either.

How long do I have to migrate?

If you already run Kendra, AWS has committed to continued support without publishing an end date, so you have room to plan properly rather than scramble. Use it. A calm migration where you benchmark relevance against a golden query set beats a rushed one every time.

If you do not already run Kendra, your deadline is hard and it is July 30, 2026. After that you cannot create a new Kendra index at all, so if you were mid-evaluation, Kendra should come off your shortlist now rather than later. Starting a migration project on a service you cannot even sign up for is not a plan.

What to actually do this quarter

A sensible sequence, whichever path you pick:

• Inventory what Kendra is doing for you. List the data sources, the connectors in use, and which features (facets, synonyms, suggestions, feedback) your application actually depends on. That list is your migration scope.
• Ask what the search is for. If the answer is "so people can find things," seriously price the option of buying rather than rebuilding. If the answer is "it is a component inside our product," you are building, and Bedrock is the shortest path.
• Build a golden query set before you move. Thirty to fifty real queries with known correct answers. Without it you cannot tell whether the new system is better or worse, and you will be arguing about relevance from memory.
• Run both in parallel. Send the same queries to old and new, compare overlap and quality, and only cut over when the new one wins.
• Do not forget the documents nobody indexed. Scanned PDFs and image-based files are invisible to any search system until the text is pulled out of them, so if a chunk of your corpus is scans, plan for extracting the data from those documents as part of the ingestion work.

The bigger lesson

Kendra's wind-down is a reminder of something that keeps being relearned: enterprise search is much harder to own than it looks. The index is the easy part. The hard parts are connectors that keep working when an API changes, permissions that stay correct when someone is removed from a Slack channel, ranking that survives contact with real vocabulary, and an interface people actually open. AWS built all of that and still concluded the shape of the product should change.

For most companies, the right conclusion is not "pick a different index." It is that search is a product to adopt, not infrastructure to assemble. If you want the answer rather than the pipeline, our guide to how AI enterprise search works covers what a finished system has to get right, and enterprise search software shows what that looks like running across Drive, Slack, Notion, Confluence, Gmail, Jira and Salesforce, with a cited answer and permissions enforced at query time.