To evaluate a legacy modernization vendor, ask for evidence in six core areas: how they assess your system, references you can call, a written rollback plan, how they reconcile data, who will do the work and for how long, and what support follows go-live. Score every vendor on the same sheet, and weigh evidence above presentations.
Most guides on legacy modernization help you choose a technique or assess your own estate. This one helps you choose the people. It assumes you already know roughly what you have and what you want, and you now face three or four vendors who all say they can do it. For the techniques, read legacy system modernization options; for the buyer-side inventory, the legacy modernization assessment checklist; for tooling, legacy modernization tools and approaches compared. We do not repeat those. If you want a team to plan and carry out the work, see our legacy software modernization page.
Key takeaways
- Ask for artefacts, not claims: a sample assessment report, a rollback plan, a reconciliation report from a past project (with names removed if needed).
- A reference you can call, on a similar project, is worth more than a case-study page. Ask for one where something went wrong, and how it was handled.
- A vendor who offers only one approach for every situation is selling a method, not advising you.
- SLAs differ widely and have no universal standard. Set the response, restoration and hours of cover from the cost of an hour of downtime in your business.
- Read what the SLA excludes and what its credits are. Credits rarely cover business loss.
- A short proof on a real slice of your system shows more than any proposal.
What evidence should a vendor provide during an evaluation of legacy system replacement?
A vendor should show how they assess, who has used them, how they would undo a failed cut-over, how they prove the data moved correctly, who will work on your project, and what support and exit terms follow go-live. For each, ask for a document, a person or a demonstration.
| Evidence | What good looks like | Red flag |
|---|
| Assessment method | A sample of their real deliverables: application inventory, dependency map, data-quality profile, risk register and an options paper with more than one route | A workshop and a slide deck, with the approach decided before the assessment |
| References | Two or three clients with similar size, stack and risk who agree to a call, including one where the project met difficulty | Only written testimonials, or references from unrelated work |
| Rollback plan | A written plan per cut-over: go and no-go criteria, who decides, point of no return, how data written after cut-over is handled, and a rehearsal | "We have never needed one" |
| Data reconciliation | Counts, control totals and sampled record checks, run before and after, signed off by your business owners, with a defect log | "We will check the data after go-live" |
| Test approach | Tests that capture current behaviour before changing it, so the new system can be compared with the old | Testing described only as user acceptance at the end |
| Team and continuity | Named people for the roles that matter, their experience, and what happens if one leaves | A team announced only after the contract |
| Subcontracting | Clear statement of who does the work and which parts, if any, are subcontracted | Vague answers about "partners" |
| Ownership and handover | Source code, documentation and environments pass to you, with a knowledge-transfer plan | Proprietary components with no exit route |
| Governance | A fixed reporting rhythm, a risk log you can see, and a way to stop the project at defined gates | Status reported only as a percentage complete |
The six core areas map to the rows above: assessment method, references, rollback plan, data reconciliation, team and continuity, and ownership and handover (with support covered in the SLA section). Test approach, subcontracting and governance are supporting checks.
If a vendor claims certifications or compliance, ask to see the evidence from the issuing body and confirm what it covers. Do not accept a logo as proof.
How should you check references?
Call the reference yourself and ask about the project that resembles yours. Ask what was promised, what happened, how problems were handled, who was on the team, whether the system is still in use, and whether they would hire the vendor again for the same job.
Useful questions:
- What was the situation before, and what exactly did the vendor change?
- Did the cut-over go as planned? What went wrong, and how was it recovered?
- How accurate was the data after migration, and who confirmed it?
- How did the vendor behave when the plan changed?
- Who supports the system now, and how well did the handover work?
- What would you do differently?
A vendor who cannot offer a reference you can call has told you something.
What should the assessment, rollback plan and reconciliation approach contain?
The vendor's assessment should produce an inventory, a dependency map, a data profile, a risk register and at least two options with reasons. The rollback plan should name the decision-maker and point of no return. The reconciliation approach should say what is counted, compared and signed, and by whom.
For rollback and reconciliation detail, our cloud ERP migration risks and rollback plan guide has a risk register and exit plan that apply to any migration. Ask the vendor to adapt that structure to your system, and read the result critically: a good plan lists what could go wrong specifically for your data and integrations, not general risks.
What are typical SLAs and support tiers for mission-critical application modernization vendors?
Support for mission-critical applications is usually described by severity levels, each with a target response time, update interval and restoration target, and by tiers that set the hours of cover. There is no universal standard, so the numbers are negotiated from your own tolerance for downtime.
Severity levels are usually defined by impact:
| Severity | Typical definition | What to specify in the contract |
|---|
| 1, critical | Production is down or a core process is unusable, with no workaround | Response target, update frequency, restoration target, 24-hour or business-hours cover, named escalation |
| 2, major | A major function is degraded, or a workaround exists but is costly | Response and restoration targets, hours of cover |
| 3, minor | A limited problem or a defect with a reasonable workaround | Response target and fix in a scheduled release |
| 4, request | A question, a configuration change or an enhancement | Response target and how requests are prioritised |
Support tiers usually differ in hours of cover and the speed of the targets:
| Tier (names vary) | Hours of cover | Typical fit | What to check |
|---|
| Standard | Business hours, working days | Back-office systems that can wait overnight | Time zone of the vendor's hours, and holidays |
| Extended | Longer weekday hours, some weekend cover | Systems used across several time zones | What counts as covered hours |
| Round-the-clock | All hours for critical issues | Revenue-critical or safety-critical systems | Whether it covers only Severity 1, and the on-call arrangement |
Read the following SLA terms closely:
- Response versus restoration. Response is when someone acknowledges the issue. Restoration is when service resumes. A fast response does not mean a fast fix.
- Availability. What is measured, over what period, and which maintenance windows and causes are excluded.
- RTO and RPO. Recovery time objective (how long you can be down) and recovery point objective (how much data you can lose). They set backup and failover design.
- Service credits. Usually a limited rebate, not compensation for business loss. Ask what remedies exist for repeated failures, including the right to end the contract.
- Escalation. Names, roles and routes, and a post-incident root-cause report after a critical issue.
- Scope. Which components are covered, including third-party software and your own infrastructure the vendor does not control.
As an illustration of the structure only, not a market benchmark: Severity 1 might specify a response within [X] minutes, an update every [Y] minutes, a restoration target of [Z] hours and round-the-clock cover, while Severity 3 might specify a response within [N] business days and a fix in a scheduled release. The bracketed values are yours to set.
Set the targets by working out what an hour of outage costs you, then match the tier and severity targets to that figure. Also ask who provides support after the project: the same team, or a separate group. Our software maintenance and support page describes the support side of this.
How do you compare the approaches of top consultancies for modernizing complex legacy systems?
Compare firms by method, not reputation: how they decide the approach, how they phase the work, who does it, how they price risk and how you leave. We do not rank consultancies, because the best fit depends on your system, your risk tolerance and your budget.
The vendors you meet usually fall into broad types. The descriptions are generalisations, and individual firms vary.
| Type | Typical approach | Often strong at | Questions to ask |
|---|
| Large consultancies and systems integrators | Programme-led, structured governance, often a defined methodology | Large, multi-system programmes with many stakeholders | Who will actually staff the work, and what changes if scope moves? |
| Specialist modernization firms | Focused on a platform or technique, often tool-supported | Particular stacks, such as a specific language or platform migration | Do they present options outside their specialty? |
| Product and tool vendors | Automated conversion or a platform to run on | Speed and consistency where the code suits automation | What happens to the generated code, and who maintains it? |
| Custom software developers | Assessment, then incremental rebuild around the business process | Systems where the workflow needs to change | Can they show comparable work, and how do they handle risk? |
Then compare on seven questions. Does the vendor present several options with reasons? Do they phase the work so value arrives early? Do they test current behaviour before changing it? Is the commercial model clear, and how are changes priced? Who owns the code and documents? What is the exit route? How do they support the system afterwards?
Scorecard (copy and weight)
| Criterion | Weight (1-5) | Vendor A (0-3) | Vendor B (0-3) | Vendor C (0-3) | Evidence |
|---|
| Assessment method and sample deliverables | | | | | |
| Reference calls on similar projects | | | | | |
| Rollback plan quality | | | | | |
| Data reconciliation approach | | | | | |
| Test approach | | | | | |
| Named team and continuity | | | | | |
| Ownership, handover and exit | | | | | |
| Support terms and SLA | | | | | |
| Governance and reporting | | | | | |
| Proof on a real slice | | | | | |
| Commercial model and change control | | | | | |
Score 0 for no evidence, 1 for a claim only, 2 for a document or demonstration, and 3 for a document plus a reference who confirms it. Sum weight times score, but look first at any must-have scoring 0 or 1.
How should you run a proof on a real slice of your system?
Choose one data domain and one workflow, agree the success criteria and reconciliation checks first, and give every shortlisted vendor the same slice. Protect the data: use masked or anonymised data where possible, put an NDA and data-handling terms in place before sharing anything, and agree who pays for the proof and who owns the output.
Worked example (illustrative numbers)
A committee compares three vendors on 11 criteria at equal weight, scored 0 to 3, so the maximum is 33 points. Vendor A scores 19 with strong references but a weak rollback plan. Vendor B scores 22, shows a sample reconciliation report and has a callable reference. Vendor C scores 15 but has the lowest quote and has no written rollback plan. The committee asks A and B for a proof on one data domain and one workflow, then decides after comparing the reconciliation results. All numbers are illustrative.
When is this the wrong approach?
A formal evaluation of this weight is excessive for a small, well-understood system that one competent developer could replace, and premature before you have decided scope and approach. Run the internal assessment first. It also will not help if the real constraint is internal, such as no business owner to sign off data.
Glossary: SLA, service level agreement. RTO, recovery time objective. RPO, recovery point objective. Cut-over, the moment users switch to the new system. Reconciliation, proving that data matches between old and new.
How Timeline Digital approaches this
Timeline Digital, a custom software company founded in 2013 in Islamabad, Pakistan, delivers modernization work remotely. For legacy work we begin with an assessment of your system, set the schedule from your requirements in the Plan step (there is no fixed timeframe), and can build a free pilot of 2 to 3 key modules for you to test before the final agreement. Source code transfers to you on full payment, and long-term support under a service level agreement follows launch. We are a custom software developer, one of the vendor types in the table above, so apply the same scorecard to us.