Amazon Q to Kiro: Complete Migration Playbook

Amazon Q Developer is being sunset: new signups were blocked on May 15, 2026, and the full IDE plugin and subscription end-of-support date is April 30, 2027. For the thousands of developers using Q daily, the question is not whether to migrate to Kiro but how quickly and how much it will change their workflow.

The answer depends almost entirely on which IDE you are coming from. CLI users get backward compatibility and a config auto-copy. VS Code users get a near-identical Code OSS environment. JetBrains users get a functional path via ACP. Visual Studio and Eclipse users are being re-platformed — there is no native Kiro plugin for either IDE. This is not a cosmetic rename: Kiro is built from scratch around spec-driven development, with primitives (Specs, Hooks, Steering, custom subagents, Powers) that have no equivalent in Q Developer.

This playbook covers the three discrete deadline dates and what each one breaks, the Q-to-Kiro architectural shift in plain terms, a migration severity ladder by IDE and CLI, the tier and credit math for every pricing tier, and the license change that enterprise teams should be flagging now. All facts are sourced from the AWS DevOps Blog announcement, the Kiro Migration Guide, and the Kiro CLI Migration Guide.

Most coverage reduces the migration to one line: "you have 12 months to transition." That framing misses two earlier dates that affect existing users immediately. The AWS DevOps Blog announcement from April 30, 2026 specifies three discrete milestones.

The practical planning implication: May 29, 2026 is the more urgent date for enterprise Q Developer Pro subscribers using Opus 4.6 in coding workflows. If your team relies on that model, you have roughly two weeks from today (published May 16) before that access closes. April 30, 2027 is the absolute deadline — but waiting until late 2026 to start a migration that may require re-platforming an IDE for part of your team is a poor risk posture.

Q Developer was an AI assistant layered into your IDE: inline completions, a chat panel, an agent mode that could traverse your codebase. All of these were enhancements to the conventional prompt-response loop. Kiro, per the official launch blog, is "an agentic development environment built from the ground up for spec-driven development." That sentence means the architecture is inverted: planning — not prompting — is the entry point.

Type "Add a review system for products" and Kiro generates three structured files automatically: requirements.md (user stories in EARS notation — Easy Approach to Requirements Syntax), design.md (data flow diagrams, TypeScript interfaces, API endpoint definitions), and tasks.md (sequenced sub-tasks with dependencies, each linked back to specific requirements). The agent then executes against those specs, not against the raw prompt. For a deeper look at Kiro's full feature set, see our complete Kiro deep dive.

The migration mental model shift is worth articulating clearly. Q Developer users who move to Kiro and continue working with bare prompts are using Kiro below its design intent — they will get comparable output to what they had with Q, but none of Kiro's differentiated value. The productivity gain from Kiro's spec workflow is real, but it requires adopting specifications as the atomic unit of work. For teams that use Claude Code's subagent and skill primitives or Cursor 3's agent-first architecture, the conceptual jump is smaller than it looks.

The single most important factor in your migration effort is which IDE you are coming from. The table below is assembled from the Kiro Migration Docs and the CLI Migration Guide. No other publication has assembled these five paths into a single severity comparison.

The severity ladder reveals a clean split: if you are in the VS Code ecosystem (including Cursor, which is also Code OSS-based), the migration is a near-drop-in. If you are on JetBrains, you have a functional path but need to configure the ACP bridge and accept some feature gaps. If you are on Visual Studio or Eclipse — both common in enterprise .NET and Java shops — you are being re-platformed, full stop.

Q Developer had two tiers: Free (50 agentic requests per month, Claude models in IDE/CLI) and Pro ($19/month, 4,000 LOC Java transformation, admin dashboard, IP indemnity). Kiro launches with four individual tiers plus Enterprise. The credit-based model is new — Q Developer used request counts, Kiro uses credits with an overage rate.

The pricing migration math is nuanced. At face value, Q Developer Pro at $19/month for 50 agentic requests looks cheaper than Kiro Pro at $20/month for 1,000 credits. But credits and agentic requests are different units — a single agentic coding task may consume multiple credits depending on model and task complexity. Teams running heavy agentic workloads may find that Kiro Pro's 1,000 credits per month is roughly comparable to Q Pro's request allotment at current usage patterns, but this warrants monitoring during the first billing cycle after migration. The overage model ($0.04/credit) also introduces variable cost risk that Q Developer Pro did not have.

Q Developer CLI was licensed under Apache 2.0 — a permissive open-source license that allowed redistribution, modification, and use in proprietary products without significant restriction. The Kiro CLI carries an AWS Intellectual Property License. This is a material change in redistribution rights, patent terms, and IP clauses that has gone almost entirely unreported in trade coverage. The only public disclosure is a brief note in the Kiro CLI Migration Guide.

For individual developers, the practical impact is minimal — you are using the CLI as an end-user tool, not redistributing or embedding it. For enterprise teams that have vendored Q CLI into internal toolchains, CI/CD pipelines, build systems, or internal distribution mechanisms, the license change requires a compliance review before migration. The AWS Intellectual Property License is not an open-source license in the OSI sense. Standard enterprise software procurement and legal review processes apply.

The Kiro CLI migration is genuinely low-friction for most users. The CLI was effectively renamed from Q CLI on December 15, 2025, and the backward compatibility commitments in the CLI migration guide are specific and verifiable.

For teams that work primarily in the terminal — CI pipelines, remote servers, headless environments — Kiro CLI is the lowest-disruption migration target in the entire Q Developer ecosystem. The license change (covered in Section 05) is the only material compliance consideration. For peer CLI agent comparisons, see our guide to how Codex CLI handles config and sandboxes.

Q Developer offered native IDE plugins for Visual Studio (the Microsoft IDE, not VS Code) and Eclipse. Kiro has no native plugin for either. Per the Kiro Migration Docs, the options for these users are:

1. Switch to Kiro IDE — a Code OSS-based desktop application. For .NET developers on Visual Studio, this means leaving the Visual Studio ecosystem entirely and adopting a VS Code-family IDE. All .NET project structures, build systems, and debuggers work in VS Code-family editors, but the IDE muscle memory, tooling integrations, and enterprise extensions are different.
2. Run Kiro CLI alongside the existing IDE — keep Visual Studio or Eclipse as the primary editing environment and use Kiro CLI for agentic tasks in the terminal. This preserves the existing IDE but limits Kiro usage to terminal-based interactions and loses the in-IDE spec-driven workflow entirely.

Neither option is a clean migration for Visual Studio or Eclipse power users. AWS has not announced a native plugin roadmap for either IDE, and none of the third-party coverage or Kiro roadmap materials seen as of May 2026 suggest one is planned.

The Q Developer sunset is not a retreat from the developer tools market. It is a repositioning. As noted by Guille Ojeda of Caylent (an AWS Premier Partner) in their Kiro first impressions review: "What sets Kiro apart from competitors like Cursor or GitHub Copilot isn't its model choice, but its architectural philosophy. While Cursor excels at project-wide context awareness and Copilot focuses on inline assistance, Kiro positions itself as an autonomous project lead." That framing maps directly onto AWS's competitive positioning.

The market AWS is targeting is the gap between two-minute Copilot completions and multi-day agentic coding projects. Cursor 3 and Claude Code both operate in the agentic space but are primarily prompt-driven — you describe what you want and the agent executes. Kiro bets that the spec-driven model (requirements → design → tasks → execution) produces more predictable, auditable, and production-ready outputs for projects of non-trivial scope. The EARS notation and the three-file spec artifact are architectural choices that make the agent's planning legible and reviewable in a way that an inline chat window is not.

The broader signal from the Kiro launch — covered in depth by InfoQ's spec-driven agent coverage — is that AWS is treating Kiro as its long-term bet on the IDE layer of the AI development stack, not a temporary Q Developer replacement. The Code OSS base, the CLI backward compatibility, and the JetBrains ACP support all suggest a product intended to serve developers across the ecosystem, not just AWS cloud users.