The modernization

01 — The situation

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.

02 — How the gates apply

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.

03 — What you receive

• ·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

04 — Where this goes wrong without discipline

• 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.