If your team standardized on Amazon Q Developer, the clock is already running. AWS announced that the IDE plugins and paid subscriptions reach end of support on April 30, 2027. From today, that is about six and a half months away. The date matters less than what the announcement shows: your AI coding assistant is a dependency with a vendor lifecycle, and it can change faster than your cloud contracts.
What AWS actually changed
The timeline is short and specific. On May 15, 2026, AWS blocked new Q Developer Free Tier accounts and new subscriptions. Existing Pro subscriptions can still add users, and existing customers keep plugin access until April 30, 2027, with critical bug fixes continuing in the meantime (per the AWS DevOps blog).
Two weeks later, on May 29, Claude Opus 4.6 was removed from Q Developer Pro. Opus 4.5 and the other existing models stayed, but the newest coding models, including Opus 4.7, are available only on Kiro, according to the same AWS post and a Let’s Data Science summary. The official runway is 12 months, but model access started moving two weeks after the sign-up block.
Not everything goes away. Q Developer in the AWS Management Console and the Slack and Microsoft Teams integration are unaffected. Java and .NET code transformation run through the IDE plugins, though, and stop on the same April 2027 date. AWS recommends finishing in-progress transformations before then and points to AWS Transform for new work.
What Kiro changes about the workflow
Kiro is not a rebrand. It keeps agentic coding, inline chat, terminal integration and MCP support, then adds a different working model built around specs. The Enterprise DNA write-up describes the pieces: a requirements document, design document and task breakdown for each feature, steering files that hold architecture conventions and coding standards, hooks that fire on file saves or commits, and custom subagents for jobs like security review.
For a DevOps team, the useful part is that these are files. Steering rules and hooks can live in the repository, go through code review, and be distributed by policy. The same source reports Kiro is built on Code OSS, so VS Code settings and Open VSX extensions carry over. That is a single source, so confirm it in a pilot before you promise anyone a painless switch.
Why the 12-month window is the wrong number
A Stack Archive analysis argues you should plan around a shorter practical window than the official one. Onboarding, security review and workflow documentation take longer than vendors suggest, and a spec-driven process asks developers to change habits, not just tools. That is the author’s opinion, not measured data, but it is a sensible planning assumption: security review and procurement rarely move at the pace of a vendor deadline.
Waiting has a cost that has nothing to do with the deadline. Because the newest models are Kiro-only, teams that stay on the plugin are already limited to older models.
A migration playbook you can reuse
Treat this as a rehearsal for the next time an AI vendor changes terms. These steps work regardless of which assistant you land on:
- Inventory usage. List who uses the plugin, which repos, which models, and whether anyone depends on Java or .NET code transformation.
- Run a pilot. Put one team on Kiro in parallel with Q Developer and measure onboarding time and review friction, not just completion rates.
- Move the rules into the repo. Coding standards, architecture notes and agent instructions should be plain files that any tool can read, not settings trapped in a vendor console.
- Keep integrations on MCP. Tool access defined through MCP servers survives an assistant swap far better than custom plugins.
- Put the assistant behind your platform. Provision access, policy and audit through your internal developer platform so a change of vendor is a configuration change.
- Set a decision date. Choose a cutoff well before April 30, 2027 and finish any in-flight code transformations before it.
Treat AI tools like any other dependency
We pin library versions, track end-of-life dates for runtimes and write exit plans for databases. AI coding assistants deserve the same treatment, because their pricing, models and support terms are changing on a scale of months. Add them to your dependency register with an owner and a review date.
The question to ask this quarter is simple: if your assistant disappeared in 90 days, how much of your workflow would go with it? If you want help building a platform layer that keeps that answer small, talk to the Luby engineering team.