Amazon Q Developer to Kiro Migration: Complete 2026-2027 Deadline Guide

Anastasiia Kuten Marketing & Partnerships Department Manager

May 23, 2026

AWS partner dedicated to startups

• 2000+ Clients
• 5+ Years of Experience
• $10M+ saved on AWS

AWS pulled the plug on Amazon Q Developer in April 2026. You have until April 30, 2027 to migrate to Kiro, the official replacement. That sounds like a lot of time. It is not, especially if your team has Q Developer baked into your IDE plugins, CI/CD pipelines, and security scanning workflows.

This guide walks through everything you need to plan and execute the migration: the exact timeline, what stays and what goes, how to migrate by IDE, what changes for your team’s workflow, and the pitfalls that will catch most teams by surprise.

The Hard Dates You Need to Know

Three dates matter. Miss them and your team has a problem.

If your team has any production dependency on Q Developer, your last possible cutover date is around April 15, 2027. Realistically, you should be fully migrated by Q1 2027 to leave time for issues. Working backward from there, evaluation and parallel running should start no later than Q3 2026.

What Stays and What Goes

This is the part most teams get wrong on first read. Not everything called “Q Developer” is going away.

What’s Going Away

• Amazon Q Developer IDE plugins (VS Code, JetBrains, Eclipse, Visual Studio)
• Q Developer Pro paid subscriptions
• Q Developer Free Tier (via Builder ID in IDE plugins)
• The Q Developer agent CLI
• Any CI/CD or automation that calls Q Developer endpoints

What’s Staying

• Amazon Q Developer in the AWS Management Console (the chat experience on AWS pages)
• Amazon Q Developer in AWS documentation
• The AWS Console Mobile App’s Q Developer integration
• Q Developer for Slack and Microsoft Teams (Chat Apps)
• Q Developer for AWS Marketing website

So if you only use Q Developer to ask questions in the AWS Console or get help in Slack, you do not need to do anything. The migration only affects teams using the IDE plugins or paid subscriptions.

What Kiro Brings Forward From Q Developer

Kiro is the official successor and inherits most of what made Q Developer useful, with some genuine upgrades. If you want the full feature overview, see our complete guide to Kiro.

The Q Developer capabilities Kiro retains:

• Agentic coding (multi-step task execution, file editing, command running)
• Inline chat (talk to the AI inside your code)
• Terminal integration (run commands from the agent)
• MCP support (Model Context Protocol for external tool access)
• AWS-aware code generation (CDK, CloudFormation, Lambda patterns)

What Kiro adds on top:

• Spec-driven development (structured requirements before code)
• Agent hooks (event-driven automations)
• Steering files (persistent project context)
• Access to the latest Claude Opus 4.7 with adaptive thinking
• IAM Policy Autopilot for least-privilege policy generation
• Cloud Agent for delegating work to a fully autonomous remote agent

Migration Path by IDE

Your migration looks different depending on which IDE your team uses. Kiro does not support every IDE that Q Developer did.

For Eclipse and Visual Studio shops, this is a real disruption. AWS has explicitly said it has no plans to build Kiro plugins for those IDEs. Your realistic options are:

1. Adopt the Kiro IDE (a VS Code fork) for AI-assisted work, while keeping Eclipse/Visual Studio for traditional editing
2. Use Kiro CLI for terminal-based AI workflows, alongside your existing IDE
3. Evaluate Claude Code on AWS (via Bedrock) or other tools as alternatives

If your enterprise has standardized on Eclipse or Visual Studio for compliance, security, or licensing reasons, plan for additional change management time.

The Migration: Step by Step

This is the practical sequence for a typical 10 to 200 engineer team migrating from Q Developer Pro to Kiro Pro. Adjust timelines based on your size.

Phase 1: Discovery and Inventory (Weeks 1 to 2)

Before you change anything, document what you have. The biggest source of failed migrations is discovering Q Developer dependencies you did not know existed.

Audit checklist:

• How many Q Developer Pro seats does your organization have today?
• Which teams and individual engineers use Q Developer actively (not just have a license)?
• Which IDEs are in use? Run a survey if you do not know.
• Are there any CI/CD pipelines, GitHub Actions, or automated workflows calling Q Developer?
• Are there custom Q Developer configurations: prompt customizations, project-specific instructions, organizational guardrails?
• Which AWS accounts have Q Developer subscriptions and who owns the billing?
• Are there security scanning workflows that rely on Q Developer (code review, vulnerability detection)?

Output of this phase: a written inventory document that lists every place Q Developer touches your organization. Without this, you cannot scope the migration accurately.

Phase 2: Pilot Program (Weeks 3 to 6)

Pick a small team (5 to 10 engineers) to pilot Kiro in production for one month. Choose a team that:

• Currently uses Q Developer actively (not just nominally)
• Works on a project that can absorb some workflow disruption
• Has at least one senior engineer who can champion the change
• Uses an IDE Kiro supports (VS Code or JetBrains, not Eclipse)

During the pilot:

1. Sign engineers up for Kiro Free or Pro plans
2. Install the Kiro IDE alongside their current setup
3. Have them work normally for one week, just to get familiar
4. Introduce spec-driven development on a real feature in week two
5. Track time saved, blockers hit, and quality differences (bug rates, review time)
6. Document the issues your team actually runs into

The pilot’s goal is not to prove Kiro is better. It is to understand what your team will struggle with and what training they will need before a wider rollout.

Phase 3: Standards and Documentation (Weeks 5 to 8, in parallel with pilot)

While the pilot runs, prepare your organizational rollout:

• Pick the right Kiro plan tier per role. Most engineers need Pro at $20/month. Active power users may need Pro+ at $40/month. Specialized senior engineers running parallel agents need Power at $200/month.
• Choose authentication. AWS Builder ID for individuals. IAM Identity Center for enterprise teams wanting SSO, MFA, and central control.
• Write internal Kiro guides. How to install, how to authenticate, how to use spec-driven development on your codebases, internal best practices.
• Set up steering files for your main codebases. These persist project context. Templates: coding standards, libraries to prefer, architectural patterns, things to avoid.
• Plan training sessions. Spec-driven development needs 1 to 2 hours of facilitated training, not just documentation.
• Update internal AI usage policies. Confirm what code can be sent to Kiro, what cannot, and how to handle proprietary or regulated data.

Phase 4: Gradual Rollout (Weeks 9 to 20)

Migrate teams in waves, not all at once.

Wave 1: Early adopter teams (the engineering equivalent of users who actually read release notes). These are teams already curious about AI tools who will provide useful feedback to the rest of the org.

Wave 2: Standard engineering teams. By this point, you have refined onboarding and have answers to common questions.

Wave 3: Teams with complex dependencies (security tooling, custom integrations, Eclipse/Visual Studio shops).

Wave 4: Stragglers and edge cases. Holdouts who actively dislike change, teams in regulated industries with extra approval cycles.

For each wave:

1. Send an announcement 2 weeks before migration with installation instructions and training schedule
2. Hold one mandatory 1-hour training session on spec-driven development
3. Have engineers install Kiro and authenticate. Keep Q Developer installed in parallel.
4. Designate one Kiro champion per team for the first month to handle questions
5. Track adoption metrics: % of team actively using Kiro, % of code authored with Kiro assistance, blockers reported

Phase 5: CI/CD and Automation Migration (Weeks 12 to 20)

If you have CI/CD pipelines or automated workflows that call Q Developer (security scans, code reviews, documentation generation), these need their own migration plan.

Kiro CLI’s headless mode (added April 2026) is the migration target for most of these. Examples:

# Old: Q Developer in a CI step
- name: Run Q Developer security scan
  run: q-developer scan --target ./src

# New: Kiro CLI in a CI step
- name: Run Kiro security review
  run: kiro review --workspace . --task security-audit

For each Q Developer automation, write the Kiro equivalent, test in a staging branch, and only switch over once you have confirmed parity. Do not migrate automations and engineers simultaneously. You will lose the ability to tell which side broke.

Phase 6: Decommissioning Q Developer (Weeks 16 to 24, ending by April 30, 2027)

Once each team is fully on Kiro, decommission Q Developer for that team:

1. Confirm all engineers on the team have Kiro working for one week without issues
2. Remove Q Developer plugins from team-shared workspace configurations
3. Reduce Q Developer subscription seats to match remaining active users
4. After all teams migrate, cancel the Q Developer subscription entirely

If you cancel Q Developer subscriptions before April 30, 2027, you save money. Just confirm there are no remaining users or automations depending on it.

Cost Comparison: Q Developer vs Kiro

Direct cost comparison for a typical team of 20 engineers, half active users.

For most teams, Kiro will cost the same or somewhat more, especially if you have power users on the Power plan. The trade-off is access to better models, more features, and the spec-driven workflow that may reduce technical debt over time.

If cost is a hard constraint, plan tier mix carefully. Most engineers do not need Power tier ($200/month). Reserve it for senior engineers running parallel agents on complex projects. Most can be productive on Pro ($20/month).

Common Pitfalls and How to Avoid Them

Pitfall 1: Underestimating the Workflow Change

Spec-driven development is not just a UI difference. It is a workflow change. Engineers used to typing prompts and getting code will find Kiro’s spec-first approach slower at first.

Mitigation: mandatory training session, allow Quick Plan mode for small tasks, set expectation that productivity may dip for 1 to 2 weeks before improving.

Pitfall 2: Forgetting About Eclipse and Visual Studio Users

If your organization has Java teams on Eclipse or .NET teams on Visual Studio, Kiro will not work the same way for them. AWS has no plans to support those IDEs.

Mitigation: identify these teams in Phase 1 inventory. Plan a parallel evaluation of Kiro IDE, Kiro CLI, Claude Code, or other tools for them. Budget extra time and possibly extra tool licenses.

Pitfall 3: CI/CD Pipelines Breaking on April 30, 2027

Q Developer integrations in build pipelines, security scans, or PR automation will silently stop working when the service ends. Some teams will not notice until builds start failing.

Mitigation: grep your CI/CD configurations for “q-developer”, “amazon-q”, “qdev” in Phase 1. Document every reference. Migrate to Kiro CLI in Phase 5 well before the deadline.

Pitfall 4: Custom Q Developer Configurations Lost

If your organization invested in custom Q Developer prompts, project-specific guidance, or organizational guardrails, these do not transfer automatically to Kiro.

Mitigation: document customizations in Phase 1. Recreate them as Kiro steering files in Phase 3. Test in pilot before rolling out broadly.

Pitfall 5: Treating Kiro Like a Vibe-Mode Q Developer

Some engineers will install Kiro and immediately use it like Q Developer (freeform chat, no specs), missing the entire point. They will report no productivity gain and recommend rolling back.

Mitigation: training emphasizes spec-driven workflow for non-trivial work. Quick Plan mode is positioned as a fallback for small tasks, not the default. Champions on each team enforce best practices in the first month.

Pitfall 6: Running Out the Clock

April 30, 2027 feels far away in May 2026. It is not. Twelve months is the minimum a typical enterprise needs for a clean migration with proper change management.

Mitigation: start Phase 1 (inventory) within 30 days of reading this. The earlier you start, the more time you have to handle the unexpected.

Should You Stay on Q Developer Until 2027 or Migrate Now?

You have a choice: migrate now while you have time, or stay on Q Developer and migrate at the deadline. The trade-offs:

For most teams, migrating in Q3 or Q4 2026 hits the sweet spot. Kiro will have had a year of refinement since launch, you have 6 to 9 months of runway before the deadline, and you get access to the newest models earlier.

For Eclipse or Visual Studio shops, migrate earlier. You have more decisions to make and may need to evaluate alternatives.

Frequently Asked Questions

Can I keep using Amazon Q Developer after April 30, 2027?
No. After that date, the IDE plugins and paid subscriptions stop working. Q Developer experiences in the AWS Console, Slack, and Teams continue, but the IDE-based product is gone.

Do I have to migrate to Kiro, or can I pick another tool?
You can pick any tool. Kiro is the official AWS migration path, but Cursor, Claude Code, GitHub Copilot, and Windsurf are all valid alternatives. The decision depends on your team’s needs.

Will my Q Developer subscription auto-convert to Kiro?
No. They are separate products with separate billing. You need to manually sign up for Kiro and pick a plan. AWS has offered a $20 first-upgrade credit to soften the transition.

What happens to Q Developer customizations and configurations?
They do not transfer to Kiro automatically. Document customizations before migration and recreate them as Kiro steering files.

Does Kiro work with my Q Developer chat history?
No. Chat history is not transferred between products. If you have important conversation history, export it before April 2027.

What if I use Q Developer in JetBrains or Eclipse?
JetBrains users can switch to the Kiro IDE (VS Code based) or use Kiro CLI. Eclipse and Visual Studio users have no Kiro plugin and need to either adopt the Kiro IDE alongside their existing tooling or evaluate alternatives.

Will my CI/CD pipelines break when Q Developer ends?
Yes, if they depend on Q Developer. Audit your pipelines now and plan to migrate them to Kiro CLI (in headless mode) before April 30, 2027.

Is the Q Developer experience in the AWS Console going away?
No. Only the IDE plugins and paid subscriptions are deprecated. Q Developer in the AWS Console, AWS documentation, AWS mobile app, Slack, and Teams continues working.

How much will Kiro cost compared to Q Developer Pro?
Roughly the same for baseline use (around $20/user/month). Higher for power users on Pro+ ($40) or Power ($200) plans. Variable based on credit consumption with premium models.

Can I run Q Developer and Kiro in parallel during migration?
Yes, and you should. Install Kiro alongside Q Developer for a few weeks while teams transition. This minimizes risk and lets engineers fall back to Q Developer if they hit issues with Kiro.

Summary: Your Migration Checklist

If you take nothing else from this guide, take this checklist:

1. By June 2026: Complete a full inventory of Q Developer usage across your organization (Phase 1)
2. By August 2026: Run a pilot program with 5 to 10 engineers (Phase 2)
3. By October 2026: Standards, training materials, and steering files ready (Phase 3)
4. By December 2026: First wave of teams migrated (Phase 4 starts)
5. By February 2027: CI/CD and automations migrated (Phase 5)
6. By April 2027: All teams migrated, Q Developer decommissioned (Phase 6 complete)

This timeline leaves a 30-day buffer before the April 30, 2027 deadline.
Compress it at your own risk.