Legacy Software Modernization

Legacy software is software a business depends on that has become hard to change, scale, or operate. Modernization moves that software onto a technology that fits, usually by replacing it piece by piece, the way a strangler fig gradually takes over a tree, rather than with one risky rewrite.

itSoftware engineering

Don't Panic: Legacy Software Modernization

Legacy software is not software that has had a long and distinguished career collecting dust. It is software the business depends on that has become hard to change. Age often attends the party, but it is not the bouncer. The real problem begins when the technology decides which business changes are possible.

The tempting answer is a grand replacement: build a shiny new copy, then switch everything over in one heroic weekend. This has the minor drawback that the old system keeps changing while the copy is being built, and much of its behavior is undocumented, accidental, or both. A big-bang replacement therefore turns an existing problem into a multi-year guessing competition.

The useful alternative is the strangler fig. Put new behavior around the edges of the old system and move one piece at a time. A facade can route a request to the old application or the new service. For asynchronous work, an event router can do the same job. Both are temporary scaffolding, which is engineering language for something valuable that must not become a permanent resident.

The surprising part is that code is not the whole animal. Modernization has four linked jobs: decide the business outcome, split the work into parts, deliver those parts, and change the organization that produced the old system. A perfect new service built by the same blocked teams and processes can become a newer version of the same complaint.

Data is where the cheerful diagrams start charging rent. During database strangling, the old and new stores must stay consistent while behavior moves. Extract, transform, and load starts the move. Change data capture carries later changes. Validation happens before the new database becomes the system of record, because rollback is much friendlier before the old data objects disappear.

Choose the strategy before the machinery. Some workloads should be retained. Some should be retired, rehosted, replatformed, or replaced with a product. Refactoring is for changing the architecture itself, and the strangler fig is one way to deliver that work gradually. It is not a ceremonial requirement to turn every old system into several newer systems.

Read the Intro for the full map of seams, routing, data, and organizational change. Use the Slides when you need the sequence at a glance. Keep the Cheatsheet nearby when the seven R's, transitional architecture, and cutover conditions start looking suspiciously alike. The quiz is where the vocabulary has to earn its keep.

Don't Panic: Legacy Software Modernization

Relevant careers