This modernization assessment checklist gives you nine checks. For each one you apply a test and keep proof. Mark every check 2, 1 or 0, add the total out of 18, then read the readiness band.
Last reviewed 2026-11-05 by Manish Sharma.
Judging an application for modernization means asking whether it can be changed safely, with a known owner and a known cost. This list answers that one question for an application that runs today. The order of work is covered in the order of work once you decide to change. Likewise, the list leaves out the symptoms that start the question, and it does not choose a route.
Marking Rules for This Modernization Assessment Checklist
Every check takes one of three marks, and none of them is a benchmark.
The nine checks, the 18 points, the marks and every band edge are Signisys suggestions. Adjust them to your firm before scoring.
The three marks read as follows.
- Proven (2): the test holds for the whole application, and you can show dated proof today.
- Partly (1): the test holds for part of it, or the proof is thin or old.
- Claim only (0): the test fails, or the only support is someone’s word.
A claim with no proof behind it scores 0, whatever the team believes.
Name the application and its environments before you mark anything. Anything outside that scope scores 0. Alternatively, remove the check and lower the top total by the two points it carried, then say so beside the result.
Where a test relies on a sample, we suggest three items. Someone other than the application owner chooses them. After that, the sheet names the three. Also adjust that number to the size of the application.
Agree the marks and the bands with the sponsor before scoring, so that totals compare across applications. Every check weighs the same here. However, a firm can change that before marking starts.
To use this application modernization checklist, paste the three tables below into a sheet. Then add columns for owner, date and mark. The result is a self-review. It is neither an audit nor a certificate.
The Modernization Assessment Checklist: Nine Checks, Tests and Proof
Three groups hold the nine checks. In each table, a test sits beside the proof that backs it.
Is It Worth Keeping, and Who Holds It?
The first three checks cover value, cost and the people who can change the application.
| No. | Check | Test | Proof to show |
|---|---|---|---|
| 1 | One named owner holds the business value. | Yes if the owner names who uses it, what stops when it is down and what depends on it later, and has signed the value statement. | A one-page value statement with the owner’s name and date. |
| 2 | The run cost is known. | Yes if the yearly cost of running, licences, support contracts and people time is written for this application alone. | A cost sheet whose lines trace to supplier records or timesheets. |
| 3 | Enough people can change it. | Yes if at least two people, our suggestion, can read the code and release a change without outside help, and neither is the only holder. | Both names, plus one change each made in the last year, also our suggestion. |
Check 1 matters first here. Without an owner, nobody can approve a change or accept its result.
Key Takeaway Check 1 comes first: with no owner, nobody can approve a change or accept its result.
What Is It Made Of, and What Does It Touch?
The middle three describe the code, the data and the support position.
| No. | Check | Test | Proof to show |
|---|---|---|---|
| 4 | The code and its parts are known. | Yes if the firm holds the source, it builds from a clean copy, and every library and runtime is listed with its version and its coupling. | A clean build record and the dependency list. |
| 5 | Data and links are mapped. | Yes if each data store, interface, file exchange and scheduled job has an owner and a named system on the other side. | A map of flows and a list of interfaces. |
| 6 | Support and security status are current. | Yes if every runtime, database and component sits inside its supplier’s support dates, and each known weakness has a named fix or a written decision. | The support-date list and the latest weakness scan. |
Treat this modernization assessment checklist as a way to find gaps, not as proof of quality. For check 6, standards-body practices for finding and fixing software weaknesses give a comparison point. They are guidance for software producers, published by a US body, and no India or GCC rule. Other systems that depend on this one raise the mark you give in check 8.
Can It Change Safely, and Is There a Way Out?
The last three cover testing a change, limiting its reach and undoing it.
| No. | Check | Test | Proof to show |
|---|---|---|---|
| 7 | Tests cover the actions the business relies on. | Yes if automated tests run on every change and the last run is recent. Where tests are missing, the key business actions are written down with expected results. | The last report and the list of covered actions. |
| 8 | The risk of change is stated. | Yes if the number of dependent systems and teams is known, a change window exists, and the owner has put the cost of a bad release in writing. | The dependants list and the owner’s impact note. |
| 9 | A written exit plan exists. | Yes if a plan says how to stop a change and return to today’s behaviour, names who may call it, and covers data written meanwhile. It also sets an end point for the old application. | The plan, with a date and the named approver. |
Check 7 is easier to prove when you are watching how an application behaves in daily use. Check 9 is the deciding check, and the totals section below applies it.
Key Takeaway Check 9 decides the band: a change with no safe way back should not start.
Collecting the Proof Without Touching the Live Application
First, collect proof with read-only access, by someone who did not build the application, while the owner answers questions. We suggest planning about an afternoon per application. That is a planning figure, not a promise, and a core application with many interfaces takes longer.
Before you start, have these ready. For example, read-only access to the source and settings, a recent performance reading at normal and peak load, and the database and security owners all help. Collecting proof is also quicker with them on hand.
Start with an inventory. Then list every application first, including those missing from the asset register. A whole application modernization assessment is a portfolio inventory plus nine marks each, so allow more time than you planned.
In practice, proof comes from supplier records, timesheets, build and test reports, dependency lists and monitoring history. The owner’s account is a lead to follow, not proof. Keep every item in one dated folder.
Keep the lower mark and write one line on the gap between them.
This list reads assessment as three questions: what exists, what it costs and how ready the people are. That framing is our own. For example, checks 4 to 6 cover what exists, check 2 covers cost, and checks 1 and 3 cover the people.
What Your Modernization Assessment Checklist Total Says
Sum the nine marks, then look up the band. These ranges are Signisys wording, and you can move them to suit your appetite for risk.
| Total | Band | Next move |
|---|---|---|
| 15 to 18 | Ready to change | Hold the proof and review it on your schedule. |
| 11 to 14 | Ready once named gaps close | Close the gaps and mark again. |
| 6 to 10 | Fix the basics first | Settle owner, cost and support status before any plan. |
| 0 to 5 | Too little known to plan | List what exists and name its owners. |
We suggest a yearly recheck. However, run one sooner after a trigger such as a changed support date.
A mark below 2 on check 9 holds the result at Ready once named gaps close, because a change with no safe way back should not start. A 0 on check 1 holds it at Fix the basics first, because nobody can approve. Each rule caps the band and leaves the total alone. When both apply, the lower band wins.
The next example is invented and is not data. Take an application with six checks at 2 and three at 1: 6 x 2 + 3 x 1 = 15. One of the three is check 9. On total alone the band is Ready to change, yet the rule holds it at Ready once named gaps close. The first task is to finish the exit plan.
A low total does not say retire. Rather, it says what is unknown. Whether to keep, replace or retire belongs to a separate decision. Once the checklist is done, the next decision is covered in a comparison sheet that sets a route for each application.
Putting Several Applications in Order
Score each application, list the totals in one sheet and sort by total. We suggest breaking ties with check 1, where higher business value goes first, and then check 8, where fewer dependants go first. The same sheet serves a legacy application assessment across a whole estate.
In practice, read value and readiness apart. A ready application that nobody needs is not a priority. Also, a valued but unready one needs its gaps closed first. The score does not measure expected gain. Instead, the business owner adds that view in writing.
First, test your marks on a short sample of applications before scoring them all. For a quick filter on which one to take first, the first-application questions fit before this scoring. This list does not choose a route for any application.
For an application you plan to move as it is, the readiness checks for moving an application as it is cover a different question.
Closing Gaps in the Order That Lowers Risk
We suggest working the gaps in this order: owner (check 1) first, exit plan (9) next, then 6, 7, 5, 4, 8, 3, and cost (2) last. The owner and the exit plan come ahead of everything else. If a support date has passed, move check 6 forward at once.
- First, checks 1 and 9: without an owner and an exit plan, no change is safe to approve.
- Next, checks 6, 7 and 5: support gaps, missing tests and unmapped links make a change risky.
- Last, checks 4, 8, 3 and 2: these shape the size and cost of the work.
Then mark again after each fix, and a gap closed without new proof does not move the mark. For how to carry out each part, read the practice of changing software in small, tested steps and the longer guide to doing the work in sequence.
A Self-Marked Score Judges Proof, Not Design
The score shows how much readiness you can prove, but not whether the design is good. A person has to judge that. The builder may mark first, and then a second reader checks the proof behind each mark.
However, bring in a specialist when no one holds the code, a support date has passed, several linked applications move together, or an auditor or the board asks for proof. This list makes no claim about any law or regulator.
Signisys offers application modernization work, yet the nine checks work without its help. If you want a specialist beside you while you mark, see changing an existing application with a specialist, the solution that pairs application change with observability plus the delivery and automation service that supports it.
Modernization Assessment Checklist FAQ: Common Questions
Does the modernization assessment checklist work for a package we bought rather than built?
Can an application with a high total still be left as it is?
How many applications should a first modernization assessment checklist round cover?
What should you do when nobody can answer a test, such as who owns the application?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.