How to consolidate business IT vendors step by step

What IT vendor consolidation means and when it makes sense

If your business pays separate suppliers for computers, phones, internet, email and security, you probably have an IT vendor problem. Consolidation means fewer, better-run relationships, with clear responsibility when something breaks.

It makes sense when the number of suppliers has started to cause pain. Common signs include:

• Nobody knows who to call when something breaks
• Two suppliers blame each other for the same fault
• Several contracts renew on different dates, with different terms

Consolidation is not always the right answer. A single supplier can create its own risk, and a provider that claims to do everything is usually good at very little. The aim is a small number of suppliers, each with a defined job and a named owner on your side.

Step 1: Map your current IT suppliers and spend

You cannot consolidate what you have not counted. List every supplier, including the small direct debits and forgotten subscriptions. Check where your files and data are stored too, as that often shows another layer of duplication.

For each supplier, record:

Total the spend. That is your spend baseline, and you will measure any saving against it.

Check each contract for early termination fees and auto-renewal clauses before you plan anything. Notice periods are often longer than people expect, and missing one can lock you in for another year.

Step 2: Run an IT supplier risk assessment

Before you move anything, assess the risk each current supplier represents. Consolidation can reduce risk, but a rushed switch can increase it.

Ask these questions for each supplier:

• Access: Do they hold admin logins to your systems, and who controls them?
• Data: Do they store or process customer or staff data?
• Continuity: What happens to your service if they go out of business?

Rate each answer as low, medium or high. Suppliers with admin access and no written response times go near the top of the list.

It also helps to know your own exposure at this stage. You can see what an attacker can already see before you decide which systems to move first. Check that the basics are covered too: layered cyber security, including endpoint protection, email filtering and multi-factor authentication.

Step 3: Compare managed IT support providers

A managed IT provider takes responsibility for keeping your systems running, for a fixed monthly fee, so your costs stop jumping every time something breaks. Use a simple comparison grid:

• Pricing: Is it a fixed fee per user, per device or per site? Ask what is not included, and what extra charges apply.
• Scope: Does the fee cover helpdesk, monitoring, patching and security? If a task is not listed with a frequency, assume it is not being done.
• Response and restore: Are both written into the contract, in minutes or hours, for each priority? Acknowledging a ticket is not the same as fixing the problem.
• People: Will you deal with the same team each time?
• Location: Will they come on site, and how quickly? If you are in Swansea or elsewhere in South Wales, that matters.
• Ownership and exit: Do you own your data, documentation, configurations and licences, with free export if you leave?

If you already have in-house IT staff, a co-managed IT model may suit you better. The provider backs up your IT person rather than replacing them. For what good local support looks like, read choosing local IT support for a small business. For the managed model in full, see managed IT support.

Ask each shortlisted provider for references from businesses of a similar size, including one that has left them. Ask to meet the people who will run your account, not just the salesperson. Vague answers tell you something.

Step 4: Build your IT vendor transition plan

With a shortlist in hand, write the transition plan in one shared document. For each service that is moving, record:

• Services moving: for example phones, internet, managed IT, backup
• Old supplier: name, end date and the date notice was given
• New supplier: name and go-live date
• Owners: one person on your side and one at the new provider
• Biggest risk: for example, email migration failure
• Mitigation: for example, a test migration with five mailboxes first
• Success measure: for example, no unplanned downtime in the first 30 days

Back up your data before any change, and agree a rollback option if a step fails. Schedule the move outside busy periods such as year-end or a major project launch. Plan for overlap rather than a hard cut-over, so the old service keeps running until the new one is proven.

Tell staff too. A short note explaining who to call, and when the change happens, prevents confusion on the first morning.

Step 5: Onboard the new provider without losing service

Onboarding is where most consolidations succeed or fail. Treat each service as its own small project with its own go-live date.

Start with discovery, not migration

Before anything moves, the new provider should describe your environment back to you: what is on the network, which services run where, who holds admin rights and which systems depend on which. This catches things nobody listed, such as a door access controller on the same switch as the office Wi-Fi.

Ask for a written dependency map. If a provider cannot produce one, they are planning to learn on your time.

Secure every admin credential before the old supplier leaves: firewall, backup keys, phone system and domain registrar. Collect network diagrams, device inventories, licence lists and configurations at the same time.

Sequence the migration by risk

The order matters more than the speed. A common pattern is:

1. Low-risk, self-contained services first. Backups, endpoint protection and email filtering can usually move without touching staff workflow.
2. Core productivity next. Email, then file shares, each tried with a pilot group before the wider rollout.
3. Telephony and connectivity last. These cause the most disruption if they fail, so they move once the rest is proven.

Run a pilot group of 5 to 10 users through each stage. Check email delivery, file permissions, printing and phone routing before widening the group.

Handle the details that trip people up

Most migration problems are boring and predictable:

• DNS and domain records. Email, websites and remote access all depend on them. Change one record at a time, note the time-to-live value first, and keep the old records until the new ones have worked cleanly for at least 48 hours.
• Mailboxes. Move mail in batches and keep the old mailbox live until the new one is confirmed. Check shared mailboxes and distribution lists separately, as they are the most commonly missed.
• File permissions. Copying files is easy. Copying permissions is not. Map who needs access to what before the move, then verify afterwards. A folder that opens for everyone is a data protection problem.

Keep the old service live until sign-off

Do not cancel anything until the new service has run cleanly for an agreed period, usually 30 days. Overlap costs money, but a failed hard cut-over costs more. Agree the sign-off criteria in writing before the move starts. The most common failure is cancelling the old supplier too early because a notice period was misread.

Before day one, tell staff how to raise a ticket, who answers it, the hours it covers and what to do out of hours. If the old helpdesk stays live during the overlap, say which one to use for what.

Monitoring performance and avoiding lock-in after the switch

Consolidation is not finished when the new contract starts. The next job is to check the promised results arrive, and to keep your ability to leave if they do not.

Measure against the agreement, not how things feel

A sense that things are fine is not evidence. Track a short list of numbers against the agreement you signed:

• Response time: from ticket raised to first human response, against the agreed target.
• Restore time: time to fix, split by priority. Averages hide problems, so ask for the percentage of tickets fixed within target.
• Uptime: downtime across phones, internet and core systems, with the cause noted. One outage a quarter is a different picture from one a week.

The provider should send this every month on one page, in plain English: what they checked, what they found, what they fixed. They should also lead a review each quarter with data and an agenda. For each missed target, ask why it was missed and what changes. Keep the minutes. A pattern of misses with no change is your cue to use the exit clause.

Avoid lock-in from day one

Lock-in happens when moving away becomes too costly or difficult. It is rarely one big trap. It is a series of small dependencies that add up. To prevent it:

• Keep control of the essentials. You should own your data, documentation, licences and admin credentials, and the contract should say so. If the provider holds the only copy, they hold the relationship.
• Insist on standard formats. Your data should be exportable, and you should test an export once a year rather than find the problem on exit.
• Write the exit terms before you sign. Notice period, data return, hand-over help and any exit fees should be explicit. 30 days' notice is reasonable. Long notice periods and multi-year terms with no review point favour the provider.
• Avoid niche single-supplier systems. If one supplier runs something nobody else can support, that is a lock-in risk whatever the contract says.

The most common lock-in is knowledge, not paperwork. If only the provider knows how your environment is built, leaving is expensive. Keep your own record of the network, accounts and dependencies, and update it when things change.

Look after your own team

If you have in-house IT staff, consolidation can feel like a loss of control. Involve them in the plan, and agree early who owns what, who approves changes and where the boundary sits between your team and the provider. Write it down. Teams that feel sidelined often work around the new arrangement, which shows up later as shadow systems and undocumented fixes.