Most organizations do not need a legacy system assessment to be told their system is old. They already know. What they need is a defensible answer to a narrower question: what should be done about it, in what order, and what it costs to be wrong. An assessment that produces observations instead of decisions has failed, however thorough it looks. This page is written as a specification for the deliverable, so you can either run it yourself with internal staff or hold an outside firm to it.
What the assessment has to decide
Start from the decision, not the discovery. Every assessment exists to resolve a small number of choices, and naming them on day one keeps the work from expanding into a general survey of the technology estate.
- Replace the system, rebuild parts of it, integrate around it, or leave it alone for now
- Which capability moves first, and what has to be true before it can move
- What the transition costs, in money and in operational disruption
- What happens if nothing is done for another twelve months
Leaving it alone must be a live option throughout. An assessment that cannot recommend doing nothing was never an assessment. Aging software that is stable, understood, and not blocking anything is a poor place to spend a budget, and saying so is often the most valuable output.
What has to be inventoried
Workflows as actually performed
Documented process and real process diverge in every organization that has run a system for more than a few years. People build spreadsheets, hold records back until a batch job finishes, re-key data between screens, and maintain private conventions that keep the operation running. Those workarounds are requirements in disguise. They have to be observed with the people doing the work, not collected from a process document or a manager's description.
Systems and integrations
Every inbound and outbound connection gets named, along with who owns it, how it authenticates, whether it is documented, and what breaks when it fails. Pay attention to the integrations nobody claims: a scheduled export writing to a shared drive, a report that a partner has been consuming for years, a nightly script running on a machine under someone's desk. These are the ones that surface after cutover.
Data ownership and quality
For each significant entity (customer, order, asset, employee), establish which system is authoritative, how it is keyed, and how badly the data has drifted. Duplicate records, dates stored as text, status fields carrying meaning that was never designed, and orphaned rows all have migration costs attached. Sample the actual tables. Migration effort tracks data quality far more closely than it tracks row count.
The permissions model
Write down who can see and change what, by role, location, and business unit, and where that model is enforced by the software versus by convention. If different sites, franchises, or entities must see different slices of the same data, that requirement reaches into every query and every screen of a replacement. It is one of the few things that genuinely multiplies cost, and it is almost never in the initial brief.
Deployment and recovery reality
Not the policy, but the reality. How is a change actually released, how long does it take, who is the only person who can do it, and when was that last tested? The same applies to backups: confirm the last time a restore was performed end to end. A backup that has never been restored is an assumption, not a control. Recovery time and data loss tolerance belong in the assessment because they set the risk budget for everything that follows.
Who holds undocumented knowledge
Name the people. In most legacy environments, three to five individuals hold the business rules that exist nowhere else, and one of them is usually close to retirement. Their availability is a schedule constraint on any modernization, and their departure is the single most common reason a system becomes unmaintainable.
The business questions that make it useful
A technically complete assessment that never touches economics leaves the sponsor unable to defend the spend. Two questions carry most of the weight, and both need numbers attached even when the numbers are estimates with stated ranges.
- What does the constraint cost per month right now, in manual labor hours, error correction, delayed invoicing, overtime, lost throughput, licensing you would otherwise drop, and staff turnover attributable to the tooling
- What capability is blocked: the pricing model you cannot offer, the market you cannot enter, the customer commitment you cannot make, the acquisition you cannot integrate
- What is the cost of a failure the current system makes likely, multiplied by how often it has already happened
- What deadline exists outside your control, such as a renewal date, an end-of-support notice, or a compliance change
The monthly cost figure is the one most often missing, because no one invoices for a workaround. It is also the number that decides most cases. A constraint costing $8,000 a month is an annoyance. The same constraint costing $80,000 a month is a business priority, and the arithmetic on a replacement changes completely.
What the assessment must produce
| Output | What it contains | Why it matters |
|---|---|---|
| Workflow map | The two or three highest-value workflows as performed, including workarounds and the points where work waits | Separates real requirements from habits the old system created, which is what keeps a replacement from copying the constraint forward |
| System and integration inventory | Every connected system, owner, auth method, data direction, and failure behavior | Integration surface is the most common source of schedule overrun, and it cannot be estimated from a diagram nobody has verified |
| Data assessment | Authoritative source per entity, key structure, sampled quality findings, and volume | Migration is priced from data quality, not data size; this is where a plausible estimate becomes a real one |
| Risk register | Named risks with likelihood, operational impact, and the specific mitigation or fallback | Turns anxiety into a list someone can own, and tells you which risks justify spending before the build starts |
| Costed delivery sequence | The order capability moves in, with effort ranges and the assumption behind each range | Lets you approve one bounded step instead of an open commitment, and makes a wrong assumption visible early |
| A recommendation with alternatives | The recommended path, the two options rejected, and what would have to be true for each to win | A single option is a proposal; showing the discarded ones is what makes it a decision you can defend |
How long it should take and what it should cost
For one business-critical system, two to five weeks and roughly $15,000 to $40,000 of senior time is the normal shape. That buys direct observation of the people doing the work, time in the code and the data rather than only in meetings, and a written deliverable. Beyond six weeks, the scope was never bounded and the cost of the assessment starts competing with the cost of the first release.
| Scope | Duration | Typical cost | When it fits |
|---|---|---|---|
| Single workflow or decision | 1–2 weeks | $8,000 – $15,000 | One clear question, such as whether to renew a platform before a known deadline |
| One business-critical system | 2–5 weeks | $15,000 – $40,000 | A system that has become expensive to change and is blocking something specific |
| Multi-system estate | 5–8 weeks | $40,000 – $90,000 | Several connected systems, multiple entities, or a post-acquisition consolidation |
How to recognize a bad assessment
Weak assessments are easier to spot in the deliverable than in the sales conversation, but the signals are consistent enough to check for in advance.
- A deck with no decisions in it, just pages of current-state diagrams, maturity scores, and a roadmap of themes, with nothing anyone can approve or reject
- Effort estimates with no named assumptions, so no one can tell which one breaking would double the number
- A recommendation that happens to match the vendor's largest service line, arrived at without visibly considering anything else
- Findings drawn entirely from management interviews, with no time spent beside the people who use the system daily
- No data was sampled, no code was read, and no environment access was requested
- Risks listed without owners, mitigations, or any indication of which ones matter
- A recommendation that requires a full replacement before anything of value ships
One question separates most of these quickly: ask which assumption, if wrong, changes the recommendation. A serious assessor names it immediately and can usually tell you what it would cost to test it early. Anyone who cannot has not done the work.
The sequence
- 1
Agree the decisions the assessment must resolve, and write them down before any discovery starts.
- 2
Get read access early to source control, a production-like database copy, monitoring, and the integration endpoints. Access delays are the main reason assessments run long.
- 3
Observe the two or three highest-value workflows with the people who perform them, in their environment, during normal operating hours.
- 4
Trace the business rules that carry money or risk through the code and confirm them against production data.
- 5
Inventory systems, integrations, data ownership, permissions, and the real deployment and recovery process.
- 6
Quantify the monthly cost of the current constraint and the capability it blocks, with ranges rather than false precision.
- 7
Draft the delivery sequence with an effort range and a named assumption per step, then review it with the operators before it reaches the sponsor.
- 8
Deliver the recommendation with the rejected alternatives and the conditions under which each would win.
A fifteen-year-old platform was rebuilt capability by capability, with the legacy and modern systems running side by side and a reversible cutover at every stage. The sequence came out of the assessment, not out of the build.
Common questions
- How is an assessment different from a discovery phase?
- Discovery is usually the front end of a project that has already been sold, and its purpose is to shape work that is going to happen either way. An assessment is bounded, paid for on its own, and can legitimately conclude that no project should follow. If the two are the same thing at a firm you are considering, the recommendation is decided in advance.
- Can we run the assessment with our own team?
- Often yes, and it is worth trying when you have a senior engineer who can be pulled off delivery for a few weeks. The two things internal teams struggle with are estimating work they have never done and reaching a conclusion that criticizes decisions their colleagues made. If either applies, use an outside assessor for the estimate and the recommendation while your team supplies the inventory.
- What access does the assessor actually need?
- Read access to source control, a production-like copy of the database, monitoring and error logs, integration documentation and endpoints, and calendar time with the people who use the system daily. Sanitize regulated data before sharing it and set the confidentiality terms in writing first. Access delays are the most common reason an assessment slips past its window.
- How long do the findings stay valid?
- About six to nine months for the technical inventory, and less if the business is changing quickly or key staff leave. The workflow map and data findings age slowest; effort estimates age fastest, because they depend on staffing and on assumptions that get tested. If more than a year passes before you act, revalidate the estimates rather than the whole document.
- Should the assessment recommend a specific technology stack?
- It should narrow the field and explain the constraints (hosting model, integration requirements, hiring market, existing team skills, compliance obligations) rather than name a framework as though the choice were the point. A stack chosen before the workflows are understood is a preference presented as a finding. The exception is when a hard constraint genuinely eliminates options, and then the constraint should be stated plainly.
- What if the assessment says to keep the current system?
- Then it did its job and you spent a small amount to avoid a large one. That outcome is common where the system is stable and the real problem is a single integration, a reporting gap, or a process that can be fixed without touching the platform. Keep the risk register and the named triggers, and revisit when one of them fires.