Open a Window or Move House? Making Sense of Legacy Modernization with a Two-Story House

Legacy modernization, legacy migration, replatform, re-architect... with so many terms in circulation, it is easy to get confused. For a while I could not tell them apart either: should an old system be renovated in place, or moved wholesale onto a new platform? Two "two-story house" analogies eventually made the distinction click for me.

Example one: leave the house alone and just cut a window in the street-facing wall

I have a two-story house. The second floor is living space; the first floor, since you do not have to climb stairs to reach it, works basically as a storeroom for the household supplies I have bought. Lately I have been thinking about cutting a small window in the first-floor wall that faces the street, turning the storeroom into a little shop and selling to the neighborhood.

The house stays the same house: the foundation, the load-bearing walls, the way we live on the second floor — none of it moves. I just cut one window in the wall so that the storeroom, which used to be accessible only to the family, opens to the neighborhood in a controlled way.

In software architecture this is called Modernization, and the specific approach is close to Replatform (partial rework, a shim layer) or Refactor / Encapsulate. The technical parallel is easy to see: the bank's old COBOL core on the mainframe stays put; you wrap a layer of microservices or an API Gateway around it, and a mobile app can call the account balance in the old system and launch online services.

The upside is low cost and quick results: the core assets are untouched, yet the old system starts producing business value again. The limit is just as clear. However big you make the window, the house is still that house; how many customers it can serve and how much weight it can bear depend on the original foundation and load-bearing walls.

Example two: move to the CBD and redesign for live-work

Same two-story house — but I decide the city's CBD is better, so I plan to move. This time I cannot keep the old arrangement of goods on the first floor and people on the second; from the start I have to plan for doing business and living under one roof.

This is Migration in the stricter sense. In reality you leave the old plot entirely — in technical terms, you leave the old servers and the old architecture's environment for somewhere with more resources and more modern infrastructure, such as the public cloud or SaaS. Designing the new site as live-work from day one amounts to redesigning the architecture around the new business.

There is another layer here. If you simply move the data and business logic from the old platform to the new one with little change, that is pure migration — like hoisting the house onto a truck, furniture and all, and setting it down in the CBD. If you rebuild the internals too, you are in Re-architect territory, or even Replace — moving a monolith out of a self-run data center onto the public cloud while rewriting the whole business with microservices and containers (Docker / K8s).

It is a big move, a long timeline, and a high cost, but the historical technical debt is gone for good and the ceiling lifts.

Why the terms get used interchangeably

The two terms are easy to confuse because one contains the other; they are not parallel options.

レガシーマイグレーション (Legacy Migration) is about the move. The goal is to take the data and business logic on the old platform and shift them to a new platform, either unchanged or with minimal changes — like hoisting the house, furniture included, into the CBD. It answers the question of changing address.

Legacy Modernization is about evolution, and it is a bigger umbrella. It covers not only moving house but also cutting a window in the old building, running new pipes, and demolishing and rebuilding parts of it. Its ultimate goal is to give old assets modern agile delivery and the ability to respond quickly to new business.

Strictly speaking, then, moving is a subset of modernization. Turning the storeroom into a shop by opening a window is modernization; relocating to the CBD and reopening there is a thorough migration and re-architecture driven by modernization.

How to decide whether to open a window or move

Put the analogy back into software engineering and the decision comes down to three questions.

First, do the load-bearing walls still hold? If the old system's core logic is still dependable and all it lacks is an outward channel, opening a window — encapsulating it, adding an API layer — is often enough.

Second, is the constraint the house or the land? If the bottleneck is servers, operations, elasticity, or cost — the "land" — renovating in place will not fix it. You have to move.

Third, can the old house be remodeled into the floor plan the new business needs? If the business processes and data model do not line up, moving alone will not be enough; you need to redesign.

These three moves are not mutually exclusive. Modernization already contains Migration, and a single project can easily open a window, move house, and redraw the floor plan along the way. What you want to avoid is treating "move" as the universal answer, or treating "open a window" as the finish line.

The next time someone mentions legacy migration, ask them one question first: do you mean moving house, or renovating while you are at it? That question alone usually settles the distinction.