How Much Easier Do Open Standards Make a Cloud Move?

On 7 October, OVHcloud became a Platinum member of the Cloud Native Computing Foundation, the organisation behind projects including Kubernetes. The announcement highlighted its contributions to shared infrastructure software and its commitment to cloud portability. For a European business considering a provider change, that raises a practical question: how much of the existing system could move without being rebuilt?

Open standards give different suppliers a common set of rules for particular tasks. They can make software easier to move, but each standard covers a defined part of the system. This article explains where that helps, where migration work remains, and how to test the difference before making a commitment.

What the OVHcloud announcement tells buyers

The announcement describes engineering work as well as membership. It points to OVHcloud's contributions to Harbor, software for storing and distributing application packages, and its use of Cilium, which handles networking and security for applications. Our reading is that participation in these shared projects is a useful signal when assessing a provider's technical direction.

A membership announcement is not evidence that your application will transfer unchanged. Buyers still need to examine the specific service, its supported features and the dependencies their own engineers have introduced. A provider can contribute extensively to shared software while offering additional features that require different configuration elsewhere.

There is also a distinction between open source and open standards. Open source concerns access to software code and the rights granted by its licence; a standard defines agreed behaviour or a format that different implementations can support. We explored the broader control question in our article on open source and digital sovereignty. Here, the test is narrower: which parts of a working application can another provider accept and operate?

The application can keep a common foundation

Containers are a useful starting point. A container image packages an application with the supporting files it needs to run. The Open Container Initiative maintains specifications for these images, their distribution and their execution, giving different tools a shared basis for handling them.

That can preserve the application package during a migration, provided the destination supports its operating system and processor requirements. It reduces the need to rebuild packaging around one provider's deployment mechanism. It does not package the external database, staff accounts or network connections that the application needs.

Kubernetes, software for deploying and managing containerised applications, adds another shared foundation. The CNCF's Kubernetes conformance programme checks support for required application programming interfaces, or APIs: the interfaces through which software issues requests. For buyers, this provides evidence of common behaviour across certified offerings.

The boundary matters. Kubernetes explicitly separates cloud-specific integration from its core components. A deployment can therefore use common Kubernetes instructions and still rely on a particular provider's network routes or traffic distribution service.

Storage illustrates the same point. Kubernetes uses storage classes to describe available storage, with a particular storage implementation and its parameters behind each class. Moving the application's instructions does not move the underlying disks or establish that the destination has equivalent behaviour. Our recommendation is to identify these attachments before estimating how much of the deployment can be reused.

Data needs its own migration plan

Shared database software offers another useful starting point. PostgreSQL, for example, provides export and restore tools that can reconstruct a database on another machine. Its documentation also makes clear that a single database export does not include every shared object, such as the roles that define database users and permissions.

For a migration assessment, we would check the destination's supported database version, required extensions and administrative access before choosing a transfer method. Extensions add capabilities to the database, and the target needs the ones your application actually uses. A successful export is one milestone; a restored application completing its normal work is the acceptance test.

The transfer plan should also answer what happens to new records created during the move. A test export cannot establish an acceptable interruption window for a busy production system. We recommend measuring transfer and restore time with representative data, then deciding whether a separate method for copying ongoing changes is needed.

File storage presents a related distinction between compatibility and complete equivalence. Scaleway, for example, documents an Amazon S3-compatible interface for its object storage, which holds files such as documents and images. This can allow existing compatible tools to work with a European alternative.

S3 compatibility describes support for an interface originally defined by AWS; it should not be treated as an independently governed open standard or proof that every surrounding feature is identical. Amazon S3's own documentation describes a wider service, including access controls, versioning and integrations. Our advice is to test the operations your application uses, including large uploads, permissions and retention behaviour, rather than treating the compatibility label as a complete migration assessment.

Login and daily operations need separate checks

Open standards can also help with user login. OpenID Connect defines how an application can verify a user's identity through an identity provider. That shared approach can reduce the amount of login code tied to one supplier.

Its scope is authentication: establishing who the user is. For migration planning, we would separately examine what that user may do, how staff groups map to application roles, and how access is removed when someone leaves. A login demonstration should include both an authorised user completing a task and an unauthorised user being refused.

Applications also need credentials to access databases and files. We recommend tracing where those credentials come from, who can change them and whether the proposed destination can reproduce the intended permissions. Treat these as explicit migration decisions instead of assuming they travel with the application image.

The operating team needs a similar review. Our suggested acceptance criteria include a working alert, a restored backup and an application update performed by the people who will support the destination. These exercises test whether the team can operate the moved service, beyond showing that its opening page loads.

A manufacturer's portal shows the difference

Consider a hypothetical manufacturer with a supplier portal on a large US cloud. The portal runs in containers on Kubernetes, stores order records in PostgreSQL and keeps quality certificates in object storage. Staff sign in through a central identity service.

For this example, assume a trial on a European provider shows that the application images run unchanged and most Kubernetes deployment instructions can be reused. The same trial finds that the database export needs missing roles recreated, the file-storage permissions need adapting, and the destination requires different network settings. These are illustrative results, not a customer case study or a promise about any provider pair.

The business has gained something substantial: it can preserve its portal's core application while changing the surrounding infrastructure. The remaining work can be named and tested. That is a more useful planning result than either declaring the entire system portable or assuming a move requires a complete rewrite.

For the managing director, the next question is whether suppliers can still submit certificates and staff can still process orders. For the technology lead, it is which dependencies must change to make those outcomes reliable. A practical migration plan should connect each technical change to one of those business checks.

Ask for evidence at the boundary

Our recommendation is to start with one representative application and a controlled test environment. Agree what the trial must demonstrate before work starts. Use synthetic or appropriately protected data, and keep the trial separate from live operations.

The assessment should produce four concrete outputs:

• A reuse record: which application packages and deployment instructions worked unchanged, and which needed editing.
• A dependency map: every database, storage service, login system and external connection needed for the chosen business process.
• A transfer result: evidence that records and files arrived correctly, permissions behaved as intended, and the tested process completed.
• An operating record: who can deploy, monitor and restore the service, with measured timings and unresolved gaps.

Be precise about the scope of a successful trial. A portal that works with sample records has demonstrated compatibility for that test. Production planning still needs realistic volume, performance checks and a clear route back if the final move fails. Record those limits alongside the results so a board decision does not rest on a broader claim than the engineers have proved.

The same exercise helps before buying a new managed service. Ask which interfaces are standard, which extensions are specific to the provider, and what must change to use a second supplier. Request evidence for the features you need, including the chosen version and region, rather than accepting a general statement about portability.

There can be good reasons to accept a provider-specific feature if it saves your team substantial operational work. We recommend documenting that decision, its business benefit and the replacement work a future move would require. Open standards are most useful when they create understood options that your team can exercise.

OVHcloud's announcement is a timely reason to ask those questions. The practical value of shared technology becomes visible when an application, its data and its operating procedures have been tested on the proposed destination. That gives you a grounded answer about what can stay, what must change and what the move will demand from your team.

Thinking about migration? Book a free consultation to discuss your situation.