Switching Your IT Service Provider: An Orderly Handover Instead of Starting Over Blind

How to tell it is time for a change

The clearest warning sign is availability. If fault reports go unanswered for days, callbacks never come, and you do not know who is currently responsible for you, the basis for the working relationship is missing. This does not mean that every small matter must be resolved immediately. It means reliability: a committed response time, a transparent ticket system, meaning software in which every request is recorded and its processing status is visible, and an honest answer as to when something will be done.

The second signal is missing documentation. If no one apart from a single technician knows how your network is structured, which servers perform which tasks, and where which passwords are stored, you are carrying a risk that grows with every year. Feel free to ask directly: Is there an up-to-date network plan, meaning an overview of all devices and connections? Is there system documentation that an outside specialist would understand? A reputable service provider can present both.

The third signal is dependency. It becomes critical when access credentials are held exclusively by the service provider, when licenses and domains run under the provider’s name, or when the provider refuses to give you information about your own systems. You can recognize a healthy business relationship by the fact that you would have full access to your own environment at any time, even if you do not use it in day-to-day operations.

Honesty also requires a look at your own role. Some working relationships fail not because of the service provider but because the company has grown and the small firm from back then can no longer cover today’s requirements. That is not a failure but a normal development. And sometimes the problem lies in unclear expectations or a budget that never matched the desired scope of services. An open conversation often resolves this faster than a change of provider.

These access credentials and documents belong to you

The most important principle first: your IT environment belongs to you, either as your property or through contracts that run in your company’s name rather than your service provider’s. The provider manages it on your behalf. What you are entitled to in detail depends on the contract, but in practice a clear line applies to most points.

Access credentials: All administrator accounts, meaning accounts with far-reaching rights on servers, in the firewall, in the email system, and in cloud services, concern your systems. You should know which of these accounts exist and keep a sealed or encrypted copy of the credentials on your own premises. The same applies to central passwords such as those for domain administration or the router.

Licenses and domains: Software licenses you have paid for should be registered to your company. Be careful with rental licenses that the provider supplies from its own allotment: these lapse when you switch and must be procured anew. Your domain, meaning your internet address including the associated email addresses, must be registered with your company as the owner. With the company through which the domain is registered, known as the registrar, the service provider may be listed as the technical contact, but not as the owner.

Documentation and backups: Whether system documentation is owed to you is set out in the contract; many support contracts provide for it. Regardless of that, your backups contain your data, no matter where they are technically stored. Clarify how they will be handed over to you in the event of a switch, in what format, and when copies held by the provider will be deleted.

Contracts and deadlines: what to check before giving notice

Before you give notice, read the existing contract in full. Three points are decisive: the minimum term, the notice period, and clauses on automatic renewal. If you miss the cut-off date, some contracts renew for another year. Note the latest possible termination date and plan backwards from there.

Also check what the contract says about termination: Is there a provision on the handover of documentation, access credentials, and data? Is support during the handover agreed, and is it remunerated separately? If such provisions are missing, that is no disaster, but you should then coordinate the handover with the provider early and in writing. A fair provider will cooperate even without an explicit clause but may charge a fee for the additional effort.

Think of contracts that run through the provider: internet access, web hosting, telephony, hardware maintenance contracts, rental licenses. Each of these contracts has its own deadlines. And if the provider processes personal data on your behalf, there is usually an Auftragsverarbeitungsvertrag (a data processing agreement under German data protection law), which also governs what happens to your data at the end of the contract: return or deletion. Request confirmation of the deletion at the end.

How an orderly handover works

The order of steps matters more than speed. Find the new service provider first and have them take stock of your environment before you give notice to the old one. That way you know what needs to be taken over, and the new provider can assess where gaps exist in documentation or access. Giving notice without a plan creates time pressure, and time pressure is the most common cause of mishaps during handovers.

Plan for a transition phase in which both sides have named contacts and are reachable. The usual arrangement is a cut-off date from which the new provider bears responsibility, followed by a run-off period of a few weeks during which the old provider remains available for questions. Realistically, an orderly switch takes several weeks to a few months from decision to completion, depending on the size of the environment.

Immediately after the handover, all passwords known to the previous provider are changed, and its accounts and remote maintenance access, meaning software it could use to access your systems from the outside, are deactivated. This is not a vote of no confidence but normal hygiene, and it protects both sides: the old provider can no longer be held responsible for new events in your environment. For its earlier work, it may remain liable under the contractual and statutory rules.

Keep the tone businesslike. The previous provider has often looked after your systems for years and knows details that are not written in any documentation. A handover conducted as a reckoning costs you exactly this knowledge. Those who terminate fairly, pay properly, and communicate clearly almost always get a cooperative handover.

Checklist for the handover meeting

Go into the meeting with a written list and tick off every point. First, access: a complete list of all administrator accounts stating what they apply to, plus the handover of the passwords by a secure route, for example via a password manager or in sealed form, not by plain email. Second, licenses: a list of all software licenses with information on who they are registered to and which ones lapse with the switch.

Third, domains and certificates: Who is registered as the owner of the domain, where is it technically managed, and how do you obtain the transfer code with which a domain can move to another provider? Also ask which security certificates are in use for the website and services and when they expire. Fourth, hardware: Which devices belong to you, which are rented or leased, and which will the provider take back?

Fifth, backups: Where are the backups stored, how far back do they go, and how will they be handed over? Sixth, documentation: network plan, device list, configurations, special setups, and known legacy issues. Seventh, open items: unresolved tickets, planned maintenance, ongoing projects. And eighth, a fixed date on which the old provider’s access will be finally deactivated. Have the results of the meeting confirmed in writing.

What you can do yourself and where help makes sense

You can prepare much of this without technical expertise: gather the contracts and invoices of recent years, note the deadlines, draw up a list of all programs and services in use, and clarify internally who will be the point of contact for IT going forward. Whether the domain and licenses are registered to your company can also be clarified with a few enquiries.

Technical support makes sense for taking stock of the systems, for assessing the documentation that is handed over, and for everything related to moving data: email mailboxes, servers, cloud environments. This is where most mistakes happen when experience is lacking. It makes sense for the new provider to take this on, because they have to work with the result.

One final piece of advice: use the switch to resolve the dependency question for good. Agree with the new provider from the outset that the documentation will be maintained on an ongoing basis, that access and licenses are registered to your company, and that you always have a copy of the most important access credentials in house. Then the next switch, should it ever become necessary, is an administrative task rather than a major undertaking.