A legacy modernization assessment (modernisation in UK spelling) is a short, evidence-based exercise that answers three questions for every application you run: how much does the business depend on it, how risky is it to keep, and what should happen to it. You inventory the applications, collect facts rather than opinions, score six risk factors, set the result against business value, and assign each application a disposition such as retain, retire, replatform, refactor or rebuild.
Most organizations start modernization with a technique ("we need to move to the cloud") instead of an assessment. The result is a program that spends its budget on the loudest system rather than the riskiest one. This checklist is for the IT lead, operations director or CTO who has to produce a ranked list that finance and the business will accept. It complements our guide to legacy system modernization options, which explains what each option means; this one explains how to decide which applications get which option, and in what order. When the assessment is done and you want a partner to run it, see legacy software modernization services.
Why assess before you choose a technique?
A technique answers "how". An assessment answers "which system, why, and in what order". Without it three things usually happen. The system with the most vocal owner is modernized first. A cheap, low-value application is rebuilt while a business-critical one sits on an unsupported database. And no one can explain to the board why the budget was spent where it was.
An assessment also finds the quiet systems: the spreadsheet with macros that calculates commissions, the batch job someone wrote years ago that posts to the ledger every night, the integration nobody remembers. These are often the ones that fail first, because nobody is watching them.
Step 1: Build the application inventory
Start with a flat list, one row per application, including the unglamorous ones. Collect it from three sources and merge them: the IT asset register, the finance system (who pays licence, hosting and support invoices) and interviews with each department ("which tools do you open every day?"). Departments always name applications IT has never heard of.
Copy this table into a spreadsheet and fill one row per application.
| Field | What to record | Why it matters |
|---|
| Name and owner | The application name and one accountable business owner | No owner usually means no decision |
| Purpose | One sentence on the process it supports | Separates core systems from convenience tools |
| Users | Number of named users and departments | Sizes training and cutover effort |
| Technology | Language, framework, database, operating system and versions | Shows end-of-support dates |
| Hosting | Where it runs and who patches it | Shows who carries the operating risk |
| Last release | Date of the last change to production | A long gap can mean stability or abandonment |
| Source and docs | Is the source code available, in version control, and documented? | Decides whether refactoring is possible |
| Data | Main data stores, volume, retention rules | Drives migration scope |
| Integrations | Every system it sends data to or receives data from, and how | Shows what breaks when it changes |
| Annual running cost | Licences, hosting, support, plus staff time if known | Gives the cost-of-ownership factor |
| Known incidents | Outages, data errors and security findings in the last year | Shows real behavior |
Two practical rules. First, record "unknown" instead of guessing; the number of unknowns for an application is itself a risk signal. Second, include applications that are not software in the narrow sense: critical spreadsheets, scripts and shared databases that people rely on as systems.
Step 2: Collect evidence, not opinions
Opinions on legacy systems are unreliable: users who dislike a screen call it legacy, while a quietly failing batch job gets no complaints. For each application, pull the following from systems you already have.
- Change requests and tickets. How many changes were requested in the last twelve months, how many were refused or deferred, and how long the delivered ones took. This measures change friction directly.
- Incident history. Outages, data corrections and manual workarounds, from the helpdesk or the operations log.
- Platform support dates. The vendor's published end-of-support date for the operating system, runtime and database version. Check the vendor's own lifecycle page rather than memory.
- Security findings. Results from your last vulnerability scan or audit; unpatched components; shared or default accounts; whether there is an audit trail.
- Cost invoices. Licence renewals, hosting bills, support contracts. Add a rough estimate of staff hours spent keeping it running.
- Knowledge concentration. Count the people who can change the system safely. One or two is a key-person risk; zero is an emergency.
- Integration map. List each interface and whether it is documented, monitored and tested.
If you cannot collect an item, record that. A week of evidence gathering normally saves months of argument.
Step 3: Score six risk factors
Score each factor from 1 (low concern) to 5 (high concern) using the anchors below, so two assessors reach the same number. Weights are a starting point; change them to match your business, but set them before you see the scores.
| Factor | Weight | Score 1 | Score 3 | Score 5 |
|---|
| Platform support | 25% | Fully supported with years left | Support ends within two years | Unsupported, or cannot run on current hardware |
| Security and audit exposure | 20% | Patched, audit trail, individual logins | Some gaps, compensating controls | Unpatched components, shared logins, no audit trail |
| Change friction | 20% | Small changes ship within weeks | Changes are slow and need specialists | Most requests are refused as too risky |
| Knowledge and key-person risk | 15% | Several people can maintain it; documented | One or two people know it | No one can safely change it |
| Integration blockage | 10% | Documented API or clean exports | Files and manual steps | Cannot connect to anything; re-typing |
| Running cost | 10% | Cost proportionate to value | Cost rising year on year | Cost is high relative to value and growing |
The weighted urgency score is the sum of weight times score, divided by 100, giving a number between 1 and 5.
Score business value separately, also from 1 to 5: how much revenue, compliance or customer service depends on the application, and how hard it would be to run the business for a week without it. Ask the business owner, then challenge the answer with the evidence (how many users, how many transactions).
Worked example (illustrative numbers)
The table below shows four invented applications to demonstrate the arithmetic. They are not drawn from any real client.
| Application | Platform | Security | Change | Knowledge | Integration | Cost | Urgency | Value |
|---|
| Order entry (desktop app, unsupported runtime) | 5 | 4 | 4 | 5 | 4 | 3 | 4.30 | 5 |
| Stock reports (spreadsheet macros and scripts) | 2 | 2 | 3 | 4 | 2 | 1 | 2.40 | 3 |
| Leave tracker (old intranet page) | 4 | 3 | 2 | 3 | 1 | 2 | 2.75 | 1 |
| Supplier portal (supported stack, no API) | 2 | 3 | 4 | 2 | 5 | 2 | 2.90 | 4 |
For the order entry application: 25 x 5 + 20 x 4 + 20 x 4 + 15 x 5 + 10 x 4 + 10 x 3 = 125 + 80 + 80 + 75 + 40 + 30 = 430, so the urgency score is 4.30. The other rows work the same way.
Step 4: Turn the two scores into a disposition
Plot urgency against value, or simply apply this rule table.
| Value | Urgency | Usual disposition | Reasoning |
|---|
| High (4-5) | High (3.5+) | Modernize first: replatform, refactor or rebuild in slices | Critical and risky; the first program wave |
| High | Medium (2.5-3.5) | Fix the specific blocker, often an API or integration layer | Business depends on it, but only one factor hurts |
| High | Low | Retain and monitor; document it | Do not touch what works |
| Medium (2-3) | High | Replatform or replace with a packaged product | Standard function; do not over-invest |
| Medium | Low-medium | Retain; revisit at the next review | Avoid spending on a stable tool |
| Low (1) | Any | Retire or replace with a simple standard tool | Cheapest outcome is often switching it off |
Applied to the example: the order entry application goes into the first wave; the supplier portal gets an integration layer before anything else; the leave tracker is a retire-or-replace candidate; the stock reports are retained but documented, with the macros moved under version control.
Step 5: Sequence the work
A ranked list is not yet a roadmap. Adjust the order using four checks.
- Dependencies. If the supplier portal and the order entry application share a database, they move together or the shared database moves first.
- Business calendar. Avoid cutovers at financial year end, peak trading and audit periods.
- Quick wins. Retiring a low-value system frees budget and attention at almost no risk; do it early to show progress.
- Capability. If your team has never done a cutover, start with a smaller system.
Step 6: Decide what the assessment must produce
Insist on a written output, so the work survives staff changes. At minimum: the completed inventory; one page per prioritized application with the evidence, scores and chosen disposition; a dependency map; a risk register with an owner for each risk; a phased roadmap with decision gates; and a list of open questions with the person who must answer each. If you hire a provider, ask for these as deliverables you keep, whoever does the later work.
Common assessment mistakes
- Scoring by age. A ten-year-old, patched, documented system can be healthy; a three-year-old one nobody understands is not.
- Letting the loudest user set priority. Use the evidence table.
- Ignoring data. Application scores say nothing about data volume or quality; add a data note to each page.
- Skipping the integration map. Hidden interfaces are the most common cause of surprise outages during cutover.
- Treating the assessment as a one-time event. Re-score yearly; platform support dates and incident counts change.
Who can run the assessment with you
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. Our legacy system modernization services begin with this kind of assessment: a system map, a code and infrastructure review, a data audit, a ranked risk register and a phased roadmap that you keep. There is no fixed timeframe: the schedule is set from your requirements in the Plan step. The free pilot of 2 to 3 key modules is ready in about 2 days, and with 1,200+ developers we have the capacity to deliver a complete system in as little as 2 weeks. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. Long-term support under a service level agreement (SLA) follows launch. Timeline Digital does not publish prices for custom software, because every project is custom.
For the next decision, read legacy modernization tools and approaches compared, and if the application at the top of your list is an ERP, see legacy ERP modernization. When you reach the stage of choosing a provider, legacy modernization vendor evaluation lists the evidence, SLAs and support tiers to compare.
About the author and publisher
This guide was written by Usama Asif, CEO and CTO of Timeline Digital. It describes general assessment practice; the weights and scores are examples, and your own should come from your evidence.