Field Report ②: A phased migration with zero lines of existing code changed

AI case studies

A core sales-management system. It has run for nearly 20 years, and the business relies on it every day. The OS reached end-of-support long ago, and both the application server and the UI technology are a generation behind. Even so, holding back from a "full rebuild" is an entirely reasonable decision given the scale and the business impact.Field Report ①we chose to "rebuild," but rebuilding is not the best choice for every system. The strategy we took this time was toleave the existing system completely untouched and build a new entry point around it — the so-called strangler pattern.

Existing code changed: 0 lines.

Users → new gateway (newly built) → existing system (unmodified) → existing DB (as is)

• On the existing-system side, we added only athin REST layerthat exposes the internal business logic to outside callers. Not a single line of the existing classes was changed. Because we don't touch it, it doesn't break.
• In front of it we built anew gateway(Java 21 / Spring Boot). Users sign in via SSO with their company business-chat account, and only authenticated requests are relayed to the existing system.
• The screens are rebuilt in a modern style on the new gateway. Both bulk registration and form-based registration run byreusing 100% of the existing system's registration logic.

Contain the risk inside the "newly built layer" and keep the proven business logic exactly as it is. That is the heart of this strategy.

Within days of starting, E2E on the production infrastructure was working.

An AI agent (Claude Code) read the existing system's code, ironed out the internal quirks peculiar to the old framework one by one, and carried the work through the gateway implementation, server setup, and reverse-proxy configuration. As a result,within days of starting, the full path was working end to end — from a public URL, through authentication, to real data being registered by the existing engine. From there we have been adding features screen by screen — search, new registration, and so on.

The nice thing about a phased migration is thatyou can shift screens over to the new side in order of how much they are used. You don't need the large budget, organization, or freeze period of a full rebuild; you can expand the footprint of the "new system" without stopping the business. The strangler pattern itself is a long-established technique, but it was a hard option to get approved because deciphering and implementation both took considerable effort. Because AI made both dramatically faster,a realistic third path has been added to the either/or of "full rebuild or freeze in place".

Are you facing the same situation?

"We have a core system we can't stop." "We can't get a rebuild approved." "At least give us new screens and new authentication." There is a way to renew just the entry point of that system without breaking it.

Series: "Legacy to AI — Field Reports"

• Overview: 22 systems and 246,000 lines on a single PC — a measured record of 3.5 months of AI development
• Field Report ①: Fully modernizing 20-year-old Java in about a week
• Field Report ②: Adding a new entry point to a core system with zero lines of existing code changed (this article)
• Field Report ③: A month-scale architecture study, done with a 2-day prototype + real measurements

* The figures in this article are measured values as of the end of July 2026. Development outcomes vary depending on the state and requirements of the system.