How to Choose Legacy Modernization Partners: the Questions to Ask and How to Evaluate Proposals

How do you choose legacy modernization partners?#

Choose the legacy modernization partner whose proposal passes five tests: dated milestones, a described scope of work, a plan for the old system, paid discovery first, and an exit plan. Every pitch you hear will sound competent, because pitching is a skill firms practise. However, a proposal is a written promise, and a written promise can be checked.

The first three tests do not come from a seller. GAO set them out in its July 2025 report on legacy systems. A plan should hold "(1) milestones, (2) a description of the work, and (3) details regarding disposition of the legacy system" at a minimum. Disposition is the formal word for what happens to the old system: when it is switched off, and how.

The other two tests come from the UK Cabinet Office. Its Digital, Data and Technology Playbook puts discovery first, a phase that asks "do we need to build something?" before anything is built. It also says "contracts should include a requirement to develop an exit plan" that hands the work from the outgoing supplier to the next one.

So the method is short. Ask five questions before any proposal is written. Then read every proposal against the same five tests, and score each one. In short, you judge the plan, not the people presenting it.

What are you actually hiring a modernization partner to do?#

You are hiring a partner to move spending from keeping an old system alive to changing it, and GAO found 79 percent of planned federal IT spending still goes on keeping systems running. That figure comes from GAO's July 2025 report, which drew on the federal IT dashboard for the 24 Chief Financial Officers Act agencies. Only 21 percent was planned for building, changing or improving systems.

Your own split is probably not that extreme. Even so, the shape is common, and it tells you what the hire is for. A good partner shifts money and time from upkeep to change. In particular, it does that while the business keeps running on the old system every day.

That second part is where proposals differ most. For instance, Microsoft's Cloud Adoption Framework lists the usual moves. They are "replatforming (moving components to a new hosting environment), refactoring (optimizing or restructuring code), and rearchitecting (redesigning the system's structure)." Each one changes the system in place. Because the system stays live, a proposal must show how orders, invoices or claims keep flowing during every step.

So treat the partner's job as a change to where the budget goes, made under load. A proposal that only describes the new system has described half the job. The other half is the old system, and it is still your business until the day it is switched off.

Which questions should you ask before any proposal is written?#

Ask five questions before any proposal exists, starting with what the partner must learn about your system before it can scope the work honestly. Because a proposal is a polished document, its polish hides gaps. Meanwhile, a first conversation shows how a firm thinks, before it knows what you want to hear.

Discovery comes first for a plain reason: most owners do not know their own estate. The UK Department for Science, Innovation and Technology (DSIT) published its State of digital government review on 21 January 2025. It found that "around 15% of survey respondents could not even estimate the size of their legacy estate" at all. So if a government department cannot size its estate, a firm that quotes a fixed scope after one call is guessing.

Here are the five questions, in the order to ask them.

1. Discovery. What do you need to learn about our system before you can scope this, how long will that take, and what will we get at the end of it?
2. The work. Which parts of the system will change, which parts stay as they are, and how will we know each part is done?
3. The old system. When, and on what condition, is the old system switched off, and who decides?
4. The milestones. What are the first three dated milestones, and what will we be able to use at each one?
5. The exit. If we part ways halfway through, what do we receive, and how does the next team pick up the work?

First, send the list ahead of the meeting. For example, a firm that answers question 3 with a date and a condition has thought about your business. A firm that answers it with "once the new platform is live" has thought about its own delivery. Then write the answers down, because the proposal will be checked against them later.

What does an evasive answer sound like?#

An evasive answer names a method or a tool, while a strong one names a date, a deliverable, a person on your side who must decide, or a condition for stopping. You do not need to judge the technology to hear the difference. You only need to ask what the answer commits the firm to.

Take the discovery question. An evasive answer offers "a proven assessment framework" and stops there. For example, a strong answer offers three weeks, with two of your people for a few hours a week. Then it promises a written map of the system and a scope you can take to anyone. The second one can be checked when it is due. As a result, it can also be broken, and that is exactly why it is worth more.

The same test works on every question.

1. The work.

   "We follow agile best practice" commits to nothing. In contrast, "the order screens change first, and billing stays as it is until month five" commits to a sequence.

2. The old system.

   "We decommission once the new platform is stable" has no date. However, "the old order module goes read-only after two clean month-end closes" names a condition, and "your finance lead signs that off" names an owner.

3. The milestones.

   "Phase one, phase two, phase three" is only a sequence of labels. Instead, "by week eight your staff take real orders on the new screens for one region" is a test you can run.

4. The exit.

   "We build long-term partnerships" is a wish. By contrast, "you own the code and the documents from day one, and we write a handover plan in the first month" is a promise.

Lock-in deserves one extra question, because it is hard to hear. The UK Technology Code of Practice was last updated on 7 July 2025. It asks for open standards so that technology "can easily be upgraded and expanded" later. Therefore, ask the partner which parts of its plan another firm could not take over. A strong answer names them and says why. An evasive one says there are none.

How do you evaluate legacy modernization proposals against each other?#

Score every proposal 0, 1 or 2 on each of the five tests, so a rewrite and a gradual replacement are judged on the same ten points. Proposals rarely recommend the same approach. One firm wants to rebuild, another wants to replace the system piece by piece. Comparing approaches directly turns into a debate about technology, and the boldest pitch tends to win it.

Instead, score what each proposal commits to. Give a 2 when the test is met in writing, with a date or a named owner. Give a 1 when it is mentioned but vague, and a 0 when it is missing. In practice, teams that choose legacy modernization partners by the pitch skip this step, and the gaps only show up once the contract is signed.

Here is a worked example with three proposals for the same order system. The numbers are illustrative, chosen to show how the scoring behaves.

Illustrative example: scores are invented to show the method, not drawn from real proposals.

Proposal A had the best slides and the most detail about the new system. However, it never said when the old system would be switched off, it fixed the scope before any discovery, and it said nothing about leaving. So it scored 4 of 10. Proposal B was plainer, yet it named a switch-off condition and a paid discovery phase, so it scored 9.

A tie on the total is not a tie in risk. Also look at where the zeros fall. A 0 on the old system or on the exit costs you after the contract ends, when you have the least power to fix it.

What must a proposal say about the old system and about leaving?#

A proposal must say when and how the old system is switched off and how you would leave the partner, because legacy estates grow when nobody plans their end. These are the two tests most proposals skip. Also, they are the two that protect you once the contract is over.

The record shows what happens without them. DSIT's review estimated that 28% of systems in UK central government departments were legacy in 2024, up from 26% in 2023. In other words, the old estate grew in a year rather than shrinking.

GAO's third element covers the first gap. It asks for "details regarding disposition of the legacy system," which in plain words means a date, a condition and an owner for the switch-off. Otherwise, the new system arrives and the old one keeps running beside it. Then you pay for both, often for years.

The exit plan covers the second gap. The Cabinet Office playbook says contracts should include "a requirement to develop an exit plan" that joins the outgoing supplier's exit to the incoming supplier's start. That is the clause you will need if the partner is sold, falls behind, or simply stops being the right fit. While the relationship is good, it costs almost nothing to write. Once it goes wrong, it is the hardest thing to get.

So ask for both in writing, in the proposal itself, not in a later statement of work. A proposal that is silent on either has planned only its own part of the job.

Why do modernization plans stall even with a capable team?#

Of the 11 legacy systems GAO judged most in need of modernization in 2025, 9 had a plan and only 3 plans held all three elements. After all, these systems belong to large federal agencies that can hire capable people. Even so, the plans were incomplete far more often than the teams were short of skill.

GAO's July 2025 report also found that 7 of the 8 systems with incomplete or missing plans already had work underway. In other words, the work had started before the plan was whole. So that is the pattern to watch for in a proposal that is keen to begin.

The longer record points the same way. In June 2019, GAO named 10 critical federal legacy systems most in need of change. By February 2025, agencies had finished three of them, and seven were still not done. One of those seven had no planned finish date at all.

None of this proves any firm was weak. Instead, it shows that a missing milestone, a vague scope or an unplanned switch-off can stall work for years, whoever does it. Therefore, weight the plan above the pitch. You can check every figure here yourself in GAO-25-107795, which is public.

When is a modernization partner the wrong fit?#

A modernization partner is the wrong fit when nobody on your side can own decisions, when packaged software already does the job, or when no business outcome has been named yet. In each case, the better step costs less than a contract and teaches you more.

First, the decision owner. A partner can propose a switch-off date, but only someone on your side can agree to it. If that person does not exist yet, hire no partner yet. Instead, name the owner, then ask the five questions.

Second, packaged software. Sometimes the old system does a job that a product now does off the shelf. The playbook's discovery question, "do we need to build something?", is the honest test here. If the answer is no, the better move is to buy the product and use a partner, if at all, only to move your data across.

Third, the outcome. If you cannot say what should be faster, cheaper or safer after the change, no proposal can be scored well. A short paid discovery is the better first purchase, because it ends in a scope you own and can take to any firm.

In short, that chart is the cost of starting without a whole plan. Waiting a month to name an owner and an outcome is cheap by comparison.

What should you do before the first partner meeting?#

Before the first meeting, write down the five tests, ask the five questions, and score every legacy modernization partner's proposal on the same ten points. In short, that is the whole method, and it needs no technical knowledge.

To turn the questions into a written request, the software development RFP template shows how to structure it. For the wider questions any software partner should answer, see how to choose a custom software development company. Then, to know what the partner's software engineers should be doing inside the work, modernizing legacy code with AI covers recovering business rules before anything moves. Finally, incremental strangler migration shows what a piece by piece replacement looks like in practice.

If you want a team to run the discovery or the change itself, Atyantik offers paid product discovery and enterprise software modernization. Still, the GAO report and the Cabinet Office playbook are enough on their own to choose legacy modernization partners well, and both are free to read.