Insights
Check if your legacy system is ready to modernise. Twenty questions on what must survive, dependencies, transition and who decides, and how to read answers. A legacy system is ready to modernise when you can show, with evidence rather than opinion, what behaviour must survive, what depends on it, how old and new will ru
Insights · Checklist · Legacy modernisation
A legacy system is ready to modernise when you can show, with evidence rather than opinion, what behaviour must survive, what depends on it, how old and new will run side by side, and who decides what the first test must prove. The 20 questions below check each. A No or Unknown marks what to investigate before you commit budget.
What does "ready to modernise" actually mean?
Readiness is not a verdict on how old or ugly the system is. An old system can be ready, because the team knows what it does and can change it safely. A newer one can be unready, because nobody can say what customers depend on.
It also depends on the next commitment. Being ready to investigate one capability is a lower bar than being ready to approve a multi-quarter rebuild. This checklist is built for the second, harder question, and the way you read your answers (below) separates the two.
AWS publishes a readiness assessment guide that assesses applications through five lenses: strategic or business fit, functional adequacy, technical adequacy, financial fit and digital readiness. It is written for portfolios moving to AWS and runs as an interview-and-questionnaire process spread over two weeks. The checklist here is narrower and written for one product team deciding whether it can responsibly start. It borrows the idea that readiness is a set of answerable questions, and it adds three things a transition has to deal with once work begins: undocumented behaviour, data coexistence and rollback.
If the question you are really asking is whether to rebuild, redesign, replatform or retire, that is a different decision. Start with our decision framework for legacy software and come back here to test whether you can act on the answer.
How do I score the checklist?
Pick one capability, not the whole product. Choose a piece of work such as creating a quote, approving an order or running a saved report. Answering for "the system" produces comfortable, vague Yeses.
Then mark each question one of four ways:
- Yes: you can point to an artefact, such as a document, a test, a ticket history or a named person's written answer. Confidence alone does not count.
- Partly: the evidence exists for some of the scope, or only one person holds it.
- No: the evidence does not exist.
- Unknown: nobody has looked. Treat this as its own result. An Unknown is not a No, and it is not a Yes. It is the work you have not done yet.
Ask a product owner, an engineer and someone who understands the operational use of the capability to answer separately, then compare. Disagreement between them is itself a finding.
Do we know why we are changing this, and what exactly? (questions 1 to 4)
Martin Fowler, who named the strangler fig approach, notes that modernisation efforts too often start with muddled objectives, with different groups wanting different things, and says to get alignment on outcomes early. These four questions force the objective to be specific enough to test.
| # | Question | What counts as a Yes |
|---|---|---|
| 1 | Can you state in one sentence why change is being considered now, and what would show it worked? | A written sentence the product, engineering and business owners all accept, with at least one observable measure |
| 2 | Is the scope one capability with a boundary you can investigate, rather than "the product"? | A named capability, the screens and services it touches, and what is out of scope |
| 3 | Do you know who depends on it, including roles outside your product team, and which habits they have built on the current behaviour? | A list of roles (customer users, administrators, support, finance, operations) with how each uses it |
| 4 | Have you separated what is constraining you: the interface, the workflow, the platform or the code and architecture? | A short written diagnosis that names which of these is the binding constraint and the evidence for it |
Question 4 matters more than it looks. In Tcules' Benchmark Gensuite work, the case concludes that a framework upgrade, a visual refresh, an interaction-model change and a design-system programme are different investments, and that telling them apart helps focus investment. A team that cannot say which one it is buying is not ready to scope the work.
Do we know what must survive? (questions 5 to 8)
This group decides whether a modernisation is safe, and it is easy to skip because the answers are scattered.
| # | Question | What counts as a Yes |
|---|---|---|
| 5 | Can you list the business rules, exceptions and customer-specific behaviour this capability enforces, with a source for each? | A rules inventory built from code, support history and interviews, with each rule marked keep, change or retire |
| 6 | Do you know which exports, reports, APIs and integrations other people treat as their source of truth? | A list of outputs with the consuming team or customer named |
| 7 | Do you have automated tests or recorded examples that describe what the system does today, not what the specification says it should do? | Tests or captured input and output pairs for the capability in scope |
| 8 | Is there a named owner of data meaning, and have the people holding undocumented knowledge been given time to share it? | A named person, and scheduled sessions with long-tenured engineers, support and operations |
Two ideas sit behind this group.
Behaviour you did not promise is still behaviour someone relies on. Hyrum Wright's observation, now known as Hyrum's Law, is that with enough users of an interface, all observable behaviours of your system will be depended on by somebody, whatever the contract says. An old application may contain an exception for a contracted customer or an export that another team treats as its source of truth. If the replacement drops it, the problem moves into operations.
A test of current behaviour is not a test of correct behaviour. Michael Feathers describes characterisation testing as documenting the system's actual behaviour, not the behaviour you wish it had. Once code is in production, he argues, it becomes its own specification. That is why question 7 asks for evidence of what the system does today. It gives you something to compare the replacement against, including the behaviour nobody wrote down.
Do we know what it depends on and what it depends on us for? (questions 9 to 12)
| # | Question | What counts as a Yes |
|---|---|---|
| 9 | Are upstream and downstream integrations inventoried, each with an owner and a contract or known behaviour? | An integration map reviewed by the owning teams |
| 10 | Do you know where the data lives, what each important field means, which records have quality problems and what must be retained? | A data inventory for the capability, with known defects and retention or compliance requirements noted |
| 11 | Can your team read, change, build and deploy the source for this capability, and intercept requests to it? | Someone on the team has done a build and deploy recently, and you can place a routing layer in front of the capability |
| 12 | Do you know what is out of vendor support, running unsupported components or carrying known vulnerabilities, and the dates that matter? | A list of components with support end dates and open security findings |
Question 11 comes from a practical limit. Microsoft's architecture guidance on the strangler fig pattern says the approach may not suit cases where requests to the back end cannot be intercepted or where you cannot access the legacy source code, because you need to modify it to disable migrated features and redirect internal calls. If neither is possible, an incremental route is closed to you, which changes what the realistic options are.
Question 12 is about urgency as much as readiness. A platform deadline is a legitimate reason to move, and it should be a known date on the plan rather than a surprise.
Can the old and the new run together, and can we back out? (questions 13 to 16)
A modernisation plan can describe the destination in detail and leave the journey nearly blank. Customers still need their records, integrations still run, and someone has to support both versions until the move is finished.
| # | Question | What counts as a Yes |
|---|---|---|
| 13 | Is there a seam where traffic or users can be routed to old or new for one capability at a time? | A named boundary, and a reviewed way to route at it |
| 14 | For each dataset the capability touches, have you decided which system is the source of truth during the transition, and how you will check the two agree? | A per-dataset decision and a consistency check you can run |
| 15 | Is rollback defined, including the point after which it is no longer possible? | A written rollback procedure with an owner and a named point of no return |
| 16 | Have you decided what happens to the old system at the end: who turns it off, what records are kept and who is still depending on it? | A disposition plan listing dependants, contracts, retained records and a substitute where needed |
The same Microsoft guidance shows why 14 and 15 belong together. Its database example keeps the monolithic database and a new domain database in sync, validates consistency before cutover, and notes that rollback is possible until the legacy tables and synchronisation are removed. Restoring them afterward means replaying data changes, which significantly increases effort and risk. The practical lesson is to decide when you will remove the old objects, and to make that a deliberate final step rather than a side effect of progress.
Can we afford to do this, and who decides? (questions 17 to 20)
| # | Question | What counts as a Yes |
|---|---|---|
| 17 | For this application, can you measure how long a change takes to reach production and how often releases need a rollback or hotfix? | Current numbers from your delivery pipeline, so you can tell later whether things improved |
| 18 | Can modernisation proceed without freezing the roadmap, with capacity and funding actually assigned? | Named engineers and designers, and an agreement about what the active roadmap gives up |
| 19 | Is there a written plan with milestones, a description of the work needed and the intended end state for the legacy system? | A plan document with an owner, reviewed by the people who will deliver and operate it |
| 20 | Is there a named decision owner and a defined first test that exposes the hardest open dependency, with acceptance evidence agreed in advance? | A first slice such as one role through one representative record, an approval, an integration and a failed action, and what it must prove |
On question 17, DORA's guidance on its software delivery metrics names change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. DORA recommends measuring one application or service at a time and warns against turning the metrics into targets. For readiness, the point is a baseline. It is not a score to hit.
Question 20 deserves the most care. A first slice that only demonstrates the easy path will tell you nothing. It should be chosen because it exposes the dependency most likely to change the plan, and the team should agree before it starts what a pass looks like.
How do I read my answers?
This is our judgement, not a validated scale. We have not tested it against outcomes, and the groups are not equally weighted. Read the pattern, not a total.
| Pattern in your answers | What it suggests | What to do next |
|---|---|---|
| Mostly Yes across all five groups | You can credibly scope a first implementation test and a staged plan | Define the first slice (question 20) and commit to that, not to the whole programme |
| Yes on questions 1 to 4, with Partly or Unknown on questions 5 to 12 | The objective is clear but the safety net is thin | Do discovery on the weak group first: rules inventory, characterisation tests, integration and data mapping |
| No or Unknown on questions 1 to 4 | The team has not agreed what problem it is solving | Pause estimating. Settle the objective and the binding constraint before anything else |
| No or Unknown on questions 5 to 8 | Nobody can say what must be preserved | Do not approve a rebuild. Recover the current behaviour first |
| No or Unknown on questions 13 to 16 | The target is described and the transition is blank | Design coexistence, data ownership, rollback and retirement before choosing a target |
| No or Unknown on questions 17 to 20 | Capacity, ownership or the first test is missing | Assign an owner and a first test before more planning |
A short worked reading, illustrative and not a client result: a team wants to rebuild the editor of a report builder because it is expensive to extend. They mark question 6 Unknown, because they have not checked whether customers rely on saved reports, and question 7 No, because there are no tests of what saved reports return. The reading above says not to approve the rebuild yet. The first work is to establish which saved reports must survive and to compare representative outputs, which costs less than discovering the gap after release.
What does the evidence say about readiness, and what does it not say?
Honest limits, so the checklist is not mistaken for more than it is.
- Modernisation is not only a technical problem. In an ICSE study by Khadka and colleagues, 26 industry practitioners were interviewed and the findings checked with a survey of 198 respondents. They found that practitioners value their legacy systems highly and that the challenges they face include business and organisational aspects, not just technical ones. The study is from 2014 and concerns perception. That is one reason most of the groups above are about decisions and ownership, not code. It is an inference about emphasis, not a measurement of what predicts success.
- Incomplete plans were the norm in one federal review. The US Government Accountability Office reviewed 11 critical federal legacy systems in 2025 and found that only three had fully documented modernisation plans, covering milestones, the work needed and what happens to the legacy system. GAO reasons that gaps like this raise the likelihood of cost overruns, schedule delays and project failure. These are large government systems, so treat this as evidence about a neighbouring setting. It shows a planning gap in that sample of eight out of eleven systems. It does not show that your SaaS product will fail without a plan.
- No published study validates this checklist's questions as predictors. They are drawn from practitioner and vendor guidance and from the pattern of what makes transitions hard. A Yes on all 20 does not guarantee a smooth programme, and a No does not mean you must not proceed.
- The checklist cannot inspect your system. It will not discover dependencies, find hidden rules or produce an estimate. It shows which of those jobs you have not done.
What if I cannot answer these on my own?
If your weakest answers cluster in one or two groups, such as what must survive or the transition, that is where an outside, structured investigation earns its place.
Tcules' Product Modernisation Assessment compares repair, redesign, progressive modernisation, replatforming, selective rebuild, leaving a capability unchanged and retirement before the change becomes expensive to reverse. It works from the running product across meaningful roles, recent change history, technical and data dependencies, and conversations with product, engineering and commercial owners. Its outputs include a current and target product model, a preserve, change, leave and retire boundary, a capability-level option comparison, one recommended route with visible reasoning, a staged sequence with continuity gates, the transitional work and the conditions for removing it, acceptance, migration and rollback considerations, and the questions that need user research or technical investigation before commitment.
It has limits you should know about. Tcules describes it as an option assessment, not a complete implementation estimate. If the team only knows the product is underperforming and cannot yet say why, a UX and Product Audit may need to come first. Missing documentation does not prevent the assessment; it becomes part of what must be made explicit.
If you would rather work through the options yourself first, Tcules' Audit, Redesign, Modernise or Rebuild tool walks you through listing capabilities, scoring each on value, product clarity, experience quality and technical cost, and reading the pattern to see which intervention each is likely to need. It is a structured argument, not an assessment: it does not evaluate your architecture, estimate cost or examine code. Either way, bring one disputed capability and the answers you marked No or Unknown.