Hollinford is a UK legacy system modernisation specialist, which means this guide was written by a supplier. Treat it as a checklist for any provider you’re talking to, including us.
The search for a partner usually starts when the system still runs, but your team is reluctant to modify it. The developer who built it left years ago, releases eat a weekend of manual testing, and every change request comes back with caveats attached.
Picking the wrong partner costs more than the contract. You might have to pay for two systems if your programme stalls, with the new one half-built and the old one still operating. Below you’ll find six criteria, the proof worth asking for, four pricing models, five checks for AI claims, eight red flags, and ten questions for the first meeting.
The Short Answer: Six Things to Judge
To choose a legacy system modernisation partner, judge every provider on six things: experience with systems like yours, assessment before proposal, delivery model and continuity, ownership and exit, security and data handling, and commercial transparency. Hollinford suggests scoring each shortlisted provider on the same six, in writing, before anyone shows you a price.
- Experience with systems like yours. Roughly the same age, stack, code size, and sector.
- Assessment before proposal. They look at your system before they quote.
- Delivery model and continuity. Named engineers, releases in phases, a way back if one fails.
- Ownership and exit. The code, tests, and documentation end up with you.
- Security and data handling. You know where your code sits and who can see it.
- Commercial transparency. Pricing, scope changes, and exit terms in writing.
If a provider goes vague on any of these (test suite ownership is a common one), make sure to note it: that gap often tells you more than the pitch.
Why “Best Companies” Lists Do Not Answer the Question
Many “best companies” lists rank providers by headcount or revenue. Neither number tells you whether a team has done legacy system modernisation on an estate like yours, and that’s the question that matters. One of the larger software modernisation companies may never have opened a 20-year-old Delphi application, while a team of twelve may have migrated three.
Most clients arrive at Hollinford with a shortlist already in hand and one worry: how do you tell a credible plan from a confident sales pitch? The rest of this guide tries to answer that.
You may not need an outside software development partner at all. If your own team still understands the code and the system is small, an internal programme plus a short external review can be enough.
Six Criteria for Judging a Modernisation Partner
The scorecard below is the one Hollinford would hand any buyer comparing application modernisation partners. There’s a row per criterion, with a good and a worrying sign for each. Fill in one copy per provider during the sales process, while everyone is keen to answer.
| Criterion | What to check | Good sign | Worrying sign |
|---|---|---|---|
| Experience with systems like yours | Age, stack, code size, sector | A similar project with “before” figures | Only new builds from scratch |
| Assessment before proposal | Analysis before the price | Roadmap, risk register, and executive summary | A price and a “rewrite” plan before analysis |
| Delivery model and continuity | Named engineers, phases, rollback | The same people from proposal to handover | The team changes after signature |
| Ownership and exit | Rights to code, tests, and documentation | You own all of it, with no lock-in | The provider keeps the tests or tooling |
| Security and data handling | NDA, code location, UK GDPR roles | Code stays in your infrastructure | Vague answers about where copies go |
| Commercial transparency | Pricing model, change process, exit terms | A written method for pricing changes | Scope changes handled “case by case” |
Experience with systems like yours. Ask for one project that started roughly where you are now. Good answers come with “before” numbers (hours of manual testing per release, say) and what they turned into.
Assessment before proposal. If the first document you get is a quote, ask what it rests on. A roadmap and risk register should come before any price, and a “rewrite everything” verdict after one sales call is a guess.
Delivery model and continuity. Will the engineer on the call in week one still be on the project in week eight? Ask that directly. Then ask how releases are staged, how old and new systems run side by side, and how they pick phased or big-bang delivery.
Ownership and exit. The contract should hand you the code, the tests, and the documentation as they’re produced. Picture giving the work to another team next month: could they carry on with only what’s in your hands?
Security and data handling. If the provider handles personal data from your system, they’ll usually be your processor under UK GDPR, which means a written contract. The ICO’s guidance on processor contracts sets out what it has to cover. On their own security, the NCSC’s supply chain guidance points to Cyber Essentials as one practical check.
Commercial transparency. Could you explain the pricing model to your finance director in two sentences? If not, ask again. The change procedure belongs in writing too, including who signs off on extra costs and how you stop after any phase.
Proof to Ask for Before You Shortlist
Before a shortlist of legacy migration providers is final, ask each one, Hollinford included, for five pieces of evidence. Sales decks make claims, and these documents let you check them. Pay special attention to those that arrive slowly, or do not arrive at all.
- Two reference conversations with clients whose projects resembled yours. A twenty-minute call covers what a case study leaves out. Ask what happened the first time a release went wrong, and how the provider handled it.
- A sample assessment output, anonymised. Look at how specific the roadmap and risk register are. Do they name modules and dependencies, or would the same advice fit any system? For comparison, our Legacy Health Check ends with a prioritised roadmap, a risk register, and an executive summary.
- A sample rollback plan. You want to see steps, owners, and a target time to restore. A line in a proposal saying “rollback is supported” doesn’t count, so ask when the plan was last used for real.
- The contract terms on code ownership. Read the intellectual property clause early, while it’s still cheap to change, and check it covers tests and documentation as well as code.
- The names of the engineers who will work on your system. Look up their backgrounds, and talk to at least one of them before you sign.
Pricing Models Compared
At Hollinford, we see four pricing models in the legacy system modernisation proposals clients show us: fixed price, time and materials, phased fixed price after assessment, and subscription. Each splits the risk between you and the provider differently, and the optimal route for you depends on how well anyone understands your system on the day you sign.
| Model | When it fits | Risk the buyer carries |
|---|---|---|
| Fixed price | A small, well-documented system with scope agreed after an assessment | Set before analysis, the price hides assumptions, and surprises come back later as change requests or cut corners |
| Time and materials | Exploratory work where scope will move as the system is opened up | Cost can grow without a ceiling, so you need weekly figures for hours and progress |
| Phased fixed price after assessment | Most legacy work: a short assessment, then each phase priced on its findings | Each phase price is only as good as the assessment behind it. Your exposure stops at one phase |
| Subscription | Ongoing support and improvement after the main migration is live | Paying for capacity you don’t use. Check minimum terms and notice periods |
Say a provider quotes a fixed price to migrate an ERP system that nobody on their side has seen. Ask which assumptions sit behind the number, and what happens when one turns out wrong.
You can read how Hollinford prices its work on our pricing page. For reference, our Legacy Health Check costs £5,000 plus VAT and takes two weeks from agreed access.
AI Claims to Test
AI features in many legacy software modernisation proposals now, and Hollinford advises testing every claim made for it. The tools can speed up code analysis and documentation, but they can also produce confident errors, which is why the five checks below look at review time, where your code goes, and what you pay.
- Which tasks does the AI do? Usually some mix of code analysis, documentation, and test generation. Get the exact list and who signs off on each output.
- How many hours of human review are budgeted? Look for a number in the plan, phase by phase. “Our engineers check everything” with no hours attached is a sales line.
- Where does your code go? Some tools send code to an outside AI service, and some run in your infrastructure. If that service receives personal data, it may count as a sub-processor, and under UK GDPR that needs your prior written authorisation.
- Is there a before-and-after example? Ask to see AI-generated documentation for a system like yours next to the original code. Would you trust it?
- Do the savings show up in the price? If AI really cuts analysis from weeks to days, you should see that in the quote or the timeline. Ask where.
Red Flags
In Hollinford’s view, any of the eight indicators listed below is enough to pause talks with a provider. While a single one might be innocent, two or three usually mean that the provider is making promises before anyone has studied your system.
- A fixed price before any analysis. Until someone has reviewed your code, any fixed figure has to rest on untested assumptions.
- “Rewrite everything” without an assessment. A full rewrite is the riskiest option, so check whether a smaller change would work first.
- No named engineers. Without names, you can’t check the team’s experience, and the people you meet may not do the work.
- No rollback plan. Ask how a failed release would be reversed. If the answer stays vague, request the plan in writing.
- AI claims without review hours. AI output still needs human checking, and without review time, errors can reach your users.
- Case studies with no “before”. When only the finished system is shown, it’s hard to judge how complex the starting point was.
- The provider keeps the code or tests. That makes switching providers later harder, since future work would go through them.
- Pressure to sign quickly. A deadline like “price valid until Friday” rarely suits a programme that runs for months. Take your time.
Ten Questions to Ask Every Provider
Hollinford gets asked these ten questions on first calls more often than any others. Each has an answer you can check, so they work with any provider. Keep the order fixed from one meeting to the next, since comparing like with like is half the job.
| # | Question to ask | What a strong answer sounds like |
|---|---|---|
| 1 | Which systems like ours have you modernised, and what changed afterwards? | A named stack, with before and after figures |
| 2 | What will you assess before you give us a price? | A fixed-length assessment with written outputs |
| 3 | Who exactly will work on our system, and will they stay for the whole project? | Names, roles, and a clause on team changes |
| 4 | How do you keep the old system running while the new one is built? | A parallel-running plan with dates and owners |
| 5 | What is the rollback plan if a release goes wrong? | A rehearsed, written procedure with a time to restore |
| 6 | Who owns the code, the tests, and the documentation at the end? | You do, from the day each is produced |
| 7 | Where does our code live during the work, and who can see it? | Your infrastructure, with a named access list |
| 8 | Which parts of your process use AI, and how many hours of human review are budgeted? | Named tasks, with review hours per phase |
| 9 | How do you handle a change in scope once the work has started? | A written procedure, with your approval before any extra cost |
| 10 | What happens if we decide to stop after the first phase? | You keep all outputs and pay for completed work |
On question three, if the answer is “a senior team”, ask for names in writing.
Try all ten on us during a free Discovery Call, and keep the answers to compare with other providers whether or not you go further.
How Hollinford Approaches the First Conversation
The first conversation is a free Discovery Call. We listen to how your system works and what’s pushing you to change it, and if a closer look makes sense, Hollinford proposes a Legacy Health Check: £5,000 plus VAT, two weeks from agreed access. You get a prioritised modernisation roadmap, a risk register, an executive summary, and a one-hour walkthrough.
Everything runs under NDA, your code stays in your infrastructure, and there’s no lock-in.
The call is about your options, and what you learn stays with you whether or not you continue.
Frequently Asked Questions
What Is Legacy System Modernisation?
Legacy system modernisation means updating an ageing application, database, or platform so it stays secure and can keep changing. The work ranges from refactoring and re-platforming to phased replacement or a full rewrite.
How Long Does Choosing a Partner Take?
Usually several weeks. Proof, reference calls, and first meetings all take time, and Hollinford recommends leaving room for a short assessment, because a real plan is easier to compare than a pitch.
Should I Ask for a Fixed Price Upfront?
Yes, once an assessment is done. Before that, any fixed price rests on guesses. A phased fixed price agreed after the assessment gives you a firm number for each stage.