Amazon's clearest software-factory case is a fleet-wide maintenance job. Amazon Q Developer analyzed older Java applications, planned an upgrade, changed dependencies and code, built and tested the result, and returned a reviewable diff. Amazon reports very large savings, while the exact product that performed the work is now being retired.
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.
Is Amazon Q Developer still the current product?
No. In an April 2026 end-of-support announcement, AWS said new Q Developer IDE accounts and subscriptions would stop in May 2026. The IDE plugins and paid subscriptions, including Java and .NET code transformation, are scheduled to reach end of support on April 30, 2027.
AWS directs new Java modernization work to AWS Transform custom and directs general agentic development to Kiro. Existing eligible customers can continue using Q Developer during the transition. The historical factory result remains useful, but readers should not treat Q Developer Code Transformation as Amazon's long-term product direction.
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.
What can a product team copy?
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.