23 October 2026

What Happens to Your Data When You Cancel a Cloud Service?

Photo by Jakub Zerdzicki on Pexels

Cancelling a cloud subscription usually takes a few clicks. Working out what happens to everything that was stored inside it takes rather longer, and by the time the cancellation has gone through, that thinking needed to have already happened.

For a UK professional services firm, that one subscription might hold years of client records, case files, invoices, emails and project history. Some providers give an administrator weeks to retrieve anything left behind. Others start removing it far sooner, or lock everyone out the moment the account lapses. The rules depend on the service, the plan, and how it was originally bought, which is exactly why they're worth checking properly rather than assumed.

"Cancelled" Doesn't Mean the Same Thing Everywhere

Microsoft 365 for business subscriptions move through a set sequence of stages once cancelled: Active, then Expired, then Disabled, and finally Deleted. Cancel within the standard cancellation window and the subscription usually skips straight to Disabled. At that point, ordinary users lose access immediately, but an administrator can still sign in and pull data out. Microsoft's own guidance is direct about what happens next: anything left behind "might be deleted after 90 days and will be deleted no later than 180 days after cancellation," and it recommends backing up before you cancel, not after. There's a sharper version of this too: explicitly deleting a subscription, rather than just cancelling it, removes SharePoint and OneDrive data straight away, with no 90 to 180 day window at all.

Google handles it differently again. Google's own Workspace guidance tells administrators to export everything they want to keep, using the built-in Data Export tool, before they cancel. It also flags something worth knowing on its own: third-party app data isn't automatically removed when a Workspace subscription ends. If staff have been signing into other tools with their Google account, that data sits wherever those tools store it, untouched by cancelling Workspace, and has to be handled separately.

Two well-known platforms, two different processes. A smaller or less familiar cloud tool may follow neither, which is exactly why the provider's current terms need reading rather than assumed from how a different service once behaved.

Read the Cancellation Terms Before You Pick a Date

Before setting a cancellation date, find out when staff access actually stops, and whether an administrator keeps access for longer to retrieve data. Check how long information stays available afterwards, whether an export has to be requested before the account closes rather than after, and whether the account can be reactivated if plans change. Confirm when billing actually stops too: an annual or fixed-term contract may keep charging until the end of its term regardless of when access ends.

If the subscription was bought through a reseller rather than directly from the software company, the process might run through them instead of the vendor's own self-service tools. Worth confirming before assuming a standard admin-centre cancellation applies.

Work Out What Actually Needs to Come Out

Start by listing what the service actually holds, rather than exporting blindly and hoping. Depending on what it's used for, that could mean customer records, documents and attachments, emails, invoices, support tickets, project history or audit trails.

Standard exports don't always take everything with them. Comments, permissions, deleted items, automation rules and activity history are commonly left out of a basic export even when the main records are included. Read what the provider's export tool actually covers, and ask them directly if something important seems to be missing.

Run the export from a business-owned administrator account, and save the result somewhere the business controls, not an individual employee's personal downloads folder where nobody else can find it later. Large exports can take a while to generate, so start early enough to chase up anything that fails or looks incomplete before access actually ends.

A Download Isn't a Backup Until Someone's Opened It

A completed export doesn't automatically mean a usable one. Open a sample of every file type that came out. Check dates are right, attachments are actually attached, and nothing reads as a broken link or an orphaned record with no obvious connection to the client or project it belongs to.

If the business is switching to a replacement service rather than dropping the function altogether, test the import into the new system before the old one closes, not after. A CSV export can preserve the words and numbers in a spreadsheet while quietly dropping the relationships between them, so a customer and their invoices might land in separate files with nothing left linking the two together. Import a small batch first and ask the people who'll actually use the new system to check it looks right, before moving everything else across.

This is the same distinction that sits behind what "immutable backup" actually means on a cyber insurance form: a copy of data only counts for something if it's genuinely recoverable, not just present somewhere.

Untangle Every Connection Before Anything Gets Switched Off

Cloud services rarely sit in isolation. A website enquiry form might feed leads into the service being cancelled. Accounting software might pull invoices out of it automatically. Reports, scheduled tasks and email alerts might all depend on a connection nobody's thought about since it was first set up.

List what sends data into the service, and what pulls data out of it, including mobile apps, browser extensions, API connections and anything running on a schedule. Move or rebuild each of those connections before the account closes, and actually test that the replacement works rather than assuming it will.

It's also worth checking whether staff sign into other tools using "Sign in with Google" or "Sign in with Microsoft" through this account. If they do, set up an alternative sign-in method for those tools first, and confirm the business, not an individual employee, controls the recovery details on every account that depends on it. Once everything's moved, revoke the old access tokens, API keys and app connections rather than leaving them live and unused.

Some Records Aren't the Business's to Delete Yet

Financial records, signed contracts, client communications and employee files often carry a legal minimum retention period, and that period depends on the type of record, the industry, and what's actually in any relevant contracts. Speak to an accountant, solicitor or compliance adviser before deleting anything that might still need to be kept, rather than guessing at a safe date.

Keep a record of what was exported, when, who checked it, and where it's stored, alongside the cancellation confirmation, the final invoice, and any written response from the provider about what happens to the data left behind. Decide how long the exported copies themselves need to be kept, and delete them securely once the business genuinely no longer needs them.

Ask the Provider What Actually Gets Deleted, and When

Cancelling a subscription and permanently deleting an account aren't always the same action, and it's worth asking the provider to spell out the difference. Find out what happens to active data, deleted records, backups, audit logs and billing history, and whether any subcontractors also hold or process the same information. A provider might clear its active systems well before the same data finally ages out of its own backup retention period, so "deleted" can mean different things depending on which system is being asked.

This is exactly the kind of thing worth locking down in writing before a contract ends, not after. NCSC's supply chain security guidance puts it plainly: organisations should "ensure that contracts clearly set out specific requirements for the return and deletion of your information and assets by a supplier on termination or transfer of that contract." For anything genuinely important, ask for written confirmation once deletion's actually happened, rather than taking it on trust.

A Straightforward Way to Leave Any Cloud Service

1. Give one person ownership of the move, with enough time set aside for exporting, testing and fixing whatever doesn't come across cleanly the first time.
2. List what's stored in the service, who uses it, and what else connects to it, including any sign-ins that run through the same account.
3. Export the data through an admin account, and store the result somewhere the business controls.
4. Open the files and test the replacement before relying on either one.
5. Move every connected app, sign-in and automated process, and confirm each one still works once it's live.
6. Cancel once everything's been checked, and keep the confirmation, the final invoice and any correspondence about deletion.
7. Revoke old access and follow up on deletion, rather than assuming it happened just because the subscription ended.

None of this has to happen from scratch every time a subscription comes up for renewal. Checking what's actually being paid for, and what it would take to leave, can become part of a regular IT review, rather than a scramble the week a renewal notice lands.