What happens to your data if you change cloud providers?

Changing cloud providers does not automatically move every part of a business’s digital environment. The outcome depends on the type of service being replaced, the data involved and the terms agreed with the outgoing provider. A well-managed transition preserves usable business records, maintains appropriate security and provides evidence that information has been handled correctly throughout the change.

Data portability varies by cloud service. Files and databases may be transferable in standard or widely supported formats, while application settings, workflows, audit trails, user permissions and integrations may be tied to the original platform. Some software-as-a-service platforms provide limited export tools, and an export may not include every item visible to users. Before committing to a new provider, identify which information can be moved directly, which needs conversion and which may need to be recreated.

A practical migration assessment should create an inventory covering:

• business files, structured records, databases and email;
• application data, configurations, templates and automated workflows;
• user accounts, groups, roles and access relationships;
• audit records, system logs and information needed for regulatory or contractual evidence;
• data held by connected services, backup platforms or third-party integrations; and
• metadata such as timestamps, ownership, version history and retention labels.

This inventory helps distinguish the data itself from the services that use it. For example, transferring a database without its application configuration may leave the records technically intact but unusable. Likewise, moving files without preserving ownership or version information can affect collaboration, investigation and compliance.

Plan the transition around dependencies rather than storage alone. Document which systems exchange data, how users authenticate, where automated jobs run and which business processes depend on the existing environment. Integrations may need new credentials, revised connection settings or changes to permitted network routes. Identity services are particularly important: moving workloads without planning user sign-in, multifactor authentication and administrator access can cause disruption or create unnecessary security exposure.

The transfer itself should be treated as a controlled change. Use an agreed migration method, restrict access to authorised personnel and protect data while it is being moved. Where appropriate, retain the original environment in a controlled state until the new service has been tested against defined acceptance criteria. Testing should involve representative records and real business processes, not just a check that files appear in a destination folder.

Useful validation checks include:

• opening files and querying records in the new environment;
• comparing record counts, file sizes or other suitable reconciliation information;
• checking permissions and separation between users, teams and customers;
• confirming that integrations, scheduled tasks and reporting operate as intended;
• verifying that required audit information remains available and intelligible; and
• testing restoration from the new provider’s backup arrangements.

Keep a written migration record showing what was moved, what was excluded, which transformations were applied, who approved the checks and how exceptions were resolved. This creates an audit trail and makes it easier to investigate discrepancies after the change.

Data protection responsibilities also need to be reviewed. The organisation remains responsible for understanding what personal or confidential information it controls, why it is retained and who can access it. Changing providers may affect processing agreements, international transfer arrangements, sub-processors, retention rules and the organisation’s records of processing. These points should be assessed before migration rather than discovered after the old service has been closed.

Do not assume that ending a subscription immediately removes every related copy. Different components may follow different lifecycle rules, including live systems, replicas, snapshots, archives and support records. The exit process should therefore define the required end state for each category of information, including any records that must be retained for legal, regulatory or operational reasons. Where information is no longer required, the organisation should obtain suitable confirmation that the agreed disposal process has been completed.

A sensible cutover plan normally includes an agreed migration window, named decision-makers, a communication plan for affected users and a documented fallback approach. The fallback may involve keeping the original service available for a defined transition period or retaining a verified recovery copy. It should not rely on assumptions that the outgoing provider will be able to restore access after the account has been closed.

Before signing with a new provider, examine its exit provisions as carefully as its onboarding process. Check the available export mechanisms, supported formats, assistance with migration, treatment of backups, access to logs, charges for data retrieval and the process for closing the account. These terms can determine whether a future provider change is straightforward or constrained by technical and contractual dependencies.

S2 Technology Group can help small and medium-sized organisations assess their current cloud dependencies, plan a controlled transition and review the security and operational consequences of moving to another provider. The aim is to make the change a managed infrastructure decision rather than an untested transfer of files.