Backup Vendor Lock-In: A UK Business Guide to Choosing a Cloud Backup Provider You Can Actually Leave in 2026

Backup vendor lock-in is the cost nobody asks about at signature and everybody discovers at renewal. Choosing a backup provider is quick: a trial, a quote, a migration of the first jobs, and protection is running within a fortnight. Leaving one is a different exercise entirely. The backups you hold are stored in a format only that vendor’s software can read, in storage that may belong to the vendor rather than to you, with years of retention you are legally obliged to keep, under a contract that renewed itself while nobody was looking. The switch you could have made in a fortnight on the way in can take months and a substantial bill on the way out.

This guide is about choosing a provider you can actually leave, and about leaving one well if you need to. It covers what makes a backup genuinely portable, why proprietary repository formats are normal and what to do about them, who owns the storage and the encryption keys and why that matters more than the software, the retention tail — the years of historical backups that do not migrate — the egress, rehydration and early deletion charges that arrive at exit, the contract terms that quietly extend lock-in, and a due diligence checklist to run before signing. The backup fundamentals sit in our guides to backup retention policy and cloud backup pricing; this guide is about the exit those decisions create.

What makes a backup genuinely portable

Portability is not a single property. A backup is portable to the extent that four separate things are true, and most products satisfy some of them and not others.

You can read the data without the vendor’s software. Most mature backup products store data in a repository optimised for deduplication, compression and incremental chaining — efficient, and readable only by that product. That is not a sign of bad faith; it is how efficient backup works. It does mean that leaving the vendor leaves you with a large store of data you cannot open, unless the vendor provides a way to restore it after your licence ends or you restore it into something else before you go.

You own the storage it sits in. Some services store your backups in the vendor’s own cloud; others write to storage in your own cloud account. Where the storage is yours, leaving the software does not mean losing access to the bytes, and you control retention, deletion and the bill. Where the storage is the vendor’s, access to your data after the contract ends depends on the vendor’s terms and timescales.

You control the encryption keys. Encrypted backups are only as accessible as their keys. If the vendor holds them and the relationship ends, your access depends on the vendor. Customer-managed keys keep that dependency on your side.

You can extract to a standard format. The ability to export to formats other systems can read — virtual disk images, native database backups, standard mailbox formats, ordinary files — turns a proprietary repository into something portable at the point of exit. Some products do this well, some offer it only for current restore points, and some do not offer it at all.

The useful way to assess a provider is to ask what happens to each of these four on the day the contract ends. A provider that writes to your storage, with your keys, and offers a perpetual restore capability or a standard-format export is genuinely portable even if its repository format is proprietary. A provider that holds your data in its own cloud with its own keys and deletes everything thirty days after termination is not, however good the product is while you are using it.

Backup portability in UK businesses — the numbers

The figures below reflect what we find reviewing backup arrangements for UK organisations of 20 to 400 staff, usually at the point of a renewal, a provider change or a merger.

The first figure is the one that should frame every backup procurement. Fewer than a quarter of organisations could restore an old backup if their relationship with their vendor ended tomorrow. The rest are in a position where historical restore points — including the ones they keep to satisfy statutory retention — are accessible only for as long as they keep paying.

The second figure explains why that matters so much. Switching provider protects new data from the switch date onwards. It does nothing for the years of history already held, which in a proprietary repository usually cannot be converted into the new provider’s format. That history must either be kept accessible in the old system, restored and re-protected selectively, or exported before access ends. Each option costs something, and most organisations discover this only at the point of switching.

The third figure is the one with a deadline attached. Vendor-hosted services commonly delete customer data a short period after termination. If the retention tail lives in vendor storage and nobody has planned its extraction, thirty days is not long to move several terabytes — particularly when retrieval from cold tiers takes hours per request.

The lock-in vectors

The grid below groups the factors that make leaving a backup provider hard. Badges reflect how much each increases the cost or risk of exit, independently of how good the product is while in use.

The middle card’s third row deserves explanation because it is an unintended consequence of good practice. Immutable backups in compliance mode cannot be deleted by anyone, including you, until their lock period expires. That is precisely what makes them valuable against ransomware. It also means that if you leave a provider whose storage holds compliance-locked backups, you may continue paying for that storage until the lock expires, and you cannot shorten it. Immutability is worth having; its interaction with exit is worth understanding before you set the lock period, which we discuss in our guide to backup retention policy.

The final row of the contract card is common among UK SMEs and easy to overlook. When backup is one component of a managed IT service, it frequently runs on the provider’s own platform and licences, and the backup data may belong to that provider’s tenancy rather than yours. Changing IT provider then means changing backup provider too, and the history held on the outgoing provider’s platform becomes part of the exit negotiation.

What actually blocks a switch

The chart below shows the obstacles that delayed or prevented a planned backup provider change, across UK organisations we have supported through one. Most switches encounter more than one.

The top row is almost universal, and it changes how switching should be understood. Moving to a new backup provider is a forward-looking change: new backups go to the new system from the switch date. The history stays where it is. For almost every organisation, that history includes restore points kept for compliance — financial records, contracts, email — that must remain recoverable for years. Switching is therefore not a cutover but a period of running two systems, with the old one in a reduced, read-only role until its retention expires or its data has been extracted.

The second row is a planning failure rather than a technical one. Backup contracts commonly auto-renew with notice periods of sixty or ninety days, and organisations that decide to switch after the notice window has passed are committed to another term. Knowing the date, as with any IT contract, is the cheapest protection available — a point we make about connectivity contracts in our guide to choosing a business ISP.

The third and fourth rows together are what make the retention tail expensive. If old backups can only be read by a licensed copy of the outgoing software, and the data sits in cold storage that charges to retrieve, then keeping history accessible means paying for both a licence and storage for years, while extracting it means paying retrieval and egress on terabytes. Neither is necessarily unaffordable; both should be priced before signing rather than discovered at exit.

What leaving actually costs

The table below sets out indicative exit cost components for a UK organisation holding around 20 TB of backup history in cloud storage, excluding VAT. Figures vary widely by provider, storage tier, contract and how much history must remain accessible, so treat them as a basis for asking questions rather than as a quotation. Transfer pricing in particular is covered in our guide to cloud network egress costs.

The two annual rows are the ones that surprise people, because they recur. An organisation with a six-year retention requirement that switches provider may carry a read-only licence and storage for the old system for up to six years while history ages out. The cost falls as restore points expire, but the obligation is long, and the total can exceed what a straightforward extraction would have cost.

That trade-off is the central decision at exit: keep history in place and pay for access over time, or extract it now and pay retrieval and egress once. The right answer depends on how much history is genuinely needed, in what form, and for how long. Many organisations find a middle path — extract the restore points needed for statutory retention into a standard-format archive, and let the rest expire with the old system.

The egress row is worth reading carefully. Hyperscale cloud providers now commonly waive egress for customers leaving the platform entirely, under conditions. That does not necessarily apply when you are leaving a backup vendor whose own service runs on a hyperscaler, or when the data sits in the vendor’s account rather than yours. Establish whose account holds the storage and whose terms govern its exit.

An exit plan that does not lose history

The sequence below takes an organisation from a decision to switch to a completed exit, with history preserved. Its duration is set mainly by the retention tail rather than by migrating new backups.

The step most often skipped is verifying extracted history by restoring from it. An export that completed successfully is not the same as an export that can be restored, and the first time anyone tests an archive of six-year-old backups should not be the day a tribunal asks for them. Restore a sample from each exported set before the old system’s access ends.

The final step matters for data protection as well as tidiness. A backup provider holding your data is acting as a processor, and the contract between you should provide for deletion or return of personal data at the end of the service. Obtaining written confirmation of deletion is how you evidence that the relationship ended cleanly.

Vendor-held against customer-owned backup arrangements

The comparison below highlights customer-owned storage and keys. The qualification matters: fully vendor-hosted backup services are often the right choice for smaller organisations, because they remove the work of running storage and are frequently simpler and cheaper day to day. The highlight reflects which arrangement is easier to leave, not which is better to use — and the gap can be narrowed considerably through contract terms if vendor hosting is preferred.

The last row captures the difference. In a vendor-held arrangement, protection against lock-in comes from what the contract says: post-termination access, data return, export formats and costs. In a customer-owned arrangement, the protection comes from the architecture itself — the software can change while the storage, the keys and the history remain under your control. Neither removes the need to restore old data with something that can read it, but customer ownership turns that from a deadline into an option.

Note what customer ownership does not solve. If the repository format is proprietary, you still need a licensed copy of the software, or the vendor’s restore-only tooling, to read old restore points. Customer-owned storage means you will not lose the data; it does not by itself mean you can read it. That is why the format and post-licence restore questions in the checklist below matter in both arrangements.

Proprietary repositories and standard formats

Most backup products worth using store data in proprietary repositories. Understanding why, and what the escape routes are, prevents both unwarranted alarm and unwarranted complacency.

Why proprietary formats exist

Efficient backup relies on deduplication — storing each unique block once — on compression, on incremental chains where each restore point depends on earlier ones, and on encryption. Together those reduce storage dramatically and make frequent backups affordable. They also produce a store that only the software that wrote it can reassemble into usable files or systems. That is a technical consequence of efficiency, and avoiding it entirely usually means paying for considerably more storage.

The escape routes

The practical questions are therefore about getting out rather than avoiding the format. Does the vendor provide restore capability after licence expiry — a free or low-cost restore-only tool, or a read-only licence? Can the product export restore points to standard formats such as virtual disk images, native database backup files, standard mailbox formats or plain file trees? Can it export historical restore points, or only the most recent? And is the repository format documented to any degree, so that it is not dependent on a single product version?

Where standard formats are natural

Some data protects well in standard formats with little efficiency penalty. Database-native backups, mailbox exports, and file-level copies to object storage are all readable without the original backup product. For data held primarily for long-term statutory retention rather than rapid recovery, writing an archive copy in a standard format — even alongside an efficient proprietary backup — is a sensible hedge. It costs some storage and makes the long tail independent of any vendor relationship.

SaaS backups have their own version of this

Third-party backup of Microsoft 365, Google Workspace or other SaaS platforms is typically delivered as a service, with data in the vendor’s storage. Exit therefore depends on export: can you get mailboxes out as standard mailbox files, sites and OneDrive as files with permissions documented, Teams content in a usable form? Ask before signing, because SaaS backup history is frequently what a subject access request or a dispute needs — and it is distinct from the preservation that Microsoft 365’s own retention provides, which we cover in our guide to Microsoft 365 email archiving and eDiscovery.

Contract terms that quietly extend lock-in

The technical arrangement determines how hard exit is; the contract determines how much time and money you have to do it. These are the terms worth reading before signature.

Post-termination access and deletion. How long after termination can you still restore or export, and what happens then? A thirty-day window may be enough for a small dataset in hot storage and nowhere near enough for terabytes in an archive tier. Negotiate a window that reflects your data volume and retrieval times, or a paid extension option.

Data return obligations. Does the vendor commit to returning your data in a usable form on request, in what formats, within what timescale, at what cost? Where the vendor processes personal data on your behalf, data protection law expects the contract to address deletion or return at the end of the service, which gives you a legitimate basis to insist on clear terms.

Export charges. Are bulk export, retrieval and egress charged, and at what rates? Undisclosed rates at exit are a negotiating position for the vendor at the moment you have least leverage.

Renewal and notice. Auto-renewal with a long notice period, combined with nobody recording the date, is the commonest reason a planned switch slips by a year. Record the date and set a reminder well before the notice window.

Committed capacity and term length. Multi-year commitments to a storage volume may be good value, and they also mean paying for the remainder if you leave early. Weigh the discount against the flexibility you are giving up.

Termination assistance. Some contracts commit the vendor to reasonable assistance during an exit, at stated rates. Where backup is critical, that commitment is worth asking for.

Bundled services. Where backup comes as part of a managed IT service, check whether the backup data and licences belong to you or to the provider, and what happens to both if you change provider. This single clause frequently determines whether changing IT provider is straightforward or a negotiation over your own history.

Exit readiness — where most UK organisations sit

Combining the assessment areas gives an indication of how easily an organisation could leave its current backup provider without losing access to history or paying heavily to retrieve it. The gauge reflects a first review of a UK organisation of 20 to 400 staff on a typical commercial backup service.

A score around thirty-one reflects backups that work well and an exit nobody has considered. Protection itself scores well. Format and storage ownership score poorly, because the default product choice holds data in vendor storage in a proprietary format. Contract awareness scores low, because post-termination terms were not read. And the retention tail scores lowest, because almost nobody has thought about how years of history would survive a change of provider.

The useful feature of this benchmark is that most of the improvement happens at signature rather than at exit. Asking the right questions before choosing a provider, negotiating the post-termination window, choosing customer-managed keys where available, and writing long-term archive copies in standard formats all cost little at procurement and are difficult or impossible to obtain later. For an organisation already under contract, the next renewal is the moment to fix them.

When the exit is not your choice

Most discussion of lock-in assumes the customer decides to leave. In practice, a good share of backup provider changes are forced by something that happens to the provider, and those are the exits with the least warning and the least leverage.

The provider is acquired

Backup is a consolidating market, and smaller providers and resellers are regularly acquired. An acquisition can bring a new platform, new pricing, migration to the acquirer’s infrastructure, or the retirement of the product you bought. Contracts sometimes address change of control; more often they do not, and the new owner’s standard terms apply at the next renewal. It is worth asking whether your contract allows you to terminate without penalty if the provider changes ownership or materially changes the service.

The product is discontinued

Vendors retire products and editions, often with a migration path to a successor that carries different pricing, different storage or different terms. If your history is in the retired product’s format, the questions are how long restore capability for old restore points will be supported, and whether migration into the successor carries history across or starts afresh. End-of-life notices typically give months rather than years, which is shorter than most retention periods.

The provider fails

The scenario nobody plans for and the one with the starkest consequences. If a backup provider holding your data in its own storage ceases trading, access to that storage depends on what happens to the business and its infrastructure contracts, on administrators’ decisions, and on whether the underlying cloud bills continue to be paid. This is a meaningful risk with small regional backup resellers in particular, and it is the strongest single argument for holding long-term retention in storage you own. Where backups sit in your own cloud account, a provider failure is an inconvenience to the software relationship; where they sit in the provider’s, it can be the loss of your history.

Contractual safety nets worth asking for

A few provisions reduce the impact of an involuntary exit. A restore-only licence or tool that remains usable after the subscription ends, whatever the reason it ends. A right to terminate without penalty on change of control or material change to the service. Defined notice periods for product discontinuation that bear some relation to your retention period. A commitment to return data in a usable form in the event of insolvency or exit from the market, recognising that the enforceability of such a commitment in an actual insolvency is limited. And, most robustly, an architecture in which the storage and keys are yours, so that none of these depend on a counterparty still being solvent.

None of these risks is a reason to avoid smaller or specialist providers, many of whom offer better service than large ones. They are reasons to ask the questions at signature and to keep the history that matters most where it does not depend on any one supplier’s continued existence. The same thinking applies to cloud platforms more generally, as discussed in our guide to planning an Azure exit strategy.

Benchmarks — portability practice against what we find

The figures below show how often each practice is in place across UK organisations of 20 to 400 staff, at first review.

Seventy-one per cent with tested, working backups against eleven per cent having estimated exit cost is the whole pattern in two numbers. Backup is treated as a protection question, which it is, and not as a supplier relationship with an end, which it also is. The two coexist without tension until the day the relationship needs to change.

The fourteen per cent who know their post-termination access window is the figure with the most direct operational consequence. If that window is thirty days and history sits in an archive tier that takes hours per retrieval, the time to discover the constraint is at signature, not in the month after giving notice.

The number that decides whether you can leave

If one figure predicts whether an organisation can change backup provider without losing access to its history, it is whether old backups can be restored without a current licence from the vendor that created them.

Twenty-three per cent means that for roughly three organisations in four, the years of history they keep for compliance, disputes and recovery are accessible only for as long as they keep a licence with one vendor. That is not unusual and it is not necessarily a problem while the relationship works. It becomes one when the vendor raises prices at renewal, is acquired, discontinues a product, or simply stops being the right fit — at which point the cost of leaving includes years of continued licensing or a large extraction exercise.

Raising the figure is mostly a procurement matter. Some vendors offer free or inexpensive restore-only tooling that works after a subscription ends; ask whether yours does and get it in writing. Where they do not, writing the long-term retention copy in a standard format makes the statutory history independent of the vendor, and that is often enough, because day-to-day operational backups only need to reach back weeks or months and will naturally migrate as new ones are taken.

The practical test is straightforward: pick a restore point from two years ago and work out exactly what you would need to restore it if your contract ended today. If the answer involves a licence you would no longer have, you have found your lock-in.

What this looks like in practice

A UK architectural practice with 75 staff had used the same cloud backup service for six years, protecting its file servers, a project database and Microsoft 365. The service had been reliable. At renewal the price increased by around forty per cent, and the practice decided to move to an alternative it had been offered.

The difficulties surfaced in the first week of planning. The contract had a ninety-day notice period, and renewal was forty-five days away, so the practice was already committed to another twelve months. The backups were held in the vendor’s own cloud, in the vendor’s proprietary format, encrypted with vendor-managed keys, and the contract provided thirty days of access after termination before deletion. The practice held seven years of restore points because its professional indemnity insurers expected project records to be recoverable for that long, and the oldest five years sat in an archive tier with retrieval measured in hours per request.

The vendor offered no restore capability without an active subscription. Its export function produced standard-format output, but only for current data, not for historical restore points. Extracting seven years of history meant restoring each relevant point and exporting it, within a thirty-day window, from archive storage with hours of retrieval latency per request.

With a year now available because of the missed notice window, the practice planned properly. It inventoried the history against its retention requirements and found that only quarterly and year-end restore points were needed for the full seven years. Those were restored and exported to standard formats over three months, verified by sample restores, and written to storage in the practice’s own cloud account with an immutable lock matching the remaining retention. Daily and weekly history was left to expire. The new provider was chosen partly on exit terms: backups written to the practice’s own storage, customer-managed keys, and a restore-only tool that remains available after a subscription ends.

Six years of good service and we had never once asked what would happen if we wanted to leave. The price rise was what made us look, and by then we were too late for the notice window anyway. The second time round, the first question we asked every provider was how we would get our data back out, and we chose the one with the best answer rather than the cheapest quote.

Two points generalise. The first is the missed notice window, which converted a planned switch into a further year’s commitment — and which, ironically, provided the time a proper exit needed. The second is the inventory: by mapping history against actual retention requirements, the practice reduced the extraction from seven years of every restore point to a few dozen, which is the step that made the exit manageable.

When some lock-in is acceptable, and how to hedge the rest

It is worth being clear that the aim is not to eliminate lock-in. Every useful backup product creates some, and chasing perfect portability usually means accepting worse protection, more storage, or more operational work. The aim is to know which lock-in you are accepting and to cap its cost.

Acceptable lock-in

Operational backups — the daily and weekly restore points that cover recent accidents, corruption and ransomware — are naturally short-lived. If you change provider, the new system starts building its own history, and within weeks or months the old system’s operational restore points are no longer the ones you would reach for. Proprietary formats for this tier are a reasonable price for efficiency, because the exposure is bounded by a short retention window.

Lock-in worth hedging

Long-term retention is different. Restore points kept for six or seven years for statutory, contractual or insurance reasons outlast any reasonable expectation of staying with one vendor, and they are precisely the history that a dispute, an audit or a regulator will ask for. That tier is where lock-in is expensive, and where hedging pays.

The hedge: separate the long tail

The most effective approach for most UK SMEs is to keep the long-term retention copy independent of the operational backup vendor. That can mean writing month-end or year-end archive copies in standard formats to storage you own, with immutability set to the retention period, while the operational backups run in whatever product works best. If the operational vendor changes, the long-term history is unaffected, and the exit becomes a matter of weeks rather than years.

The same principle underlies the familiar copy rules. Holding more than one copy in more than one place is usually discussed as protection against loss; it is also protection against being dependent on one supplier for all of your history. The broader copy strategy is covered in our guide to the 3-2-1 backup rule, and the multi-provider variant in our guide to multi-cloud backup.

One caution: a second copy that nobody restores from is a second copy you cannot rely on. Whatever arrangement holds the long tail, test a restore from it at least annually, from the oldest restore point you claim to hold, as described in our guide to backup restore testing.

Common mistakes with backup lock-in

The errors below recur across UK organisations. Almost all are made at signature and discovered at exit.

• Never asking what happens at termination. Only about 17 per cent asked about exit terms before signing. The question costs nothing at procurement and gains a great deal of leverage.
• Assuming switching providers moves the history. It almost never does. New backups go to the new system; years of retention stay in the old one unless deliberately extracted.
• Missing the notice window. Auto-renewal with sixty or ninety days’ notice is the commonest reason a planned switch slips by a year.
• Leaving history in vendor storage with a short deletion window. Thirty days is not long to retrieve terabytes from archive tiers with hours of latency per request.
• Accepting vendor-held keys without considering exit. Your access to encrypted history depends on the vendor for as long as they hold the keys.
• Setting compliance-mode immutability without thinking about exit. Locked data cannot be deleted early by anyone, so its storage cost continues until the lock expires, provider or no provider.
• Extracting every restore point rather than what retention requires. Mapping history against actual obligations usually reduces an extraction from years of daily points to a few dozen.
• Not verifying exports by restoring from them. A completed export is not a restorable one until a sample has been restored and opened.
• Overlooking backup ownership in a managed service. When backup is bundled with IT support, the data and licences may belong to the provider, making a change of IT provider a negotiation over your own history.
• Forgetting deletion confirmation. When the relationship ends, written confirmation that the provider has deleted your data closes the processor relationship properly.

The 12-point pre-signature due diligence checklist

Items one to four concern your data. Items five to eight concern the contract. Items nine to twelve concern how you run the arrangement so that exit stays possible.

1. Ask where the backups will be stored, and whose account that storage sits in. Customer-owned storage keeps the bytes under your control regardless of what happens to the software contract.
2. Ask who holds the encryption keys. Prefer customer-managed keys where available, and understand the access implications where they are not.
3. Ask what can be restored after the subscription ends, using what software. A restore-only capability after expiry is the single most valuable portability feature.
4. Ask whether historical restore points can be exported to standard formats. Not just current data — the history you keep for retention.
5. Establish the post-termination access window and what happens at its end. Negotiate a period that reflects your data volume and retrieval times.
6. Establish data return obligations, formats, timescales and charges. In writing, including deletion confirmation at the end.
7. Establish renewal terms and notice period. Record the date and set a reminder well before the notice window opens.
8. Request the cost and timescale of a full exit at your expected data volume. Compare it alongside the monthly price when choosing.
9. Separate the long-term retention copy from the operational backup vendor. Standard formats, storage you own, immutability matched to retention.
10. Set immutability periods with exit in mind. Locked data cannot be deleted early, so align lock periods to genuine retention rather than defaults.
11. Confirm ownership where backup is part of a managed service. Whose tenancy, whose licences, and what happens to both if you change IT provider.
12. Test a restore from the oldest restore point annually. From whatever holds the long tail, so that portability is proven rather than assumed.

At a glance — backup vendor lock-in

How Cloudswitched approaches backup portability

Cloudswitched designs and manages cloud backup for UK organisations, and we treat exit as part of the design rather than something to think about later. In practice that means asking where data will live and who holds the keys before recommending a product, preferring customer-owned storage and customer-managed keys where they suit the organisation, separating the long-term retention copy into standard formats you control, setting immutability periods that match genuine retention, and reading the post-termination terms before you sign rather than after you give notice. Where backup is part of a managed service with us, the backup data and storage belong to you, and we will say so in the contract. And if you are trying to leave another provider, we can plan the exit so that history survives the move.

Frequently Asked Questions

What is backup vendor lock-in?

The situation in which leaving a backup provider is substantially harder or more expensive than joining it was, because your backup data is held in a format only that provider’s software can read, in storage the provider controls, under contract terms that limit access after termination. It is common rather than unusual, because efficient backup relies on proprietary repository formats. The practical question is not whether a provider creates any lock-in, but how much of your history would remain accessible, and at what cost, if the relationship ended.

Can I move my old backups to a new provider?

Usually not directly. Backup repositories are generally specific to the product that wrote them, so the new provider cannot import the old one’s restore points. Switching protects new data from the switch date onwards, while history stays in the old system. The options are to keep the old system accessible in a read-only role until its retention expires, to restore and export selected historical restore points to standard formats, to restore and re-protect specific points in the new system, or to let unneeded history expire. Most organisations combine these based on what their retention obligations actually require.

What should I ask a backup provider before signing?

Where the backups will be stored and whose account holds that storage; who holds the encryption keys; what can be restored after the subscription ends and using what software; whether historical restore points can be exported to standard formats; how long you retain access after termination; what data return obligations, formats, timescales and charges apply; the renewal and notice terms; and the cost and timescale of a full exit at your expected data volume. The single most revealing question is what you could restore the day after terminating, with what, from where, for how long, at what cost.

Are proprietary backup formats a problem?

Not in themselves. Deduplication, compression, incremental chaining and encryption make backup efficient and affordable, and they produce repositories that only the writing software can reassemble. Avoiding proprietary formats entirely usually means paying for considerably more storage. What matters is the escape route: restore capability after licence expiry, export of historical restore points to standard formats, and ideally a long-term retention copy held in standard formats independently of the operational backup product.

What does it cost to leave a backup provider?

It depends heavily on data volume, storage tier and contract. Typical components are egress to move history out, retrieval and rehydration charges for archive tiers, early deletion fees for cold data removed before minimum periods, a read-only licence if the old system must stay accessible, and parallel storage during the retention tail. For around 20 TB of history, one-off extraction costs might run from hundreds to a few thousand pounds, while keeping history in place can cost a similar amount every year for several years. Price both before deciding.

Is it better to keep old backups with the old provider or extract them?

Price both. Keeping history in place means paying for read-only access and storage until each restore point expires, which can run for years and falls gradually. Extracting means paying retrieval, egress and effort once, and then holding the result in storage you control. A middle path often works best: map history against what retention genuinely requires, extract the month-end or year-end points needed for statutory or insurance purposes to a standard-format archive, verify by restoring samples, and let operational history expire with the old system.

How long do providers keep data after the contract ends?

It varies, and it is defined in the contract. For vendor-hosted services, a window of around thirty days before deletion is common. That may be enough for a small dataset in hot storage and nowhere near enough for terabytes in archive tiers with hours of retrieval latency per request. Read the post-termination terms before signing, negotiate a window that reflects your volume and retrieval times or a paid extension option, and plan extraction well before giving notice rather than after.

Does immutable backup make leaving harder?

It can. Immutable backups in compliance mode cannot be deleted by anyone until the lock expires, which is exactly what makes them effective against ransomware. It also means that if they sit in storage you are leaving, you may continue paying for that storage until each lock expires. That is a reason to set lock periods to match genuine retention requirements rather than accepting long defaults, and to consider where immutable long-term copies are held, not a reason to avoid immutability.

What if our backup is part of our managed IT service?

Check who owns the backup data, the storage and the licences. When backup is bundled with IT support, it frequently runs on the provider’s platform, sometimes in the provider’s tenancy, which makes changing IT provider also a change of backup provider and turns your history into part of the exit negotiation. Confirm ownership in the contract, establish what happens to the backup data if you leave, and ideally ensure backup storage sits in an account you own regardless of who manages it.

Does UK GDPR help when leaving a backup provider?

It gives you a legitimate basis for clear terms. A backup provider holding personal data on your behalf is normally acting as a processor, and data protection law expects the contract between you to address deletion or return of personal data at the end of the service. That supports insisting on clear data return and deletion terms at signature, and obtaining written confirmation of deletion when the relationship ends. It does not, on its own, oblige the provider to convert your data into another vendor’s format.

How can we hedge against lock-in without changing provider?

Separate the long-term retention copy from the operational backup vendor. Keep operational backups — daily and weekly points for recent recovery — in whichever product works best, accepting that they age out naturally after any future switch. Write month-end or year-end archive copies in standard formats to storage you own, with immutability matched to retention. If the operational vendor later changes, the long-term history is unaffected and exit becomes a matter of weeks. Test a restore from the archive at least annually.

When is the best time to address lock-in?

At signature, and failing that, well before the next renewal notice window. Post-termination access, data return terms, export charges, customer-managed keys and storage ownership are all much easier to obtain when a provider is competing for your business than when you are trying to leave. For an existing contract, record the renewal date and notice period now, set a reminder several months ahead of the notice deadline, and use the renewal to fix the terms that matter.

Related reading

More guidance on protecting, governing and paying for UK business data and IT:

• Cloud network egress costs: controlling data transfer charges
• Microsoft 365 email archiving and eDiscovery
• Azure identity and access management: securing admin access
• Choosing an internet service provider: comparing contracts
• Cyber Essentials and insurance: how certification affects premiums