If your enterprise deployed Amazon Q Business, Kendra, or Bedrock Agents in the past two years—congratulations, you were an early adopter. AWS has now put all three services into maintenance mode. Capability development stopped June 30. New customers stopped being accepted July 30-31. And the successor services AWS is pointing you toward are materially different products, not simple upgrades. You have a migration decision to make, and the clock is already running.
Update — August 26, 2026: The runway assumption in this article was too generous, and AWS has now shown by exactly how much. Amazon Mechanical Turk—one of the SageMaker AI features moved to maintenance in this same June 30 tranche—will permanently close on September 30, 2026. It closed to new customers on July 30. The closure was announced on August 25. That is 26 days from maintenance mode to a published death date, 62 days from maintenance mode to gone, and roughly 36 days of public notice. The 90-day plan below still describes the right work. It no longer describes the time you have to do it in. Read every name in this tranche as a dated exit whose date has not been published yet—and see the new section on human review, because three of those names have no successor at all.
Update — August 28, 2026: This article treated MTurk, A2I, and Ground Truth as three services a team would know it uses. AWS's own documentation says otherwise, and that changes who is exposed. The Mechanical Turk workforce is the "public workforce" option inside Ground Truth labeling jobs and A2I human review workflows—selected as a WorkteamArn, with no separate MTurk account and no separate MTurk line item on your bill. So an inventory pass that greps for the string "Mechanical Turk" will come back clean on pipelines that die on October 1. AWS has since added a closure banner to that documentation page telling customers to transition off the MTurk workforce before September 30. The discovery step that finds this is now in the Days 1-30 block below, and it is a one-day query, not a migration.
This isn't a routine cloud service update. This is AWS retiring AI services faster than many enterprises complete a single procurement cycle. Bedrock Agents launched in November 2023. Q Business launched roughly a year later. AWS is now moving both into maintenance mode before most enterprises have finished deploying them at scale.
Understanding what happened, why AWS made this move, and what it means for your roadmap is the right place to start. Then we can talk about the 90-day plan.
What AWS Actually Did on June 30
The announcement, framed as a "service availability update," moved roughly 20 services and features into maintenance mode in a single day. The three headline names are Q Business, Kendra, and Bedrock Agents—but the full scope is broader.
Nine Amazon SageMaker AI features also moved to maintenance in the same update—A2I, Clarify, Debugger, GeoSpatial, Ground Truth, Mechanical Turk, Model Monitor, Role Manager, and Studio Lab—while SageMaker Profiler entered sunset and SageMaker Ground Truth Plus went to end of support that same day. Ground Truth Plus is the detail worth pausing on. The tranche had a casualty on the day it was announced, and almost nobody wrote it up.
The non-SageMaker names in the same update are the rest of your inventory checklist: Bedrock Agents Classic, Cognito Sync, Kendra, Q Business, Simple AD, IoT Device Defender Detect (closed to new customers August 31, 2026), Mainframe Modernization Self-Managed Experience, myApplications, Resource Groups Group Lifecycle Events, Service Catalog Application Registry, and Systems Manager Application Manager. If any of those strings appears in a Terraform file or a CloudFormation template you own, you are in this story—whether or not you think of yourself as a Q Business customer.
A March 2026 update had already pushed AWS App Runner, CloudTrail Lake, and Audit Manager into maintenance, while Amazon WorkMail and RDS Custom for Oracle moved to full sunset. Taken together, these represent the most coordinated catalog pruning AWS has executed.
In AWS terminology, maintenance mode sits between full support and sunset. Existing customers keep their workloads running. AWS continues security patches and bug fixes. Feature development stops entirely, and new customers cannot sign up. On June 30 there was no hard end date announced for any of the maintenance-mode workloads. Fifty-six days later, one of them got one.
The specific timelines: Kendra stopped accepting new customers July 30. Q Business closed to new customers July 31. Both remain available to existing deployments indefinitely under the current guidance, but "indefinitely" in maintenance mode is a planning risk, not a commitment.
The Successor Map: What Replaces What
AWS has been deliberate about the consolidation narrative. Every retired service has a designated successor, and the successor map reveals the strategy.
Kendra → Bedrock Knowledge Bases. Amazon's managed RAG (retrieval-augmented generation) service with built-in connectors, hybrid search, and an agentic retrieval API becomes the replacement for the enterprise search service. The architectural direction is sound—RAG-native retrieval is more aligned with how enterprises want to deploy AI than pure semantic search. But the migration is not clean. Some Kendra data source connectors lack a native equivalent in Bedrock Knowledge Bases, and AWS's own migration guide recommends routing unsupported sources through Amazon S3. That means additional infrastructure, additional complexity, and additional engineering time.
Q Business → Amazon Quick. The enterprise AI assistant platform that AWS launched is being folded into Amazon Quick, the platform AWS introduced in October 2025 by merging Q Business capabilities with Amazon QuickSight. Quick is a broader product—it includes Quick Flows for workflow automation, QuickSight integration for structured data analysis, Research for in-depth research, and Spaces for unified knowledge management. The vision is compelling. The migration involves rebuilding connector configurations and adapting application integrations.
Bedrock Agents Classic → Bedrock AgentCore. The agent execution platform gets a rename and a successor. AgentCore is AWS's new foundation for running production agents, positioned as more robust for the kind of multi-step, tool-calling agent workflows that enterprises are increasingly deploying. The "Classic" label on the old Bedrock Agents is AWS's way of telling you it's the legacy path.
The Successor Map Has a Hole Where Human Review Used to Be
Three names in this tranche—A2I, Ground Truth, and Mechanical Turk—have no successor at all. The wording of AWS's own notices is the tell, and the contrast is stark enough to be deliberate.
Kendra's documentation names a replacement in its first sentence: "For capabilities similar to Amazon Kendra, explore Amazon Bedrock Knowledge Bases." The A2I notice names nothing. It reads, in full: "Amazon SageMaker A2I is no longer open to new customers. Existing customers can continue to use the service as normal. AWS continues to invest in security and availability improvements for A2I, but we do not plan to introduce new features." No replacement, because there is not one to point at.
It is tempting to file human review under the Bedrock migration and move on—Bedrock does have evaluation tooling, after all. That mapping is wrong in kind, not just in detail. Bedrock's evaluations are automated: programmatic metrics and LLM-as-judge. A2I, Ground Truth, and Mechanical Turk are human labor. Substituting a model's judgment for a person's is a change to what your pipeline measures, not a change to which API it calls, and if you deployed A2I because a regulator, an auditor, or your own risk function wanted a human in the loop, an LLM judge does not discharge that requirement.
So if you have an A2I human-review step inside a Textract, Rekognition, Comprehend, Transcribe, or custom-endpoint pipeline—or evaluation gold sets sourced through Mechanical Turk or Ground Truth—this is not a service-to-service migration. It is a decision about where the humans come from. Scale AI, Mercor, and Prolific are the names that absorbed most of MTurk's decline, alongside Surge. Every one of them means a new contract, a new data processing agreement covering whatever your reviewers see, a new security review, and a new unit price that will not resemble a few cents per task.
There is a cheaper path this article understated. AWS keeps three workforce types, and only one of them is dying. A private workforce is your own staff, managed through Amazon Cognito or your own OIDC identity provider—switching to it is a WorkteamArn change and a rota, not a procurement cycle. A vendor workforce is subscribed through AWS Marketplace, which at least keeps the contract inside an agreement you already have. Both survive September 30. If your review volume is small enough to staff internally, this is an afternoon of configuration. If it is not, the external re-sourcing above is procurement lead time, not engineering lead time, and procurement is the longer of the two in most enterprises. MTurk served more than 500,000 workers at its peak across 21 years; whatever fraction of that pool touched your pipeline has to come from somewhere else by September 30.
The Dependency Is Invisible Twice Over
Here is the part that turns a scheduling problem into a discovery problem. The Mechanical Turk workforce is not a service you integrate with. It is an option inside Ground Truth and A2I—the "public workforce," selected by passing one ARN. AWS states it plainly: "Any Amazon Mechanical Turk workforce billing is handled as part of your Ground Truth or Amazon Augmented AI billing. You do not need to create a separate Mechanical Turk account to use the Amazon Mechanical Turk workforce."
Read that as an exposure statement. There is no MTurk entry in your account list, because there is no MTurk account. There is no MTurk line on your bill, because the charge arrives as Ground Truth or A2I. A discovery pass that greps Terraform and billing exports for the string "Mechanical Turk" comes back clean on a pipeline that stops working on October 1.
The dependency is one field. In an A2I flow definition it is HumanLoopConfig.WorkteamArn; in a Ground Truth labeling job it is HumanTaskConfig.WorkteamArn. The value that means MTurk is arn:aws:sagemaker:{region}:394669845002:workteam/public-crowd/default—and that account number, 394669845002, is AWS's, not yours. It is the same in every region. Grep your flow definitions and labeling jobs for those twelve digits and you have your answer in a day.
AWS has now added a closure banner to that same documentation page: "If you currently use the MTurk workforce option, we recommend that you review your affected workflows and transition to an alternative workforce option before September 30, 2026." That sharpens the point above. A2I and Ground Truth still have no published end date. Their public workforce does. If your human review runs on MTurk workers, you do not get to plan around the services' open-ended timeline—you inherit MTurk's, and it is 33 days out.
The counterintuitive part is who this actually hits. AWS has always forbidden the MTurk workforce for sensitive data: the docs require your input be free of PII, and a job that does not set the FreeOfPersonallyIdentifiableInformation flag fails outright. The same page rules it out for video frame and 3D point cloud labeling, and warns against it for HIPAA-eligible workloads. So regulated pipelines were never on this workforce. They were pushed onto private or vendor teams years ago, by a hard failure at job-submission time.
The teams that break on October 1 are the unregulated ones—evaluation gold sets, content moderation on public data, generic OCR quality checks. Exactly the pipelines nobody put on a compliance inventory, run by teams who never had a reason to think about where the labelers came from. If your risk register is what you plan to search, you will search the wrong list.
Why AWS Made This Move Now
The why matters more than the what for long-term planning.
AWS built Q Business, Kendra, and Bedrock Agents as separate products during a period when no one was sure how enterprise AI would be consumed. The result was a sprawl of overlapping point solutions—each solving a slice of the problem independently. Microsoft and Google arrived at consolidation earlier. Microsoft folded its enterprise AI capabilities under the Copilot brand. Google consolidated under Gemini Enterprise. Both built unified experiences from the start of the current generation.
AWS shipped first-generation products and is now unwinding them in public. The resulting consolidation—Bedrock for models and retrieval, AgentCore for agent execution, Quick Suite for business user experience—is architecturally cleaner than what it replaces. But the timing creates a real problem for enterprises that made platform decisions in 2023 and 2024 based on AWS's product roadmap signals.
The deeper dynamic is competitive pressure. AWS's enterprise AI market share has faced headwinds from Microsoft's Copilot momentum and Google's Gemini Enterprise integration. Maintaining a fragmented catalog of point solutions makes it harder to compete against unified platforms. Consolidation is the right long-term call—but it comes at the cost of enterprise buyers who standardized on the first generation.
For Business Leaders: The Vendor Risk Calculation
The business case for early adoption of enterprise AI has always rested on moving faster than competitors. AWS actively encouraged enterprises to deploy Q Business, Kendra, and Bedrock Agents with re:Invent launches, case studies, and dedicated migration playbooks. Enterprises that followed that guidance are now absorbing migration costs that weren't in the original business case.
This creates a specific vendor risk calculation worth internalizing before the next cloud AI platform decision.
The cost of migration is not just engineering hours. It's the opportunity cost of roadmap capacity redirected from innovation to infrastructure maintenance. An enterprise that planned a 2026 initiative to expand its AI-powered workflow automation now has a competing priority: migrating the foundation that initiative is built on. That reallocation of engineering attention has real business impact, even if it doesn't show up on a migration cost estimate.
The budget implication for business leaders: migration to Quick Suite and AgentCore should be treated as unplanned capital expenditure. AWS's migration guidance is comprehensive, but "phased approach starting with Bring Your Own Index" is not a synonym for "minimal effort." Budget for discovery (inventorying what's deployed and how), architecture (designing the target state), migration execution, and testing. Organizations with significant Q Business or Kendra deployments should plan for months of engineering work, not weeks.
The procurement lesson is structural. Cloud AI services should be evaluated on more than current capability. A service that launched 24 months ago and is already in maintenance mode is evidence that cloud AI catalogs are actively rotating. Future procurement decisions should include abstraction requirements—applications should not be written against specific AWS service APIs without an isolation layer that enables migration.
For Technical Leaders: The Migration Architecture
The migration complexity varies significantly by how deeply your applications are coupled to the deprecated service APIs.
For Kendra deployments, the critical variable is connector coverage. Bedrock Knowledge Bases supports a large set of data source connectors natively, but gaps exist. AWS recommends routing unsupported sources through S3 as an intermediate step. If your Kendra deployment relies on connectors that aren't natively supported by Bedrock Knowledge Bases, you're looking at a two-phase migration: first to an S3-based intermediary, then to native connectors as they become available. Map your connector dependencies before estimating migration scope.
For Q Business deployments, the complexity depends on how you integrated Q Business into your applications. Customers using Q Business for anonymous access and API integration into custom applications face the most friction—AWS explicitly recommends contacting AWS Support to discuss custom migration approaches for these deployments. The standard migration path uses Model Context Protocol (MCP) integrations for connectors that Quick Suite doesn't natively support, but those MCP integrations cannot serve as knowledge base data sources for document indexing. That's a meaningful architectural constraint.
For Bedrock Agents deployments, the migration to AgentCore is the most fluid of the three. AWS has positioned AgentCore as a direct evolution rather than a complete redesign. But fluid doesn't mean automatic—agent configurations, tool definitions, and orchestration logic need to be validated against AgentCore's execution model before assuming compatibility.
AWS's migration guidance mentions an automatic migration path scheduled for Q4 2026. That option exists, but treating "automatic migration in Q4" as your plan means letting AWS make architectural decisions for you under a compressed timeline. It's not a recommended approach for production workloads.
The 90-Day Migration Plan
The absence of a hard sunset date creates a false sense of time. Mechanical Turk is the proof: 26 days from maintenance mode to a published death date, 62 days to gone. Ninety days is not the runway AWS is offering. It is the maximum you should let elapse before you have real migration data in hand, because the announcement can land inside it.
Days 1-30: Discovery and risk assessment. Inventory every production workload that touches Q Business, Kendra, or Bedrock Agents Classic—then run the same query against the SageMaker feature names, which is where teams find dependencies they had forgotten they owned. Classify each by migration complexity: simple (well-abstracted integration), moderate (some service-specific API dependencies), and complex (deep coupling or unsupported connectors). Flag any human-review or labeling dependency separately, and do that one first: enumerate your A2I flow definitions and Ground Truth labeling jobs, read HumanLoopConfig.WorkteamArn off each DescribeFlowDefinition and HumanTaskConfig.WorkteamArn off each DescribeLabelingJob, and search the results for account 394669845002. Anything that matches is on the MTurk workforce and has 33 days, not 90. That query is a day of work; the remediation is either a WorkteamArn swap to a private team or a procurement cycle, and you need to know which one you are in before you know how much of the rest of this plan you can afford. For complex workloads, engage AWS Support immediately—the custom migration paths require early coordination.
Days 31-60: Architecture and planning. Design the target-state architecture for each workload. For Kendra migrations, validate connector coverage against Bedrock Knowledge Bases before committing to a migration timeline. For Q Business migrations, decide whether to use the BYOI (Bring Your Own Index) path to accelerate user and app migration while deferring data source migration. For Bedrock Agents migrations, test agent configurations in AgentCore in a staging environment.
Days 61-90: Pilot migration. Migrate one lower-complexity workload end to end. Validate performance, functionality, and cost against the baseline. Use the pilot to calibrate estimates for remaining workloads and to surface gaps in your migration plan before they become production incidents. Document what worked and what didn't.
Beyond day 90, execute remaining migrations with the benefit of real migration data rather than estimates. The goal is to be off maintenance-mode services before AWS sets a hard sunset date—because when that date is announced, you'll want your migration already done, not starting. MTurk customers found out what that announcement looks like: 36 days, and no negotiation.
The Abstraction Principle Going Forward
The broader lesson from this wave of AWS retirements is one that applies to every cloud AI platform decision from this point forward.
Enterprises that built applications with clean abstraction layers between business logic and cloud service APIs will have migration paths measured in weeks. Enterprises that wrote directly against Kendra's API, Q Business's API, or Bedrock Agents' API without an isolation layer will have migrations measured in months.
The principle is not new—it's the same argument that has been made about database portability and messaging system lock-in for decades. But the speed of cloud AI catalog rotation makes it more urgent than it has ever been in enterprise software. AWS shipped Bedrock Agents in November 2023. It's in maintenance mode as of June 2026. That's 31 months from launch to end of feature development.
Any enterprise AI application that cannot migrate to a different underlying service within a reasonable engineering sprint is carrying technical debt that compounds with every platform decision. The abstraction layer is not an architecture nicety. It's the hedge against catalog rotation—and the AWS June 2026 update is proof that rotation is accelerating.
What AWS Is Betting On
The consolidated platform AWS is pointing enterprises toward is better than what it replaces. Bedrock Knowledge Bases is more capable than Kendra as an AI-era retrieval system. Amazon Quick is more ambitious than Q Business as an enterprise AI assistant. AgentCore is a more production-hardened execution environment than Bedrock Agents Classic.
If AWS holds this consolidated architecture through the next two re:Invent cycles, the June pruning will read as a calculated strategic bet that traded short-term migration pain for long-term competitive positioning against Microsoft and Google. Enterprises that align their roadmaps with Bedrock, AgentCore, and Quick Suite now will carry less migration debt going forward.
The question is whether AWS maintains commitment to the current generation for long enough to justify the migration investment. The last two years of AWS AI service history suggest the answer requires a hedge, not a bet.
What to Do This Week
The immediate actions are straightforward. Pull the list of production workloads that touch Q Business, Kendra, Bedrock Agents Classic, or any of the nine SageMaker features. Assign engineering owners to each. Flag the ones with complex connector or API dependencies for early AWS Support engagement. Run the 394669845002 search across your flow definitions and labeling jobs before anything else on that list, because it is the only item with a date on it—then send whatever it finds to your own staffing plan or to procurement, depending on volume, the same day. Brief your business stakeholders on the unplanned migration scope.
Most of these services are not going dark tomorrow. One of them is going dark on September 30. Maintenance mode is a one-way door—no new features, no new customers, and a sunset date that will eventually be set, on AWS's calendar rather than yours. The enterprises that treat this week as the start of a structured migration program will have options. The ones that wait for the hard end date will have 36 days.
AWS's June 2026 service availability update is a case study in the velocity of cloud AI platform evolution. The enterprises best positioned to absorb it are the ones that built for portability from the start. The ones most exposed are the ones who trusted that a product launched at re:Invent had a multi-year roadmap. Both lessons apply to every cloud AI decision you're making right now.
Continue Reading
- Your Assistants API Dies Aug 26. Azure's Exit Is Different.
- AWS Agents Run 14 Days. The Session Is the Only Wall.
- RAG Build vs Buy: Buy the Index. Build the Eval Set.
- Best RAG Platforms for Regulated Industries: Permissions First
- AI Vendor Lock-In Crisis: 67% of Enterprises Already Hedged
- AWS Didn't Buy DuckDB. It Hired Its Board Majority.