Leaving an IT provider is one of the few business decisions where the asset most likely to go missing is the one nobody ever put a price on. Laptops get counted. Licences get invoiced. Data sits quietly in a dozen places at once, and a meaningful share of those places are controlled by the company you have just told you are leaving.
That is rarely malice. Most support relationships end politely enough. But an outgoing supplier has no commercial reason to spend three weeks unpicking eight years of accumulated configuration for a client who has stopped paying, and a great many contracts never obliged them to. The result is a handover that delivers a folder of documents, a password spreadsheet six months out of date, and a permanent hole where the backup history used to be.
This guide sets out what actually happens when leaving an IT provider: where your data physically lives, who owns which parts of it under UK law, what a realistic thirty-day handover looks like, which systems are most often lost, how to demand exports you can open, and how to get proof that whatever the old supplier kept has been destroyed. It is written for businesses between ten and two hundred staff, because that is where the gap between what people assume and what the contract says is widest.
One framing point before the detail. Your supplier is almost never the owner of your business data; they are its custodian. Custody, however, is nine-tenths of practical control, and the entire exercise of leaving an IT provider is the work of converting a legal right you already hold into physical possession of files you can actually open. If you are still at the decision stage, our guide to switching IT support providers without disruption covers the commercial side of the same move.
Table of contents
- What actually happens to your data when leaving an IT provider
- Who legally owns what when leaving an IT provider
- The first thirty days after leaving an IT provider
- The data most at risk when leaving an IT provider
- Getting your data out in a format you can actually use
- Proving deletion: what the outgoing provider owes you
- Contract clauses that make leaving an IT provider painless
- What leaving an IT provider costs and how long it takes
- Nine mistakes that turn an exit into a data loss event
- Your step-by-step data exit plan when leaving an IT provider
- Frequently asked questions about leaving an IT provider
What actually happens to your data when leaving an IT provider
Nothing dramatic happens on the day you give notice. The damage of leaving an IT provider arrives slowly, through access being withdrawn in a sequence nobody planned, and it is usually discovered weeks later by someone who needed a file from 2021.
The four places your data actually lives
Business data in a supported environment sits in four distinct places: systems you own and control, systems the supplier owns on your behalf, systems a third party owns under the supplier’s account, and copies held for backup or archival purposes. Only the first survives an exit untouched. The other three all depend on a commercial relationship that is ending, which is precisely why leaving an IT provider needs an inventory before it needs a notice letter.
Data you own outright versus data you merely licence
Your documents, mailboxes, databases and customer records are yours. The tooling that manages them frequently is not. Remote monitoring agents, endpoint protection consoles, backup software, ticketing systems and network management platforms are typically licensed to the supplier, not to you. When the contract stops, the licence stops, and anything that existed only inside those tools stops being reachable with it. That single distinction accounts for most of the unpleasant surprises in leaving an IT provider.
The configuration data nobody thinks to ask for
Firewall rulesets, VPN profiles, VLAN maps, switch configurations, printer queues, DNS records, group policy objects, conditional access rules and the reasoning behind all of them are data too. They are also the single most commonly lost category, because they live in the outgoing engineer’s head and in a console you are about to be removed from. Ask for them in writing, as exports, before anything else is discussed.
Why the inventory has to come before the notice letter
The order matters more than almost anything else here. Once notice is served, goodwill becomes a finite resource and access reviews start happening. Build the inventory first, quietly, while you still have a co-operative supplier and a live contract. A business leaving an IT provider with a complete asset and system list is negotiating; one without it is asking for favours.
Who legally owns what when leaving an IT provider
Ownership is where most disputes begin, and it is also where most businesses discover their contract is thinner than they remembered. The legal position in the UK is reasonably clear; the contractual position usually is not, and leaving an IT provider tends to expose the difference within a fortnight.
Controller and processor: the distinction that decides everything
Under the Data Protection Act 2018 and UK GDPR, you are almost certainly the data controller and your supplier is a processor acting on your instructions. That distinction carries real force: a processor must return or delete personal data at the end of the contract, at your direction, and must be able to demonstrate it did so. It is the strongest lever you hold when leaving an IT provider who has become unresponsive.
What your contract usually says about data return
Most managed service agreements contain a termination clause and a confidentiality clause. Fewer contain an explicit data return clause with a format, a deadline and a named deliverable. If yours does not, you are relying on statutory rights and goodwill rather than a contractual obligation, which is slower and considerably less certain. Our breakdown of what belongs in a managed IT services contract covers the wording to insist on at renewal.
Who owns scripts, documentation and automations
This is genuinely contested ground, and it derails more exit conversations than any other topic. Bespoke work paid for under a project agreement usually belongs to you. Reusable scripts, monitoring templates and automation the supplier deploys across its whole client base usually belong to them, and no amount of arguing while leaving an IT provider will change that. What you can always demand is the output: the current configuration, the current rules, the current state, in a form you can rebuild from.
Where the law helps you and where it stops
Data protection law gives you strong rights over personal data and almost nothing over commercial artefacts. Your customer database is protected; the supplier’s documentation of how they built your network is not. That asymmetry surprises people. It is also the reason the practical work of leaving an IT provider concentrates on extraction and evidence rather than on legal threats.
The first thirty days after leaving an IT provider
Thirty days is the most common notice period in UK managed services and it is workable, but only if the first week is spent on the right things. Compressed timelines are where data gets left behind, and the calendar below is what leaving an IT provider looks like when nobody is improvising.
Days one to seven: notice, freeze and inventory
Serve notice in writing, request the data return obligations in the same letter, and freeze all non-essential change. Complete the system inventory if it is not already done, and ask for a named handover contact on the supplier side. Nothing technical should happen in the first week of leaving an IT provider. Everything technical that happens later depends on it.
Days seven to twenty-one: extraction and parallel running
This is the working fortnight. Export every system on the inventory, stand up replacement tooling alongside the old, and run both in parallel wherever the licensing allows. Parallel running is what turns a risky cutover into a boring one, and it is the part businesses cut first when they are trying to save money on leaving an IT provider. It is also the part that fails loudest when skipped.
Days twenty-one to thirty: cutover, deletion and final invoice
Move production, verify it, then deal with the paperwork: written confirmation of deletion, return of any hardware, closure of the supplier’s administrative accounts and settlement of the final invoice. Hold a modest final payment until the deletion evidence arrives, if your contract permits it. That single piece of leverage resolves more disputes than any other.
What good looks like at each checkpoint
At day seven you have a list. At day fourteen you have exports of everything on it. At day twenty-one you have restored at least one export successfully and proved it opens. At day thirty you have production running elsewhere and a signed statement of what was destroyed. Any checkpoint you cannot evidence is a checkpoint that has not happened.
The data most at risk when leaving an IT provider
Some categories reliably survive an exit and some reliably do not. The list below is ordered roughly by how often businesses leaving an IT provider discover the loss after it is too late to fix anything.
Backups and the retention chain
Backups are the number one casualty. If your backup platform is licensed to the supplier, your seven-year retention chain is licensed to the supplier too, and it evaporates the day billing stops. Restoring every historical point to somewhere you control is usually impractical, so decide deliberately which restore points genuinely matter and extract those. Anyone leaving an IT provider without addressing backups first is gambling with the oldest data they own.
Email archives, journaling and shared mailboxes
Mailbox contents inside your own Microsoft 365 or Google tenant are safe when leaving an IT provider. Anything held in a third-party archive, journaling appliance or email security gateway bought on the supplier’s account is not. Shared mailboxes and distribution groups that were configured but never documented also tend to disappear from view, because nobody remembers they exist until an enquiry stops arriving.
RMM agents, monitoring history and ticket records
Remote monitoring and management history is lost almost universally, and the ticket system with it. That matters more than it sounds: the ticket history is the written record of every recurring fault, every workaround and every piece of hardware that has been flaky for two years. Ask for a bulk export in CSV before the contract ends. Most platforms support it and most suppliers will agree if you ask early.
The password vault and the admin accounts inside it
A shared password vault is usually the supplier’s tenant, not yours. Export it to a format you control, then rotate every credential in it after cutover — not because the outgoing team is dishonest, but because credentials that have lived in someone else’s vault for years should not remain valid afterwards. This is basic cybersecurity hygiene and it is the step most often deferred and then forgotten.
Domains, DNS and certificates
Domain names are occasionally registered in the supplier’s name rather than yours, which is a problem that takes weeks to unwind and cannot be rushed. Check the registrant record now. Do the same for DNS hosting, SSL certificates and any mail authentication records, because a lapsed certificate or a stale DNS entry produces an outage that looks exactly like sabotage and usually is not.
Line-of-business databases and file shares
Databases hosted on infrastructure the supplier owns need a native export, not a file copy of the data directory. File shares need permissions exported alongside the files themselves, or you will spend a fortnight rebuilding access rights by complaint. Treat both as projects with their own owner rather than as tasks in a checklist.
Getting your data out in a format you can actually use
An export you cannot open is not an export. This is the stage of leaving an IT provider where a handover that looked complete on paper turns out to have delivered very little of value.
Native exports beat proprietary dumps every time
Insist on open or native formats: PST or MBOX for mail, CSV or SQL dumps for databases, standard image formats for backups, plain text or JSON for configuration. A proprietary archive that only the outgoing supplier’s software can read is functionally the same as no export at all, and it is the most common way for a technically compliant handover to leave a business worse off after leaving an IT provider than before.
The formats to insist on, system by system
Mail as PST or MBOX per mailbox. CRM and finance as CSV per table plus a full database backup. File shares as the files themselves plus an exported permissions report. Firewalls and switches as text configuration files. Documentation as PDF or Word rather than as a link to a wiki you will lose access to. Write this list into the exit correspondence rather than assuming it.
Test a restore before you sign anything off
Open the mail archive. Restore one database into a test instance. Import one configuration file. Verifying exports is a couple of hours of work and it is the only thing that distinguishes a handover that happened from a handover that was described. Businesses leaving an IT provider on a compressed timeline skip this step almost every time, and it is the one that cannot be redone later.
Chain of custody and secure transfer
Large exports get moved on portable drives, which is fine provided they are encrypted, logged, signed for and wiped afterwards. Record who handed what to whom and when. The NCSC’s supply chain security guidance is a sensible reference for the controls to apply to a departing supplier, and it also helps to have followed something published if the transfer is ever questioned.
Proving deletion: what the outgoing provider owes you
Getting your data out is only half the job of leaving an IT provider. The other half is establishing that the copies left behind no longer exist, which is a legal obligation rather than a courtesy.
What a certificate of destruction should actually say
A useful certificate names the systems, states what was deleted from each, gives the date, confirms that backups and replicas are included, and is signed by someone with the authority to say so. A one-line email saying “all client data has been removed” is not evidence of anything, and it will not satisfy an auditor, an insurer or the Information Commissioner’s Office if somebody asks how leaving an IT provider was handled.
Why deletion is a process, not an event
Backups make immediate deletion impossible in practice. A supplier with a ninety-day retention cycle cannot destroy your data today; they can stop using it today and confirm it ages out on a stated date. That is an acceptable answer and you should ask for it in that form: what is deleted now, what expires when, and who confirms it afterwards. Anyone leaving an IT provider should get that timetable in writing.
Sub-processors and the long tail of copies
Your supplier’s own suppliers hold copies too — the backup vendor, the email filtering service, the documentation platform, the monitoring cloud. Ask for the sub-processor list and confirmation that deletion has been instructed downstream. This is exactly the obligation UK GDPR places on a processor, and most reputable firms maintain the list already because their own data protection commitments require it.
What to do when a provider will not co-operate
Escalate in writing, cite the processor obligations, set a deadline and copy in a director. If that fails, a formal complaint to the ICO is available and free, and the possibility of one resolves most stand-offs on its own. Withholding a final payment is a legitimate commercial lever where the contract allows it; deleting your own copies before the dispute concludes is not.
Contract clauses that make leaving an IT provider painless
Everything above is far easier when it was agreed at signature rather than negotiated at termination. These are the four clauses that make leaving an IT provider a scheduled task instead of a negotiation, and they are worth insisting on next time.
The exit and data return clause
Name the deliverables, the formats, the deadline and the responsible party. “Reasonable assistance” is not a clause; it is an invitation to argue. A good clause says the supplier will provide exports in specified formats within a specified number of working days at a specified rate, whether the relationship ended well or badly.
Notice periods and the duty to co-operate
A thirty-day notice period with no co-operation obligation is worse than a ninety-day one with a strong obligation. Read them together rather than separately. The right combination gives you time to extract and an enforceable duty on the supplier to help you do it, which is what makes leaving an IT provider a project rather than a fight.
Credential and asset ownership
State plainly that domains, tenants, subscriptions and licences are registered to your business, that administrative credentials are held jointly, and that the supplier maintains a current password export you can request at any time. This clause costs nothing at signature and is worth several weeks of work at exit.
What a fair exit fee looks like
Charging for handover effort is legitimate; charging for the release of your own data is not. A fair arrangement bills genuine engineering time at the normal rate against an estimate agreed in advance. Anything framed as a fee to unlock, release or hand back data should be challenged directly, and usually is not defensible once it is put in writing.
What leaving an IT provider costs and how long it takes
Budgeting for the exit is what turns it into a managed project. Businesses that budget nothing for leaving an IT provider spend more overall, because they end up buying the same work in a hurry.
Typical UK costs for a small business exit
For a firm of forty staff, expect somewhere between £2,000 and £6,000 of combined effort across both suppliers, plus one to two months of overlapping subscriptions. Complex estates with on-premise servers, bespoke applications or regulated retention obligations run higher. The honest planning number for leaving an IT provider is one month of your current support fee, held aside specifically for the transition.
How long a proper handover really takes
Six to ten weeks end to end for a typical SME, of which thirty days is the contractual notice and the rest is preparation before and verification after. Attempting it inside a fortnight is possible and reliably expensive. If you are also changing platforms at the same time, treat those as two projects and sequence them rather than running both at once.
Why paying for overlap is the cheapest insurance available
Two months of double-running costs less than one lost database, and far less than a week of downtime during a busy period. Overlap buys you the ability to fail safely: if an export turns out to be incomplete, the original system is still there. Everyone leaving an IT provider without overlap is betting that every export worked first time, and exports frequently do not.
Nine mistakes that turn an exit into a data loss event
These recur in almost every difficult handover, and every one of them is avoidable with a fortnight of forethought before leaving an IT provider becomes public knowledge inside the business.
Cancelling the contract before planning the exit
The most expensive mistake available. Notice served before the inventory exists means every subsequent conversation happens under time pressure with a supplier who is no longer being paid to help. Plan first, serve notice second — the order is not negotiable.
Assuming the backups belong to you
They usually do not, and finding out in week three is a genuinely bad afternoon. Check the licensing on the backup platform before anything else, because it determines whether your historical restore points are an asset you own or a service you rent.
Leaving the whole job to the incoming provider
Your new supplier can do most of the technical work but cannot enforce your contract, cannot compel deletion evidence and does not know what existed before they arrived. Someone inside your business has to own the exit. Where there is no internal capacity for that, buy it explicitly as part of the vendor management scope rather than assuming it is included.
Accepting a password spreadsheet as a handover
A spreadsheet is a starting point, not a deliverable. Every credential in it needs testing and then rotating, and any account it does not mention needs finding. Pair it against the system inventory and treat the gaps as the real work of leaving an IT provider.
Forgetting the systems bought on a director’s card
Every business has three or four subscriptions that never went through IT and never appeared on any list. They surface at the worst moment. A quick review of card statements and recurring payments before you serve notice will find nearly all of them.
Your step-by-step data exit plan when leaving an IT provider
If you take nothing else from this guide, take the sequence. The order below is what separates an uneventful transition from a bad quarter, and each step assumes the one before it is complete.
Steps one to three: inventory, contract, owner
Build a full inventory of systems, data locations and credentials. Read the contract and extract the termination, data return and co-operation clauses into a single page. Name one internal owner with authority to make decisions. Do all three before anyone outside the business knows you are leaving an IT provider.
Steps four to six: credentials, exports, verification
Take control of domains, tenants and administrative accounts. Export every system on the inventory in an agreed format. Verify a meaningful sample by actually restoring or opening it. Sound IT asset management practice makes these three steps routine rather than archaeological, which is a good argument for maintaining the register continuously.
Steps seven to ten: cutover, deletion, evidence, review
Cut over with overlap in place. Instruct deletion in writing and obtain the certificate. File the evidence with your compliance records. Then review what the exit revealed about your own documentation, because the gaps you just spent six weeks filling will reopen quietly unless somebody owns them. A structured managed IT services arrangement should keep that register current as a matter of routine.
Frequently asked questions about leaving an IT provider
The questions below come up in nearly every transition conversation, and the answers are more reassuring than most people expect when they first start thinking about leaving an IT provider.
Can an IT provider hold my data hostage?
Not lawfully, where personal data is concerned, and this is the fear that stops most businesses leaving an IT provider they have already outgrown. A processor must return or delete personal data on the controller’s instruction, and refusing is a matter the ICO will take seriously. A supplier can legitimately withhold discretionary effort over an unpaid invoice, and can charge for handover time, but withholding the data itself is a different thing entirely.
Who owns our Microsoft 365 tenant?
You should, and it is worth checking today rather than at notice. If the tenant was created under the supplier’s partner account, you can normally have billing and administrative control transferred to you without moving any data. If it was created as a sub-account of something they own, unpicking it is harder, and that is a strong argument for doing it before leaving an IT provider becomes a live question.
How long can the old provider keep our data?
Only as long as they have a lawful reason, which after termination is usually a short retention window for backups plus whatever a legal or regulatory obligation requires. Agree the period explicitly and get the expiry date in writing. Indefinite retention “just in case” is not a lawful basis and should be challenged.
Do we need the outgoing provider’s help at all?
Technically, sometimes not; practically, almost always. Even a co-operative handover of two hours saves days of guesswork about why a firewall rule exists. Budget for their time, ask specific questions rather than open ones, and keep the tone civil — you will get considerably more from a supplier treated as a professional than from one treated as an adversary.
What if the provider has gone out of business?
Move quickly, because administrators do not prioritise client data and hosting bills stop being paid. Contact the administrator in writing immediately, assert your position as data controller, and pull whatever you can reach while credentials still work. Our IT provider offboarding checklist works as an emergency running order in that situation as well as a planned one.
Where should we start this week?
With the inventory, always. Everything in this guide depends on knowing what exists, and the inventory is the only step you can complete without telling anyone anything. Build it, read your contract against it, and the rest of leaving an IT provider becomes a sequence of ordinary tasks rather than a crisis with a deadline.
