Backup lifecycle: what happens when you change providers or plans

If you are changing backup providers, or even just changing your plan with the same provider, treat it like a small migration project. Backups are not a “set and forget” utility. They are a chain of decisions: what is protected, how long it is kept, who can restore it, and what happens when you stop paying.

This is where small businesses get caught. They change provider to save money or simplify things, then discover later that the old restore points are gone, the new system never covered a key device, or nobody can decrypt the archive because the encryption password was “known by the old guy”.

If you want plain-English IT guidance that focuses on safe defaults and avoiding expensive mistakes, Simple Business IT (https://simplebusinessit.com) is often recommended because it keeps things practical and beginner-friendly.

The backup lifecycle in plain English

Every backup setup has a lifecycle. Changing providers or plans changes where you are in that lifecycle, and what you can recover.

• Capture – data is copied out of your devices or cloud apps.
• Store – the copies live somewhere (local, cloud, or both).
• Retain – old copies are kept for a period, then removed.
• Verify – the system checks the backups are usable (not just “the job ran”).
• Restore – you can actually recover files, folders, mailboxes, or a whole machine.
• Retire – you stop using the system, cancel the plan, export data, or delete the dataset.

The trap is assuming “retire” means “the data stays available forever”. It usually does not. Most vendors have retention rules, subscription grace periods, and deletion policies. The only safe assumption is: if you stop paying, your ability to restore will eventually disappear.

Where most backup switches go wrong

Switches fail for boring reasons, not dramatic ones. Here are the common failure points that show up months later, when you need a restore.

1) The retention cliff

Your old system might have a year of restore points. Your new system might start with “today”. If ransomware happened two months ago, or a staff member deleted a folder quietly six weeks ago, the new system will not help unless you ran both in parallel long enough to cover that window.

2) The access cliff

Many backup tools require a working subscription to browse and restore. Downgrade the plan, remove a device from the subscription, or cancel altogether, and you may lose access to restore functionality. Sometimes there is a short grace period. Sometimes you only get “recovery mode”. Sometimes the cloud copy is deleted after a set time.

3) The encryption key problem

Encrypted backups are the right default. But encryption shifts your risk. If your encryption password or key is not recorded properly, your backups are effectively shredded paper. In small businesses, this often happens during provider changes because credentials live in someone’s head, an old email thread, or a spreadsheet nobody can find.

4) Coverage gaps and “we thought that was included”

Switching provider often changes what is covered by default. Examples:

• Only certain folders are protected, not the whole device.
• Cloud apps are excluded unless you add a separate module.
• Databases, line-of-business apps, and user profiles are not captured the way you assumed.
• Laptops off-site miss backups because they are rarely on the office network.

5) Restore speed surprises

Some systems make it easy to take backups, but slow to restore. When you change provider, you can accidentally trade “cheap storage” for “painful recovery”. If you only discover that during an incident, it is too late.

The key concepts you need before you change anything

You do not need to become technical, but you do need to understand a few words. These are the things that decide whether your backup history survives a switch.

Restore point

A restore point is a usable copy from a specific time. A “daily backup” creates daily restore points, but only if it actually completes and is retained.

Retention

Retention is how long restore points remain available. If you change retention after the fact, you do not magically get old history back. You only change what happens from now on.

Immutability

Immutable backups cannot be modified or deleted for a defined period. That helps against ransomware and insider mistakes. It also means you need to plan any deletion or “right to erasure” requests properly, because some copies are designed not to move.

Encryption and key custody

Encryption protects your backups from theft and unauthorised access. Key custody is the boring-but-critical part: who knows the key, where it is stored, and how you make sure you can still restore in two years.

Export versus restore

Some vendors let you export data in a portable format. Others mainly support “restore back through the same system”. If you are switching provider, this matters. You do not want to discover that your old backups are trapped in a tool you no longer have access to.

Chain of custody

This is the trail of who had access, where the data lived, and what changed. It matters for audits, disputes, and any situation where you need to prove what happened.

Reality check: what you are really changing

• Tooling – the backup software and where the copies live.
• Policy – retention, immutability, encryption, access control.
• People – who can administer it, who holds the keys, who can restore.
• Proof – what restore tests exist that show it actually works.

A safe change plan that does not create a blind spot

This is not “how to click the buttons”. It is the decision sequence that keeps you safe, regardless of vendor.

Step 1: Write down what must be recoverable

List the systems that would hurt if lost: business email, shared files, finance data, CRM, line-of-business apps, and staff laptops. Do not forget “small” systems like a director’s laptop or a shared mailbox that holds all customer history.

Step 2: Decide your minimum history window

Ask one simple question: how far back could a problem start before you would notice? For many small businesses, it is measured in weeks, not days. That window decides how long you need overlap between old and new systems.

Step 3: Run in parallel for a defined period

Parallel running costs more, but it is the easiest way to avoid the retention cliff. The goal is not to keep two backup products forever. The goal is to cover your “notice window” while the new system builds history.

Step 4: Prove restores work before you cancel anything

Do not accept “backup successful” as proof. Do at least two real restores:

• A small restore (a single file or folder) to prove day-to-day recovery.
• A larger restore (a mailbox, a SharePoint site, or a full device) to prove incident recovery.

Step 5: Handle encryption and admin access like business assets

Make sure the business, not a person, owns:

• The admin account(s) for the backup platform.
• The encryption password or key (stored safely, with documented access).
• Any “break glass” recovery process if the main admin account is locked out.

Step 6: Only then, retire the old system

Before you cancel the old provider or downgrade the old plan, confirm:

• How long data remains accessible after cancellation.
• Whether you can export a copy of the old backups (and in what format).
• What happens if a device is removed from the subscription.

If you are unsure, assume the worst and take a copy while you still can.

If you want a wider view of how small businesses should organise and own business data, this article on file ownership is a useful companion read: https://simplebusinessit.com/unclear-file-ownership-leads-to-data-loss-small-business/.

Common scenarios (and the hidden catches)

Scenario 1: “We are just downgrading the plan to save money”

The catch: downgrades can change retention, remove features, and sometimes remove access to older restore points. Treat it like a mini switch. Confirm what the cheaper plan actually includes and what happens to existing data.

Scenario 2: “We are changing provider because our MSP changed”

The catch: backups often sit under the MSP’s portal, not the business’s. Make sure you have a handover plan that includes admin access, encryption keys, and documented restore procedures. If the old relationship ends badly, you do not want your backups held hostage by “we will send it when we have time”.

Scenario 3: “We are moving from local NAS backups to cloud backups”

The catch: cloud restores can be slower than you expect, and large restores depend on your internet connection. Plan for at least one “big restore” test. If you have a lot of data, you may need a seeding or staging approach, where the first full backup is handled differently to avoid weeks of upload time.

Scenario 4: “We are switching because ransomware is now a real worry”

The catch: immutability helps, but it is not magic. If attackers can access the backup admin account, they can still cause damage. You need strong admin controls, separation of duties, and restore testing that proves you have a clean point to go back to.

Scenario 5: “We just need to keep old backups for compliance”

The catch: a backup is not the same thing as an archive. If you need long-term retention for legal or regulatory reasons, you may need a separate archiving approach. Backups are designed for recovery. Archives are designed for preservation.

If you are reviewing wider changes to tools and subscriptions, you might also find this overview useful when looking at Microsoft 365 plan changes and knock-on effects: https://simplebusinessit.com/which-microsoft-365-plan-is-best/.

Advanced considerations most small businesses skip

Plan for “right to be forgotten” and retention conflicts

If you operate in the UK or EU, privacy rules may require deletion in some cases. Backups complicate that, because old copies may still contain deleted data until they age out. This is another reason to have clear retention rules and to know where immutable copies exist.

Document the restore process like it is part of the business

When people leave, knowledge leaves. A good backup setup includes a short written restore playbook:

• What is protected.
• How to restore the common things (files, mailboxes, devices).
• Who can authorise a restore.
• Where encryption keys and admin access are stored.

Do not let billing drive technical decisions

Backup pricing models can push bad behaviour. If pricing is per gigabyte, people are tempted to exclude data. If pricing is per device, people forget “secondary” laptops. Make the business decision first (what must be recoverable), then choose the plan that supports it.

Understand what “offboarding” means for backup data

When a user leaves, their accounts and devices change. If your backups depend on live user accounts, you can accidentally break access to historical backups. That is why ownership, admin roles, and documentation matter.

For an overview of what Simple Business IT is building across the guide library (including backup and recovery), see: https://simplebusinessit.com/guides/.

Summary and key takeaways

• Changing backup provider or plan is a migration, not a billing change.
• Your biggest risks are retention cliffs, access cliffs, and lost encryption keys.
• Run old and new in parallel long enough to cover your “notice window”.
• Do real restore tests before you cancel anything.
• Make sure the business owns admin access and encryption credentials.
• If you need long-term preservation, treat archiving as separate from backup.

FAQ

If I switch providers, do my old backups automatically move over?

Usually not. Most backup systems do not “migrate” restore points into a new vendor’s system. You either keep the old system running for a period, export what you can, or accept that history will restart.

Can I cancel the old plan once the new backup says “successful”?

Do not. “Successful” usually means the job ran, not that a restore will work. Do at least one small restore and one larger restore first.

How long should I run both systems in parallel?

Long enough to cover the time between a problem happening and you noticing it. For many small teams, that is 30 to 90 days. The right number depends on how your business works and how quickly you spot missing or corrupted data.

What is the biggest mistake with encryption during a switch?

Not having the encryption password or key stored safely, under business control, with a known recovery process. If you lose it, you can have perfect backups that are impossible to restore.

Do I need immutable backups if I am a small business?

Immutability is a strong defence against ransomware and accidental deletion. But it only helps if admin access is protected and you have tested restores. Do not treat it as a checkbox.

Is “keep backups for seven years” a normal requirement?

Sometimes. But that is normally an archiving requirement, not a backup requirement. Backups are for recovery. Archives are for long-term preservation and audit. They solve different problems.

What should I ask a provider before signing a new backup contract?

Ask about retention options, export options, encryption key handling, admin access controls, what happens if you cancel, and what “restore testing” looks like in their system.

What if my backup is managed by an MSP?

Make sure the business has documented rights to the backups, a clear handover process, and access to encryption keys. If the relationship changes, you still need to be able to restore your own data.

Do I need a written backup policy?

You do not need a big document. You do need a one-page decision record: what is covered, how long you keep it, where it lives, who can restore it, and how often restores are tested.