How to Choose an IT Provider Without Regrets Two Years Later

Changing IT providers is expensive, and almost never because of the invoice. The real cost appears when the previous provider leaves with the knowledge in its engineers' heads: no one knows why that server has that configuration, where the backup credentials are, or what that firewall rule no one dares to touch means. Operations keep running, but any change becomes an expedition.

The good news is that this risk can be detected before signing. You don't need to be an infrastructure expert to evaluate a provider: you need to ask the right questions, request written answers, and be wary of answers that sound good but commit to nothing. This guide gathers what to review during selection, how to read the answers, and which signals should stop the negotiation.

1. Who owns the documentation and the code?

The equipment inventory, network diagrams, configurations, operating procedures, and integration code should belong to the client. If the provider considers them its own assets, the relationship is not a partnership: it is a dependency.

It is worth requesting this explicitly in the contract and, above all, verifying how it is delivered in practice. A useful question during the evaluation is to ask for a sample of the documentation they deliver to their current clients: if it exists, is up to date, and has an owner's name, that is a good sign. If the answer is "we handle that internally," we already know how the relationship will end.

• Is the documentation delivered in open, editable formats, or only as a closed PDF?
• Is it updated with every change, or reconstructed when someone asks for it?
• Does the client have access to the administration consoles and credentials, or does everything go through the provider?
• Who owns the custom scripts, automations, and developments?

A detail that is often overlooked: ownership of licenses and cloud accounts. If the cloud accounts, domain, or licenses are in the provider's name, changing providers stops being a business decision and becomes an emergency migration.

2. How is compliance measured, and with which indicators?

"We have 24/7 support" is not an indicator, it is a phrase. What works is a service level agreement with defined metrics, calculation formula, measurement period, and consequences when it is not met.

When reviewing the proposal, it is worth noting what is actually being measured. A fifteen-minute response time means nothing if the resolution time is three days. And a 99.9% availability percentage means little if it is not clarified what counts as an outage, how it is measured, and what it excludes.

• Response time and resolution time, separated and defined by severity.
• Availability measured with an agreed tool, not with the provider's perception.
• Compliance with preventive maintenance and planned changes.
• Periodic reporting with the numbers, including the bad months.

There is a simple and very revealing test: ask for the last quarter's service report from two or three reference clients. A serious provider shares it, even when the numbers do not favor them. One that only shows slides of success stories is choosing what to tell.

3. Who designs and who operates? Who answers at three in the morning?

Many proposals are written by a sales team and a senior architect, and then daily operations are handled by a different team, sometimes outsourced, sometimes with high turnover. That mismatch appears in the first serious incident, when the person responding does not know the design and the person who designed it is no longer available.

It is worth asking for specific names and roles: who will be the technical account manager, who will handle day-to-day operations, who will be on call outside business hours, and what backup they have. If the provider cannot name anyone before signing, it probably cannot afterward either.

It is also worth understanding how they retain knowledge. A provider that depends on a single key person has the same problem as the client that depends on it. Asking about team turnover, internal documentation, and how they handle handover when someone leaves says a lot about the maturity of the operation.

4. What is the escalation plan, and has it been tested?

A phone number is not an escalation plan. A real plan has defined levels, criteria for escalating, maximum times at each level, and named owners. And, above all, it has been tested at least once.

During the evaluation, you can ask them to describe a real incident from recent months: what happened, how it was detected, how long it took them to find out, who made the decision, and what they changed afterward. The answer is usually more informative than any certification in the brochure.

• How is an incident reported, and through which channels?
• Who decides to declare a critical incident, and by what criteria?
• Is there a continuity and recovery plan, and when was it last tested?
• To whom is it escalated when the usual owner does not respond?

If the provider cannot describe an escalation with names and times, what you have is good will. Good will works until there are two simultaneous incidents.

5. What does an orderly exit look like?

Every contract should describe how operations are handed over to another provider or to an internal team. Not because the relationship is going to end badly, but because the existence of that plan changes the behavior of both parties throughout the relationship.

An orderly exit includes the delivery of updated documentation, the transfer of credentials and ownership, an agreed accompaniment period, the return of equipment, and the certified deletion of client data. It also includes deadlines: how long each item takes and what happens if it is not met.

The answer to this question says more about the provider than any sales presentation. Those who have a defined exit process usually also have an orderly operation; those who are uncomfortable with the question are betting on retention through friction.

Warning signs not to ignore

Beyond the five questions, there are behaviors that appear during the evaluation and anticipate problems:

• Rush to sign. A proposal that expires in 48 hours or a discount that disappears tomorrow usually indicates that the price is not sustainable.
• Vague answers to specific questions. If, when asked for the SLA, they respond with a list of services, there is no SLA.
• Resistance to naming the team. Turnover disguises itself as flexibility.
• References that cannot be contacted. Success stories without a name or phone number are not verifiable.
• Contracts without an exit clause. It is the point where it is most worth negotiating and the one most often omitted.

None of these signs is a condemnation on its own. But two or three together describe a pattern, and the pattern is what ends up being paid for two years later.

In closing: the decision is made with documents, not with trust

Choosing an IT provider is not choosing the one you like best or the one with the most polished presentation. It is choosing someone whose way of working is verifiable: documentation that exists and is delivered, indicators that are measured and shared, names that respond, a tested escalation, and an exit that can be executed without drama.

Trust in a technical relationship is built on evidence. If those five answers are in writing before signing, regret two years later has much less room to appear. And if any is missing, it is better to discover it now, when you can still choose, than in the middle of a forced migration.