Amazon Q Developer, IDE end of support and the move to Kiro

Amazon Q Developer, IDE end of support and the move to Kiro

Amazon Q Developer is the AWS AI assistant that suggests code, scans it for vulnerabilities, and modernises legacy Java and .NET applications. Since 15 May 2026 you cannot create a new account or buy a new subscription, and the IDE plugins together with paid plans reach end of support on 30 April 2027. The successor is Kiro.

What ends and what stays

The sunset covers the developer half of the product, not all of it. That distinction matters, because teams using Amazon Q only inside the console have nothing to do.

Existing Pro subscriptions still accept new users until support ends, so a team on an active plan can keep adding people. Starting a subscription from scratch is no longer possible.

The timeline to put in your calendar

Three dates decide when to schedule the migration.

15 May 2026 closed signups. Free accounts and new subscriptions stopped being available, so no organisation can adopt the tool from scratch any more. One exception matters: an organisation holding an active Pro subscription can keep adding users to it until support ends, so a growing team is not forced into an emergency migration.

29 May 2026 removed the Opus 4.6 model from the Pro plan. Opus 4.5 and every other existing model stayed, while the newest ones, Opus 4.7 among them, are available only in Kiro. Teams that had tuned their workflow around one specific model felt this as a change in answer quality rather than an outage.

30 April 2027 ends support for plugins and paid plans. After that date, code transformations launched from the IDE stop being available, so any modernisation in flight has to finish earlier.

It also pays to check whether some team has built automation on the plugin that the rest of the organisation knows nothing about. Scripts calling the assistant from a terminal, or pipeline steps added by one person two years ago, stop working along with support, and they are rarely on anybody's dependency list.

A year sounds generous, but replacing a tool used by an entire engineering group rarely fits into one sprint. A sensible plan pilots one team in the first quarter and completes the switch at least six months before the deadline.

What still works in the AWS Console

The console version stays, and it helps to know what it is good for, because it is a different tool from the editor plugin. It answers questions about AWS services from the documentation, explains CloudWatch error messages, and helps establish why a function cannot reach a database.

A typical scenario: a Lambda inside a VPC fails to connect to RDS and the log shows a connection timeout. Amazon Q in the console inspects the security group configuration and points out that the inbound rule on port 5432 does not cover the group attached to the function. You get the diagnosis without clicking through four screens.

The second thing the console version handles well is questions about service costs and limits. Instead of digging through the pricing page, you ask directly what a given NAT Gateway setup costs to run, or what the default Lambda concurrency limit is in a region. The answer comes from the documentation, so it holds up for a design decision, though the actual bill still needs watching in Cost Explorer.

The limitation is that the assistant sees your account configuration, not your application code. Writing code needs a tool in the editor, which from 2027 means Kiro or something outside the AWS ecosystem.

Kiro, the successor for the IDE and terminal

Kiro is an agentic environment built around working from a specification. Instead of single inline suggestions, the starting point is a description of the change, from which the tool plans the work, applies it across many files, and verifies the result.

For migration purposes, what counts is that Kiro takes over the features teams actually used in Q Developer: agentic coding, in editor chat, terminal integration, and Model Context Protocol support. That last one decides how easily you connect your own data sources, since MCP server configuration looks the same as in every other compliant tool.

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"]
    }
  }
}

Kiro ships as an editor and as a CLI, so terminal automation scenarios survive. If you have worked in Cursor or with Claude, the workflow will feel familiar: describe the task, review the plan, apply a series of changes, read the diff.

The terminal side of the transition was designed not to require swapping everything at once. New settings land in a home directory under their own name, while the tool keeps reading the old project configuration directory.

~/.kiro/settings/mcp.json   # MCP servers
~/.kiro/steering            # steering rules
~/.kiro/agents              # custom agents
~/.kiro/prompts             # custom prompts

The existing q and q chat commands keep working alongside the new kiro-cli, and the .amazonq directory in a repository is still read, so rules and MCP server settings stored in a project need no immediate move. That takes the pressure off the migration: scripts and build pipeline steps can be rewritten gradually rather than over one weekend.

Migration step by step

Start with an inventory, because the most common reason a migration drags on is that nobody knows who uses what.

First, check in the console how many users hold a Pro subscription and which of them signed in during the last quarter. Licences unused for months are the first line item to cut, migration or not.

Second, list the processes that depend on the plugin: Java transformations, .NET porting, security scanning in the pipeline. Scanning usually moves to another tool within a week, transformations have to finish in the old one.

Third, move your context configuration. Project rules that Q Developer read from a repository file map to specifications and steering rules in Kiro. This is a good moment to review them instead of copying, since some entries have usually gone stale.

Steering rules live in a .kiro/steering directory in the repository, and a header at the top of each file decides when that rule gets loaded.

---
inclusion: fileMatch
fileMatchPattern: "src/api/**/*.ts"
---

Every route validates its input against a schema before touching the database.
Errors are returned in one shape, described in docs/errors.md.

Split the rules rather than dumping everything into one always loaded file. A rule about API routes need not occupy context while you work on a stylesheet, and on a large repository that difference shows up in both cost and answer quality.

Fourth, run a pilot with one team and two weeks of real work. Compare code review time and the number of rejected suggestions. Only then widen the rollout.

Pricing before and after

The Pro plan raises limits rather than removing them: agent interactions still have a ceiling, and the line of code allowance for Java upgrades is pooled at the payer account level. A hundred subscriptions add up to 400,000 lines per month, and every line beyond that costs 0.003 USD. On the free plan there is no overage to buy, so once you pass 1,000 lines you have to split the project into smaller modules.

When budgeting for the successor, count more than the licence price. Usage billed agentic tools can cost more than a flat per seat fee if the team runs long tasks on a large repository. Measure that during the pilot, before signing an annual contract.

Amazon Q against other assistants

The deciding factor is rarely suggestion quality any more, since the leading tools have converged there. What decides is where the code lives, which models your security team allows, and whether you need an agent in the terminal.

Java and .NET transformations in flight

This is the one item that cannot wait. Java modernisation from 8, 11 and 17 to 17 or 21, dependency refreshes within Java 21, and porting .NET Framework applications to modern .NET all run exclusively through the plugin with a paid subscription. Java upgrades themselves work only in VS Code and JetBrains IDEs, and the project has to build with Maven.

A practical order: start with services that have the fewest external dependencies, because transformation runs cleanest there and gives the team a reference point. Budget review time for each one, since the tool raises the version and rewrites API calls but knows nothing about the business context behind tests that stop passing.

If you cannot cover the whole application portfolio by April 2027, AWS points the remainder at AWS Transform. The Windows and .NET modernisation agent is free there today, while custom transformations, Java version upgrades included, cost 0.035 USD per agent minute, counted only while the agent actually analyses or edits code. Builds and tests running on your own machine are not billed. Do that arithmetic now, because a single large monolith can take a quarter on its own.

What replaces security scanning

Code scanning was one of the stronger sides of Q Developer, because it worked without configuration and caught hardcoded secrets, injectable SQL queries, and overly broad IAM policies. Once the plugin is disconnected, that control leaves with it, so plan the replacement for the same sprint in which you uninstall the extension.

The simplest path moves the control from the editor into the pipeline. A scanner running on every commit catches secrets, a package manager audit reports vulnerable dependencies, and a template analyser checks CloudFormation and CDK for infrastructure mistakes. Three separate steps instead of one, but independent of whichever editor the team happens to use.

- name: Dependency scan
  run: npm audit --audit-level=high

- name: Infrastructure scan
  run: cfn-lint template.yaml

The practical difference is when you find out. The plugin flagged a problem while you typed, the pipeline reports it after you push. For the team that means a longer feedback loop, worth shortening by running the same commands in a pre commit hook.

Review the rules you relied on deliberately. If scanning rejected specific patterns, access keys in configuration files for example, write them down as rules for the new tool rather than assuming the default configuration covers the same ground.

Common migration mistakes

The first is treating April 2027 as a start date. Support ends then rather than beginning, so the plan needs slack for permission problems and for team resistance.

The second is migrating without measurement. With no baseline from before the change, every discussion about whether the new tool is better ends in trading opinions. Three numbers suffice: time from ticket to deployment, number of review comments, and monthly cost per person.

The third is leaving old keys and permissions behind. Once the plugins are disconnected, review the IAM roles created for the integration and delete the ones nobody uses.

The fourth concerns security scanning in the pipeline. If the scanning step disappears along with the plugin and nobody adds a replacement, the project loses a control the team has already forgotten about, because it ran quietly for two years.

FAQ

Does Amazon Q Developer stop working entirely?

No. Support ends for IDE plugins and paid subscriptions on 30 April 2027. Amazon Q in the AWS Console, in the documentation, in the mobile app, and in Slack and Microsoft Teams continues unchanged.

Can I still buy a Pro subscription?

New subscriptions cannot be created since 15 May 2026. If your organisation holds an active Pro plan, you can keep adding users to it until support ends.

How does Kiro differ from Amazon Q Developer?

Kiro works from a specification: you describe the change, the tool plans it, applies it across multiple files, and then checks the result. Q Developer was closer to a classic editor assistant with inline suggestions and chat. Kiro takes over agentic coding, chat, terminal integration, and MCP support.

What about Java modernisation after April 2027?

Transformations launched from the plugin stop being available, so migrations already started must finish before that date. AWS points the rest of the portfolio at AWS Transform, billed per agent minute, or at manual work, which is worth building into the 2026 plan.

Does migrating mean changing editors?

Kiro is a separate environment, but it also ships a CLI, so part of the work stays in the terminal. The alternative is leaving the AWS ecosystem for Copilot, Cursor, or Aider, if model choice matters more to the team than cloud integration.

The official announcement sits on the AWS blog, and the transition guide in the Kiro documentation.