How portable is our infrastructure if we change IaaS provider?

Infrastructure portability is the ability to move workloads, data, configurations and operational processes from one Infrastructure as a Service (IaaS) provider to another without unacceptable disruption, rework or loss of functionality. It is not a single technical feature: portability depends on the workload architecture, data dependencies, network design, identity controls, licensing arrangements and the quality of the documentation supporting the environment.

A workload may be technically transferable but still difficult to relocate in practice. For example, its compute resources might move successfully while its firewall rules, access permissions, monitoring, backup policies or integrations need to be rebuilt. Portability should therefore be assessed across the complete operating environment rather than by asking whether the servers can be copied.

• Compute and operating systems: Check whether the target provider supports the required operating system versions, processor architecture, storage drivers and machine images. Differences in virtual hardware, boot processes or guest tools can affect performance and may require configuration changes.
• Storage and data: Identify the volume of data, its format, retention requirements and transfer method. Large datasets can take considerable time to copy and validate. Databases may require replication, export and import procedures, or application-level synchronisation to prevent changes being missed during the transition.
• Network design: Document IP addressing, routing, firewalls, load balancing, DNS, private connections and remote-access arrangements. A new provider may use different networking constructs, so the design may need to be translated rather than copied directly.
• Identity and access: Record users, service accounts, privileged roles, authentication methods, certificates, keys and dependencies on directory services. Access controls should be recreated deliberately instead of transferring broad permissions that are no longer appropriate.
• Applications and integrations: Map connections to software, APIs, email services, payment systems, file repositories and third-party platforms. An application can appear to work after migration while a less frequently used integration remains broken.
• Operations: Consider monitoring, alerting, patching, backup, vulnerability management, logging and support procedures. These controls are part of the infrastructure service even when they do not form part of the workload itself.

Provider-specific dependencies are usually the main obstacle to a clean move. These can include proprietary databases, managed queues, specialised storage, serverless functions, native backup formats, integrated security policies and platform-specific automation. The more an application relies on these services, the more likely it is that migration will involve redesign or a staged replacement rather than a direct transfer.

Portability is also affected by how infrastructure is created and maintained. Manually configured environments are harder to reproduce because important settings may exist only in an administrator’s notes or in the provider’s control panel. Maintaining accurate configuration records and using repeatable deployment definitions makes it easier to rebuild resources consistently. Those definitions should be reviewed for provider-specific commands and rewritten where necessary; copying automation without testing can reproduce incompatible assumptions.

Documentation should describe more than resource names. A useful portability record includes ownership, purpose, dependencies, data flows, service relationships, network rules, recovery priorities, credentials management, licensing terms and the order in which components must be started or stopped. It should also identify which settings are business requirements and which are simply features of the current provider.

A controlled migration normally follows a sequence similar to this:

1. Inventory the current environment. Catalogue workloads, data stores, dependencies, configurations, identities, security controls, licences and operational processes.
2. Classify portability risks. Separate components that can be recreated with limited change from those requiring conversion, replacement or application redevelopment.
3. Design the target environment. Translate the existing architecture into the target provider’s services, while checking capacity, performance, security and compliance requirements.
4. Build a non-production version. Recreate representative workloads and test connectivity, permissions, performance, backup, monitoring and recovery procedures.
5. Transfer and validate data. Use an agreed migration method, reconcile records and confirm that applications read and write data correctly before the final changeover.
6. Perform the cutover. Define a change window, freeze or control relevant updates, redirect users and integrations, and monitor the service closely against documented acceptance criteria.
7. Retain a rollback option. Keep the original environment in a usable state until the new service has been validated and the agreed rollback conditions have expired.
8. Decommission safely. Revoke old credentials, remove obsolete network routes, preserve required records and securely erase data in line with contractual and regulatory requirements.

Testing should cover business functions, not just whether virtual machines start. Check user authentication, scheduled jobs, file access, database transactions, integrations, reporting, backup restoration, alert delivery and performance under representative demand. Where possible, involve the people who use the systems because they may identify process dependencies that technical documentation does not capture.

Business continuity planning is particularly important during a provider change. The migration plan should define acceptable service interruption, data loss tolerances, communication responsibilities, decision-makers and recovery actions. A provider exit should not depend on the outgoing platform remaining available indefinitely, so the business should understand how data will be extracted and how long it will remain accessible after termination.

Contract terms can materially affect portability. Before committing to an IaaS service, review data export rights, export formats, egress charges, retention periods, assistance with migration, ownership of configurations, access to logs, termination procedures and obligations for deleting data. Also check whether software licences can be moved to another environment and whether support arrangements change when workloads leave the provider.

A practical portability assessment can assign each workload a rating based on technical effort, business risk, data complexity and dependency on provider-specific services. This helps prioritise remediation. Critical systems may justify reducing proprietary dependencies, maintaining tested export procedures or designing a secondary recovery environment, while less important workloads may be accepted as more tightly coupled to the chosen platform.

For a small or medium-sized organisation, the sensible objective is usually not complete independence from every provider. A better objective is informed exit readiness: knowing what is portable, what would need redesign, how data would be recovered, which controls must be rebuilt and what the migration would involve. An IT services partner can help create the dependency inventory, review the target architecture and test the migration plan before a provider change becomes urgent.