The modernization

There's a system nobody wants to touch. The people who built it are gone, the vendor is gone or charging like it, and every change is a small act of courage. But it runs the business, so it can't be paused, and it can't be replaced in one move.

This engagement is a staged migration: understand the system, fence it in behind clean interfaces, and move capabilities out one at a time — with the legacy system running until the day it has nothing left to do.

Assay matters most here. Before anything is planned, the legacy system has to be mapped: what it actually does, what depends on it, and which behaviors are load-bearing bugs. Sometimes the recommendation is to keep it and fence it — that recommendation comes in writing too.

Smelt produces the phase map: what moves, in what order, and how each phase is proven safe before the next begins.

Cast and Temper cycle per phase — each extracted capability is hardened and cut over before the next extraction starts.

• ·Legacy system map — what it does, what depends on it
• ·Phased migration plan with proof gates
• ·Extracted services, cut over one at a time
• ·Monitoring on old and new during transition
• ·Repositories and runbooks, owned by you

• Trusting the documentation. The system's real spec is its behavior; the docs describe a system that retired years ago.
• Replacing behaviors without understanding which quirks downstream systems depend on.
• Declaring victory at feature parity. The migration ends when the old system is off, not when the new one is on.