Amazon used Q Developer to upgrade Java across tens of thousands of production applications. The system analyzed each application, planned and attempted an upgrade, ran checks, and returned the changes for review. Amazon's reported savings make this a useful case for examining both the scale of automated maintenance and the assumptions behind time-saved estimates.
What was Amazon Q Developer's Java migration workflow?
Amazon built Code Transformation to move Java 8 and Java 11 applications to Java 17. Its 2023 launch account describes three broad stages.
First, the service analyzes the application in a managed environment and creates a project-specific transformation plan. It inspects dependencies, deprecated APIs, and build requirements. Next, it updates dependencies and source code. Finally, it builds the transformed application, runs available tests, and returns the changed files, summary, and build results for a developer to review.
The result can be successful or partial. A partial transformation may contain useful updates even though the application does not compile yet. A developer still decides whether to accept, repair, and commit the changes.
This is a migration line rather than open-ended feature development. The target state, Java 17, is known in advance. Compilation and existing tests provide useful proof. Similar applications can enter the same workflow at fleet scale.
What internal scale did Amazon report?
The launch article says an internal Amazon team of five upgraded 1,000 production applications in two days. It reports an average of about ten minutes per application and says the longest took less than an hour.
A later AWS milestone article says Amazon used Q Developer to migrate tens of thousands of production applications. AWS estimated that the work avoided more than 4,500 developer-years and produced performance improvements worth $260 million per year.
These numbers are Amazon's self-reported estimates. The 2024 article says the time-saved estimate was based on the number of Java dependencies migrated and a typical manual time of a day or more per dependency. It is not a randomized or independent productivity study.
The public milestone material does not disclose the full mix of application size, dependency complexity, test coverage, or manual work behind the portfolio. The early throughput example should therefore not become a forecast for every difficult legacy application.
What did the agent automate, and what stayed with people?
The transformation agent automated discovery, plan generation, dependency changes, deprecated-code repair, compilation, and available tests. The managed build environment gave each attempt a consistent place to run.
People still selected the application, reviewed the plan and diff, handled partial transformations, assessed behavior not covered by tests, and committed the result. Existing tests constrained what the workflow could prove. A compiling application can still behave incorrectly, and an application with weak tests leaves more risk for review.
The public material does not report how many attempted applications failed, how many partial transformations people completed, how many changes were reverted, the defect rate after release, or total review attention.
What product transition did AWS announce?
In an April 2026 end-of-support announcement, AWS said new Q Developer IDE accounts and subscriptions would stop in May 2026. The announcement scheduled end of support for the IDE plugins and paid subscriptions, including Java and .NET code transformation, for April 30, 2027.
The announcement directed new Java modernization work to AWS Transform custom and general agentic development to Kiro. It allowed eligible customers to continue using Q Developer during the transition. The migration case illustrates a repeatable workflow; use AWS's product documentation to choose a tool for a new project.
Why is this still a useful software-factory case?
The migration had a standard destination, many candidate applications, a repeatable plan, a managed execution environment, executable proof, and a human acceptance point. It converted a maintenance portfolio into a queue of comparable work units and let a small team oversee much more execution.
The product transition adds another lesson. A factory architecture should preserve task specifications, validation rules, migration records, and source-control history outside any one model or vendor surface. The line needs to survive a tool replacement.
How should a team evaluate a migration campaign?
Choose a costly maintenance campaign with a clear target version and a reliable build. Segment applications by complexity before making a throughput forecast. Generate a visible plan. Run compilation and tests in a controlled environment. Return partial work with exact failure evidence. Track attempts, accepted migrations, manual completion, review time, defects, operating savings, and tool-transition risk.
Report easy and difficult cohorts separately. A dramatic result from selected simple applications should not become the forecast for every legacy system.