Why the Choice of Partner Matters More Than the Choice of Technology
There is a tendency to treat technology partner selection as a technology decision, but that is not the case. The framework or cloud platform that a partner prefers matters far less than how they think about your business, how they manage risk, and whether they have done this kind of work before at your scale.
Consider a scenario that plays out more often than it should: a company chooses a partner on price, signs a contract for a fixed-scope rewrite, and eight months later has nothing deployable to show for it. The technology choices were fine, the team was skilled, but nobody had assessed the existing system before scoping the work, and the contract left no room for the surprises that come with legacy software. Eight months behind schedule and over budget, the company started again.
Legacy system modernisation is not a commodity service. Every legacy system is different, and the partner you choose needs to understand that.
The 8 Questions to Ask Any Legacy Modernisation Partner
Put these to any shortlisted partner, in an initial discovery call, a formal RFP, or a reference check — each one is a filter. A bad answer, or an evasive one, is almost always worth taking seriously.
1. "Do you start with an assessment, or jump straight to a quote?"
This is the single most important question on the list, and the one most commonly skipped. A partner who offers a fixed price for "legacy modernisation" without first examining the system is quoting blind. Legacy systems contain undocumented logic, informal workarounds, and integrations that nobody wrote down. A quote produced without a structured assessment is not a quote — it is a guess with a pound sign in front of it.
Before committing to scope or cost, a good partner will start with an assessment or discovery phase, asking questions about your business processes, your team, and your priorities, not just your technology.
Our approach at Hollinford starts with a Legacy Health Check before any project scope is agreed.
2. "Have you modernised systems like ours before?"
Experience in legacy modernisation is not one-size-fits-all. An SMB's realities, like tighter budgets, smaller teams, and less formal documentation, might not be clear to a company that has only modernised a financial services platform for a 2,000-person enterprise.
Ask specifically what size businesses they typically work with, and whether they can show you a completed project with a company of comparable size and complexity to yours. As CIO.com's guide to choosing the right software vendor notes, asking vendors for references in your industry is a starting point, but the more revealing question is how long they have retained clients: sustained relationships are a stronger indicator of delivery quality than a polished case study.
3. "What is your approach to risk and business continuity?"
For most SMBs, the legacy system being modernised is the system that the business runs on, so the question of "what happens to daily operations during the project?" is often the central one.
A partner with genuine experience will describe phased delivery, parallel running periods, and rollback plans. The strangler fig pattern (where new functionality is built alongside the existing system and gradually takes over) is one well-established approach. As Catapult CX puts it, the aim should be controlled change, not a high-risk big-bang launch: running old and new systems in parallel and prioritising critical business journeys throughout.
4. "Who will actually do the work?"
This question sounds blunt, but do ask it anyway. Larger consultancies have a well-established pattern: senior people lead the sales process; the delivery team is different, often less experienced, sometimes in a different location entirely. Make sure to ask directly: will the people you are meeting now be involved in the project? For UK-based SMBs, a partner in the same or a nearby time zone matters, as daily stand-ups, quick questions, and ad hoc calls are harder across a five-hour time difference.
5. "How do you handle scope changes and unexpected complexity?"
Legacy software contains surprises. This is not a flaw in your system; rather, it is the nature of software to be maintained and extended over years or decades. Undocumented integrations, data stored in unexpected formats, business logic embedded in places nobody thought to look: these are normal findings in any legacy assessment. What matters is how a partner plans to deal with them.
A good partner will describe an iterative approach in which the project plan adapts to new findings, and you are consulted before significant alterations are made. Many propose a time-bounded discovery phase at the start to make these issues known before the main work begins. TechnologyMatch's vendor selection criteria guide identifies change management process as a core evaluation criterion for any technology partner relationship.
6. "What happens after go-live?"
Modernisation does not end when the new system goes live. The process involves things like training the team, resolving issues that only appear in production, and ensuring the system functions in real-world scenarios.
A good partner will have a clear handover plan: documentation, training, and a defined support period after launch. This is also the moment to ask about independence. A modernisation project that leaves you dependent on the same partner for every future modification has replaced one form of lock-in with another. Pragmatic Coders note that when operational knowledge exists only in a few external developers, switching becomes costly precisely when you need it most.
7. "Can you show us results at each stage, not just at the end?"
Paying for months of work before seeing any tangible results is risky. Additionally, it is not required in legacy modernisation, where the current system must continue to function while the new one is being developed.
A partner working iteratively should demonstrate working software at regular intervals, typically every two to four weeks. This allows you to provide feedback, catch problems early, and verify that progress is real.
8. "Do you understand our business, or just our technology?"
This is the question that separates competent IT vendors from reliable digital transformation partners.
Legacy systems reflect years of accumulated business logic: decisions about how the company operates, how data flows, and what the system needs to do. A partner who does not understand your business will make technical decisions that make sense on their own but are wrong in the bigger picture.
You can hear the answer by the way they carry on the initial conversation. A company focused on technology will talk about frameworks, cloud providers, and migration approaches, while a company concentrated on the business will ask how the system is used, who uses it, what breaks when it goes wrong, and what the organisation's priorities are. If you reach the end of an initial meeting and nobody has asked about your business, that is a meaningful signal.
Red Flags to Watch For
Across all eight questions, certain patterns indicate a partner unlikely to be the right fit.
- A fixed price without a prior assessment. Any quote made without reviewing the existing system will either have extra room for error or become a source of disagreement when things get complicated.
- "We will rewrite everything from scratch." An experienced partner considers a full rewrite only when incremental modernisation is truly not viable, and they can explain why.
- No SMB experience in their portfolio. Scale changes communication patterns, budget structures, and tolerance for disruption. Enterprise experience does not automatically transfer.
- Senior people on the pitch, different team on the project. This happens quite frequently, so make sure to ask directly who will be assigned before the contract is signed.
- No defined post-launch plan. Training, documentation, and support are part of the project, not an afterthought, which means that a partner who disagrees is not thinking about your long-term success.
- Technology-first, business-second conversations. If a partner cannot explain their proposal in terms that a non-technical leader can follow, that gap will widen once the project starts.
A Practical Checklist for Your First Meeting
Take this to any initial meeting with a prospective partner.
| Question | What a good answer sounds like | Red flag |
|---|---|---|
| Do you start with an assessment? | "We do a structured assessment before scoping any project." | Fixed price without seeing the system |
| Do you have experience with businesses of our size? | Specific examples with comparable company size and system type | Only enterprise case studies |
| How do you protect business continuity? | A phased delivery plan with parallel running or rollback options | "We rewrite and then cut over" |
| Who will actually work on this? | Named or described team, with clear seniority and location | Vague or evasive answer |
| How do you handle scope changes? | An iterative process with defined change management | Rigid fixed scope or no scope at all |
| What happens after go-live? | A handover plan with documentation, training, and a support period | Post-launch support treated as a separate sale |
| Can we see progress before the end? | Regular demos or deliverables at defined intervals | "You'll see the full system at the end" |
| How do you learn about our business? | Questions about operations, users, and priorities, not just tech | Discovery call focused entirely on technology |
How Hollinford Answers These Questions
We include this section not to close the conversation, but to be direct about where we stand.
We begin every engagement with a Legacy Health Check: a structured assessment of your system, processes, and business context before any project scope is agreed. We do not quote blindly.
Our experience is specifically with small and medium-sized businesses in the UK: companies with 10 to 200 employees, operational constraints, and systems that need to keep running while the work happens. We use phased delivery as a default, with working software demonstrated every two to four weeks.
The people you speak with during discovery are involved in the work. We do not staff projects with junior developers after the pitch. Documentation, training, and a defined support period are part of every project. Our goal is to leave your team able to maintain and extend the new system without depending on us.
If you are interested, learn more about how we work and our legacy modernisation services.
Key Takeaways
- The choice of partner matters more than the choice of technology. A good partner with the wrong stack will outperform a bad partner with the right one.
- Use these eight questions as a filter. They separate partners who have done this kind of work before from vendors who are learning on your project.
- The biggest red flags : a fixed price without an assessment, a big-bang rewrite, and no plan for after go-live.
- Relevant experience at your scale matters. Enterprise experience does not automatically transfer to an SMB context.
- IT vendor due diligence does not need to be complicated. Eight questions, asked directly, will tell you most of what you need to know.