Legacy Modernization Checklist

This is the last part of the field guide, and it does a different job from the eleven before it. Parts 1 through 11 built the understanding; this part turns that understanding into an instrument. It distills the whole series into a checklist you can run against your own system — five stages of questions, each gating the next. Where you can answer confidently, you are ready to proceed. Where you cannot, the gap is your next piece of work. Read it as a diagnostic, not a trophy: the value is in finding the questions you can’t yet answer.

Everything here is on this page. There is no gated download and no form — copy it, adapt it, run it.

Stage 1 — Assessment: is this actually legacy, and what is it costing?

Before any plan, establish that modernization is the right response at all. (Parts 1–2.)

• Is the system genuinely legacy, by function rather than age? Is the gap between what the business needs and what the system can safely deliver actually widening — or is this a healthy old system?
• Is change slow and getting slower? Has lead time for a routine change trended up over recent quarters?
• Is maintenance crowding out new work? Is the maintenance share of the engineering budget climbing toward the ~55–57% run-the-business baseline (Deloitte)?
• Is the knowledge concentrated and leaving? For each critical subsystem, how many people could safely change it — and are they staying?
• Is risk accumulating? Are there open security or compliance findings against unsupported runtimes you cannot patch away?
• Are users routing around the system? Have shadow spreadsheets and side tools appeared because the system can’t do the job?
• What is the cost of not acting? Have you named the cost of delay — rising maintenance, thinning knowledge, growing exposure, a larger eventual effort?
• Is modernization even the right answer? Could the honest move be to retire or replace the system, or leave a stable one alone?

If you can’t answer these, that is your first task — measure the gap before you plan a response.

Stage 2 — Decision: the right move per component

Modernization is not one move applied to a whole system. Decide per component. (Parts 3–4.)

• Have you inventoried the components and mapped their dependencies? From the real system, not a stale architecture diagram.
• Have you assigned each component one of the 7 Rs — with a reason? Retire, retain, rehost, replatform, replace, refactor/rearchitect, rebuild.
• Have you retired the dead weight first? Confirmed-unused features and modules removed before anything else.
• Have you replaced the commodity functions? Custom code for things a product does better and cheaper, handed to the product.
• For the parts that must evolve, have you chosen refactor, rearchitect, or rebuild deliberately — based on whether the existing code is salvageable, not on appetite for a clean slate?

Component situation	Likely right move
Confirmed unused	Retire
Stable, low value to change	Retain (documented)
Needs a new home, not new logic	Rehost / Replatform
Commodity function	Replace
Must evolve, code salvageable	Refactor / Rearchitect
Must evolve, code beyond saving	Rebuild (incrementally)

Stage 3 — Planning: sequence the slices

Turn the per-component decisions into an ordered, fundable program. (Part 5.)

• Has discovery produced a current, evidence-based map of the system, its dependencies, and its undocumented behavior?
• Have you defined slices — vertical cuts of business capability that ship independently — rather than horizontal layers?
• Are the slices bounded, vertical, independently valuable, and loosely coupled?
• Is the sequence ordered by business value and risk, front-loading value and containing risk?
• Is the first slice meaningful enough to matter and contained enough to succeed — neither the scary core nor a trivial corner?
• Is the parity bar defined per slice — functional parity, data integrity, non-functional parity — before work starts?
• Have you separated “must replicate” from “safe to improve” for each slice?
• Is re-planning built into the cadence, with a deferred queue feeding the next slice?

Stage 4 — De-risking: build the program to survive

Most programs fail for structural reasons. Build in the structure that beats the odds. (Parts 6–9.)

• Are you delivering incrementally, not big-bang — slice by slice, not one distant cutover? (Unless the system is small/isolated enough to justify big-bang — see Part 8.)
• Is there a strangler facade so old and new run side by side and traffic shifts gradually?
• Is parity proven against the legacy before each promotion, not just tested against your own spec?
• Can any slice roll back independently?
• Does the business keep running throughout — no frozen roadmap, no downtime cutover?
• Is the system’s knowledge captured as living specs before it is changed?
• Is there an executive sponsor, business stakeholders, and a single accountable lead?
• Is modernization interleaved with the product roadmap so it isn’t a competing line item?
• Is cost and timeline estimated in small, validated increments, with the option to stop after any slice?
• Are your expectations honest — discovery in weeks, first slice in a couple of months, full program scaling with system size?

Stage 5 — Partner selection: evaluate method over logos

If you bring in a partner, judge how they work, not how many logos they show. (Parts 10–11.)

• How do they prove a component behaves like the legacy before it carries live traffic? (Parity validation — not “we test thoroughly.“)
• Can a single piece roll back without affecting the rest? (Strangler facade, slice-by-slice — not “careful cutover planning.“)
• How do they recover undocumented behavior? (From the system itself — not only “interview your team.“)
• Will the business keep running throughout? (Continuously — not a maintenance window or a roadmap freeze.)
• How is the engagement scoped and priced? (Bounded discovery first, then incremental — not one large upfront commitment.)
• Are they candid about where their own approach does not fit? (Honesty about limits predicts honesty under pressure.)
• Can you start with a small, real engagement and evaluate them on delivered work before committing the program?

How to read your results

Run the five stages and the pattern in your answers tells you where you stand:

• Mostly confident answers in Stages 1–3: you understand the system and have a plan. Pressure-test the de-risking and partner stages before committing.
• Gaps in Stage 1: stop. You may be about to modernize for the wrong reasons, or to modernize something that should be retired or left alone. Measure the gap first.
• Gaps in Stages 2–3: the understanding isn’t there yet. This is precisely what a discovery phase produces — and why it is the right, bounded first commitment.
• Gaps in Stage 4: the plan may be sound but the shape is risky. These are the items that decide whether a program joins the ~70% that miss their objectives (BCG, 2023).

One caveat about the checklist itself: it tells you what to ask and where you stand. It cannot tell you the answers for your system — those come from looking at the actual code, data, and business context. A checklist is a map of the questions, not a substitute for the work of answering them.

Where this leads — the end of the guide

That closes the field guide. Across twelve parts you have a complete, working model of legacy modernization: how to recognize it, decide it, plan it, de-risk it, size it, and source it. The thread through all of it is a single idea — distribute the risk. Don’t bet the business on a date; replace the system slice by slice, prove each step before it carries load, and keep the business running the entire time. The systems that built your business deserve a future as serious as their past.

To revisit any part, the full series lives at the Legacy System Modernization field guide hub. And if you want to run this checklist against your own system with the people who built the method behind it, the most direct path is a 30-minute discovery call — no deck, just your system and an honest read on where it stands.