Tendering for a Long-Term Technology Partner: A Buyer's Guide

Why this purchase is different

Buying a long-term technology partner is not buying developers. You are transferring responsibility for something the business already depends on.

Development resource is bought against a specification. You define the work, suppliers price it, and you compare the prices. The supplier’s job is to deliver what the document says.

Ownership of an estate cannot be bought that way. Nobody can write a specification for the next five years of an application that runs your operation. What you are actually buying is judgement: the ability to understand a system somebody else built, keep it running, tell you the truth about its condition, and decide what to change and in what order.

That difference should shape everything about the selection process. A process designed to compare fixed prices against a fixed scope will reliably select the wrong partner for open-ended ownership.

Should you run a formal tender?

Run a structured process. A formal tender is only necessary if your procurement rules require one.

Public bodies and regulated organisations often have no choice, and framework agreements exist for exactly this reason. In the UK public sector, buyers commonly use G-Cloud or Digital Outcomes and Specialists to shorten the process while staying compliant.

Most private-sector organisations are free to choose. In that case a lightweight structured process beats a full tender for three reasons.

• A formal tender takes months. If you are replacing a departing supplier, those months come directly out of your knowledge transfer window.
• Tenders reward tender-writing. The correlation between a polished bid document and a good working relationship is weak.
• Long documents suppress the questions you most want to hear. A supplier who has been given 60 pages tends to answer them rather than challenge them.

A structured process that works well looks like this:

1. A short written brief, five to ten pages
2. Three or four shortlisted partners
3. A working session with each, with their actual delivery people in the room
4. A scored comparison against criteria agreed before you meet anyone
5. A paid discovery or assessment with your preferred partner before the long-term commitment

The last step matters more than it looks. A short paid assessment lets both sides test the relationship on real work, and gives you an artefact you own whatever happens next.

What should the brief contain?

Give suppliers business context and the shape of the estate. Do not give them a technical specification.

For an existing estate, a heavy upfront specification tests whether a supplier can read a document. It does not test whether they can own a system. Worse, it invites suppliers to price the document rather than the reality, which is how you end up with a change request on day one.

A brief that produces useful responses covers:

• What the business does and how the system supports it, in plain language
• The estate at a high level: main applications, technology stack, hosting, rough scale
• Integration surface: how many interfaces, to whom, and how they are specified
• Who is involved: your internal team, their roles, and what they will keep doing
• The situation: why you are looking, and the timeline you are working to
• What good looks like in two years, expressed as outcomes rather than features
• How you will decide, including the criteria and their weightings

Publishing your evaluation criteria in the brief is unusual and worth doing. It tells serious suppliers what to address and it forces you to agree internally what matters before you are influenced by whoever presents best.

How many partners should you shortlist?

Three or four. This is the range where comparison is meaningful and the time you give each one is still worth having.

Two gives you no real comparison, and it is uncomfortable if one drops out. Five or more spreads your attention so thinly that every supplier gets the same generic pitch, which defeats the purpose.

Shortlist for genuine difference rather than for a tidy list. If all four candidates are the same size and shape, you are comparing sales teams, not approaches.

Which supplier archetype fits an estate handover?

Three archetypes bid for this work, and they win on different things.

The large integrator wins when you need breadth you cannot predict, global coverage across time zones, or the ability to add thirty people in a month. The trade is that your estate is a small account. The people who impressed you in the pitch are rarely the people who arrive, and turnover on the account is a structural feature rather than a failure.

Offshore development resource wins on cost per hour and on scaling a well-specified backlog. It struggles with ownership, because ownership requires someone to decide what should happen next, not just to build what was asked. It also puts a time zone and a contract boundary between your operation and the people who fix it.

The specialist partner wins on continuity and access. The same engineers stay on the estate, and you can reach the person who makes decisions. The trade is real: less surge capacity, and a narrower range of specialisms, so check that their range actually covers your estate rather than assuming it does.

None of these is the right answer in general. The right answer depends on whether your main risk is capacity or continuity. For an estate handover, it is almost always continuity.

Which evaluation criteria actually separate suppliers?

Most scorecards are full of criteria that every credible supplier passes. Those criteria feel rigorous and tell you nothing.

Design your scorecard around the things suppliers genuinely differ on.

Criteria that discriminate

Inherited-system experience. Not “have you worked with .NET”, but “describe a system you took over from another supplier, what you found, and what you changed in the first six months”. Most suppliers have far more greenfield experience than takeover experience, and takeover is a distinct skill.

Named people and their availability. Ask who specifically would work on your estate, what else they are committed to, and what happens when one of them leaves. A supplier who cannot name them yet should say when they can.

Breadth across the estate. An estate handover usually needs application development, cloud infrastructure, data, security, and support. Ask which of these they do themselves, which they partner for, and which they would expect you to keep.

Operational maturity. How incidents are classified, who is called at 3am, how a problem is distinguished from an incident, and what happens when a fix needs a release. Ask them to walk through a real incident from last quarter.

Willingness to disagree with you. In the working session, put forward a plan with a flaw in it. Suppliers who spot it and say so are showing you what the next five years feel like. Suppliers who agree enthusiastically are showing you that too.

Criteria that rarely discriminate

• Certifications, as a yes or no. Ask for the certificate and the scope instead. ISO 27001 and Cyber Essentials Plus are common enough that presence alone separates nobody, but scope and currency differ a lot.
• Technology lists. Everyone lists everything.
• Case studies chosen by the supplier. Ask instead for a reference from an engagement that went badly at some point, and how it was handled.
• Methodology names. What matters is what happens when the plan meets reality.

How should you weight the scoring?

Agree weightings before you meet any supplier, and write them into the brief.

A defensible starting point for a long-term ownership engagement:

• Capability against your estate: 30 to 35 percent. Can they actually run and develop this specific system.
• Transition and knowledge transfer approach: 20 percent. How they get from nothing to ownership, and how they de-risk it.
• Relationship and cultural fit: 20 percent. Judged from the working session, not from the document.
• Operational and security assurance: 15 percent. Support model, incident process, certifications with scope.
• Commercials: 15 to 20 percent. Total cost of the arrangement, not the headline day rate.

Cost sits below capability deliberately. On an ownership engagement, a partner who understands the estate needs less specifying, produces fewer regressions, and raises fewer change requests. A day rate difference of 10 to 15 percent is recovered quickly. Weight cost heavily only when what you are buying is genuinely commoditised, and estate ownership is not.

Be careful with total cost comparisons. Ask every supplier to price the same three things separately: the transition itself, steady-state support, and a notional allowance of development. Otherwise you will compare a transition-heavy bid against a support-heavy one and conclude nothing.

What should you ask in the working session?

The working session is the highest-signal part of the process. Use it to observe, not to be presented to.

Structure it as a working problem rather than a pitch. Put a real decision from your estate in front of them and see how they approach it.

Questions worth asking directly:

• “What would you want to look at in the first two weeks, and what would you expect to find?”
• “What is the most likely way this transition goes wrong, and what would you do about it?”
• “Which parts of our estate would you not take on, or would want to partner for?”
• “Tell us about a system you inherited where the documentation was wrong.”
• “Who is on the account in year three?”
• “What would make you tell us we are making a mistake?”

Watch the ratio of questions to answers. A supplier who asks more than they assert is usually the one who will understand the estate. A supplier who has a confident answer to everything before seeing the code is telling you something about how they will run the engagement.

Insist that the delivery people attend, not only the sales team. If the supplier resists that, you have learned something useful early.

What commercial structure fits estate ownership?

Separate the phases, because they carry different risk.

Transition. Fixed price or capped is reasonable, because the scope is bounded and both sides want it to end. Define completion by checklist, not by date.

Steady-state support. A monthly retainer against an agreed service level. Make sure the agreement states what is included, what counts as a change, and how the boundary is decided when it is disputed.

Development. Avoid fixing scope for years ahead. A capped investment with flexible scope works better for open-ended ownership, because it lets priorities change without a contract change every time.

Three clauses to settle before you sign, not after:

• Exit. You are running this process because a previous arrangement ended. Agree now what a good exit looks like: documentation standards, notice, transition assistance, and the rate for it.
• Intellectual property and access. Confirm you own the source code, and that repositories, cloud subscriptions, domains, and certificates sit in your accounts rather than theirs.
• Key person continuity. Name the roles that must be continuously staffed and what happens if they are not.

What do buyers most often get wrong?

Starting too late. If you are replacing a supplier who is winding down, the value of their knowledge falls every month as their staff leave. Start the selection while there is still someone to hand over from.

Over-specifying the brief. A long specification produces comparable but uninformative responses, and it hides the supplier who would have told you the specification was wrong.

Meeting only the sales team. The relationship you are buying is with the delivery team. If you never meet them, you have not evaluated it.

Treating the day rate as the cost. The expensive part of a bad fit is rework, regressions, and the change requests that follow a misunderstanding. None of that appears in the rate card.

Splitting application and infrastructure without defining the boundary. Two suppliers is a legitimate choice. Two suppliers with an undefined boundary is an outage waiting to happen. Decide who owns diagnosis before you need the answer.

Scoring the document instead of the behaviour. By the end of the process you will have a lot of evidence about how each supplier behaves under mild pressure. That evidence predicts the engagement better than the bid.

Next steps

If you are replacing a supplier who is winding down, the transition itself deserves as much attention as the selection. Our guide to a development partner transition sets out how knowledge transfer, parallel running, and handover of operational ownership fit together.

If the decision is between appointing a partner and building an in-house team, managed support versus hiring works through the comparison. If a supplier has already gone, start with what to do when your development team leaves.

To talk through your own selection, book a consultation.