Do Not Rewrite the Legacy System. Contain It.

Understand the existing design, then isolate the change, design it cleanly, and implement it with TDD, ATDD and integration testing.

Legacy systems usually do not need to be rewritten entirely. More often, a few parts create most of the pain, while the rest still works well enough.

I start with a coarse view of the whole system (C4 models). The goal is not to document everything in detail, but to understand the main components, dependencies, integrations, ownership boundaries and finally to document the problems with the as-is implementation.

Then, together with stakeholders, I identify which parts are most critical to change and assign priorities. Only after that do I start working on a concrete part.

For the selected part, I explore the current implementation, analyse its behavior and document the design that actually exists, then create a coarse to-be C4 models and a more detailed UML models. Then I define a boundary around the part and introduce adapters that isolate the new design from the remaining legacy code, design the replacement cleanly and implement it with TDD.

The same process can then be repeated for the next priority.

The result is not an instant clean architecture. It is a system where more and more parts become understandable, documented and safe to change, one boundary at a time.

This is the kind of legacy modernization work I specialize in: recovering design, containing change, and improving the system one boundary at a time.