How to change your IT provider without downtime

That fear is usually misnamed. A company is not afraid of the new provider — it has checked them, talked to them, seen the scope and the references. It is afraid of the gap: the stretch where the outgoing provider has stopped treating you as a client and the incoming one does not yet know that invoices are issued by a program sitting on one machine in the accounts office.

The gap is real, but it has a specific cause and a measurable length. Knowledge of an environment is not written into the contract — it lives in the ticket history, in habits and in somebody's memory, and the end of a contract transfers none of it. The gap lasts exactly as long as the new provider has no access of their own and no description of the environment. Both can be in place before the old contract runs out.

Which is why the switching date is the last step in a change, not the first. An accounting firm that gives notice in January and moves its support in March takes incomparably less risk than one that does both on the same Friday — not because March is a better month, but because in between somebody had time to write down what there is to take over.

Not every frustration is a reason to change. A provider who answers slowly in a week with three outages running at once can still be a good provider, and an arrangement whose scope nobody has reviewed for two years can be a bad arrangement with a good provider. Before you start looking for a successor, it is worth settling whether the problem is the contractor or a scope nobody is paying for — a conversation about widening the contract sometimes fixes more than changing the name on the invoice, and costs a great deal less.

Some signals, though, survive that conversation, because they come not from anyone's bad will but from the way the arrangement is built. They are worth reading as observations rather than accusations — that way each of them can simply be checked.

Taking over IT support is not a transfer of goodwill; it is a transfer of administrative control. If the domain, the Microsoft 365 tenant and the licence agreements are registered to your company, changing provider is a decision you make on your own. If they are registered to the provider, you are not changing provider — you are asking permission.

So the first thing to check is not the competing quote but your own position. The list below needs no tooling — you go through it point by point and write the answers down. It is usually where the first thing nobody knew about turns up.

Before any date is set, read the contract you are under in full, annexes included. Four things matter: how long the notice period is and when it starts to run, the form the notice has to take, whether the agreement renews itself, and what it says about returning access and documentation. If it says nothing about the last of those, that does not mean the access is not yours; it means nobody thought about it.

A notice period tends to be treated as a penalty when it is really a schedule. Three months is comfortable room for an audit, for putting ownership in order, for gathering documentation and for agreeing a switching date calmly. One month is tight but still enough to avoid improvising. The trouble appears only when the notice goes out first and the thinking starts second — the clock then runs whether or not anyone knows where the passwords are.

While notice runs, almost everything can be done: a review of the environment, an inventory, a domain transfer, setting up your own password vault, documenting the network and the licences, agreeing the order of work. What cannot — and should not — be done is switching off the outgoing provider's monitoring or backups before the new ones are running, or stripping their administrative access while they are still formally responsible for the environment. Responsibility without access is worse than having neither.

A handover starts with an audit and an inventory, before notice is given. You cannot plan a change in an environment nobody has listed, and the review answers the ownership question along the way: what is yours and what has to be recovered first. At this stage nobody needs your administrator passwords — read-only permissions and the presence of the person who knows where those passwords are kept will do.

The second step is access and documentation. The new provider should get their own named administrator accounts rather than inherit a shared password: it is then visible who did what, and cutting off the old access requires changing nothing else. In parallel, a description of the environment takes shape — a list of devices, accounts and licences, a network diagram, contacts at the ISP and the software vendors, where the backups live. That document stays with you, and it, rather than somebody's good memory, is what protects you the next time you do this.

The third step is a period of overlap. The new provider already has monitoring and backup oversight running, is watching the environment and learning its rhythm, while requests still go down the old channel because the old contract is still in force. That week or two is the cheapest insurance in the whole process — it is exactly when the things that appear in no documentation surface, and they surface with two providers present instead of none.

Only then comes the cut-over: the ticket channel changes, contact with the ISP and the software vendors moves across, and the outgoing provider's access is revoked. For most staff it is above all a new phone number and a new email address for requests; where the remote-access tooling or the endpoint protection has to be swapped, they are told about it in advance. What follows is a settling period, usually the first month, in which the dependencies nobody knew about come to light: the spreadsheet that pulls from one particular network share, the printer with a hand-typed IP address, the industry application that runs on exactly one workstation. If you are in or around Bydgoszcz, this part can be done on site, at the cabinet and the hardware — within the visit scope set in your agreement; things like that are found faster there than remotely.

This is the sentence that most often unblocks the decision: a competent handover does not require the outgoing provider's consent or their help. Only convenience requires that. Everything needed sits either in your own systems — the domain panel, the tenant, the invoices, the contracts — or can be reconstructed from scratch: a network can be mapped, devices can be listed, a configuration can be written down again. Their cooperation shortens the process; it does not determine whether it is possible.

It is worth saying plainly, because many companies stay with a provider they no longer want to work with purely out of a worry that “they will never hand it over”. The one thing that genuinely cannot be reconstructed on your own is ownership registered in somebody else's name — and that, not the atmosphere of the parting, is the real risk in the whole business.

What does genuinely break is a change carried out in a week. A domain whose renewal nobody is watching any more expires on its own date, weeks or months after the switch, and takes the whole company's email with it. A subscription paid on a card nobody has access to stops renewing, and an unpaid subscription starts a clock that ends with the licences switching off; how much of that clock is left is something the admin console shows and an article cannot. A backup job that ran inside a console decommissioned along with the old contract simply stops running — and a backup nobody reports on is not a backup, it is a hope.

We start with a short, free conversation about what is not working today, and then with an IT audit — run before you give notice. We look at the backups and whether anyone has ever tried to restore from them, the Microsoft 365 configuration, accounts, permissions and MFA, the network and firewall, endpoint security, licences, and whether any current documentation exists at all. The findings come in writing, ranked by their impact on the business, and you can show them to anyone you like — including your current provider.

If the review shows that your current provider does their job well and the real problem is a contract whose scope is too narrow, we will say so. A handover with no case behind it is a cost to both sides, and we would rather lose one contract than run it for a year knowing it should never have started.

Once the decision is made we propose a scope, a plan and an SLA with severity levels and response times written into it: on current standard terms, a standard request within three working days and an urgent one within twelve hours, while the IT Business and IT Critical plans get shorter, individually agreed windows written into the agreement. Then we take over access, move administrative passwords into a vault, switch on monitoring and backup oversight to the extent agreed in the contract, and write the environment down: devices, licences, network, access, vendors.

We write the same rules into our own agreement. The documentation, the inventory and the administrative passwords are yours, the tenant and the domain are registered to your company, and the notice period is set so that leaving is not a penalty. A company that can leave at any moment stays because it wants to — and that is the only version of this arrangement that survives a few years.