The problem
Moving a fleet of applications from Tomcat 9 and Java 8 to Tomcat 10.1 and Java 21 involves more than changing a runtime version. Older frameworks, shared libraries and differences in application behaviour all need attention.
Repeatedly solving those problems by hand would make each application another isolated migration. I wanted the tooling to improve as it encountered new cases.
What I built
I created a Python-based pipeline that coordinates AI-assisted code transformations, builds, deployment checks, browser checks and functional verification. When a stage fails, the workflow collects evidence and attempts a repair.
- 01Inspect the application and its dependencies
- 02Transform code and update the runtime
- 03Build, deploy and check application startup
- 04Exercise browser behaviour and functionality
- 05Investigate failures, repair and repeat
What made the approach useful
I treated failures as inputs to improving the migration tooling. Recurring problems became reusable transformations or checks, with regression tests to prevent the same gap from reappearing.
The work combined framework and library changes with runtime diagnosis, browser-based verification and deployment planning. I remained responsible for the architecture, acceptance criteria and release decisions.
The result
By October 2026, I had used the pipeline to migrate code for 18 applications and 11 shared libraries. Applications were progressing through build verification, integration, testing and delivery, with production releases managed separately.
The pipeline made migration steps repeatable and left a body of automated checks that could be applied to subsequent applications.
A useful first engagement: assess one application, identify the migration risks and prove a bounded upgrade with agreed acceptance checks before expanding the scope.