CLOUD PORTABILITY VS SERVICE PORTABILITY: WHY MOVING A WORKLOAD IS NOT ENOUGH.

A workload can be portable without the service it supports being portable. That may sound like a technical distinction. For a public service, it can become a serious operational problem.

Imagine being told that a critical application could be moved to another cloud provider. The architecture is portable. The data belongs to the organisation. An alternative environment is available.

So, the move should be straightforward, shouldn’t it?

Not necessarily. The application may be able to run elsewhere, but what about the identity services users rely on to access it? The security controls that protect it? The monitoring, backup and recovery arrangements around it? The specialist knowledge needed to operate it? The contracts and supplier support required to make the transition work?

Moving the workload is only the beginning. The real test is whether the organisation could move the service and keep delivering it.

WHAT DOES CLOUD PORTABILITY ACTUALLY GIVE YOU?

Cloud portability is valuable.

At a technical level, it concerns the ability to move applications, workloads or data between environments with an acceptable level of effort. NIST’s cloud computing standards distinguishes portability from interoperability, including how different cloud systems exchange and use information.

For an organisation, greater portability can mean more flexibility over where workloads operate and fewer technical obstacles if it needs to change environments. But, calling an application portable only tells you so much.

It does not tell you how much work a move would require, what would need to change around the application or how quickly the service could become operational again. That matters because portability is rarely binary. An application that can run elsewhere after months of redesign and transition work offers a very different kind of choice from one that can be redeployed relatively easily.

Being able to move the technology is useful. Leadership also needs to know what exercising that option would involve.

CAN AN APPLICATION BE PORTABLE WHILE THE SERVICE IS NOT?

Yes.

Suppose the application has been successfully deployed into another cloud environment. Can users log in? Can historical data be recovered and used? Are the required security controls operating? Can teams monitor the service, manage incidents and restore backups? Do they know the new environment well enough to diagnose problems when something goes wrong?

Some of the harder dependencies may not appear on the architecture diagram at all. Specialist knowledge may sit with the existing supplier. Operational processes may depend on tooling specific to the current environment. Licensing arrangements may change when technology moves. Transition may require documentation, cooperation or support from incumbent providers.

Current portability and interoperability guidelines by European Commission reflect this wider problem. It covers workload portability alongside areas such as data formats and interfaces, APIs, identity and access management, service levels, switching procedures and exit information.

Moving compute solves only part of it.

The distinction is between cloud portability and service portability. Cloud portability asks whether applications, workloads or data can move between environments. At UBDS Digital, service portability has a broader meaning: can the organisation transition or re-establish everything required to continue delivering the service?

An application can therefore be portable while the service around it remains heavily dependent on the existing ecosystem.

DOES CLOUD PORTABILITY MEAN YOU ARE NO LONGER LOCKED IN?

Not necessarily.

Portability can reduce important technical dependencies. Open interfaces, portable architectures and less coupling to provider-specific components can make switching easier. But, dependency does not stop at the application.

A service might run across several cloud environments but still rely on one identity platform. An organisation might be able to export its data but lack the specialist knowledge required to reconstruct the service elsewhere. Another environment might be technically viable but too costly or disruptive to use within the required timeframe.

Calling all of this “vendor lock-in” can hide more than it reveals. It suggests that an organisation is either locked in or free to move. In practice, digital services depend on combinations of technology, data, suppliers, people and commercial arrangements. Some dependencies are easy to change. Others are difficult. Some are entirely worth accepting.

For leadership, a better question is: Where are we dependent, and does that dependency restrict a choice we may need?

NOT EVERY DEPENDENCY NEEDS TO BE REMOVED.

Cloud services create dependencies because organisations use capabilities that providers have spent years building.

That can be a perfectly reasonable trade. Managed and provider-specific services can reduce operational burden, provide sophisticated capabilities and allow teams to concentrate on the public service rather than rebuilding underlying technology.

Trying to preserve maximum portability can have costs too. Teams may need to maintain additional capability, support more complex architectures or avoid useful provider-specific services simply because they would be harder to replace later.

The decision is therefore not “dependency or no dependency”.

It is whether the benefit of a particular dependency is worth the constraint it places on future choices.

For one service, deeper integration with a provider may deliver enough value that a more difficult future transition is acceptable. For another, the consequences of losing an alternative may justify investing more heavily in portability.

The organisation should be able to make that decision deliberately, rather than discovering the trade-off only when it needs to change course.

HOW MUCH PORTABILITY DOES A SERVICE ACTUALLY NEED?

There is no sensible reason to demand the same level of portability from every public-sector service.

Consider a low-impact internal application alongside a critical citizen-facing service. The consequences of being unable to move them are unlikely to be the same, so the investment required to preserve an alternative should not automatically be the same either.

For public bodies, that distinction can be particularly important where digital technology supports essential or statutory services and users may have no alternative route to the service.

Start with the service. What happens if its current technology arrangement becomes unavailable, unsuitable or uneconomic? How quickly would an alternative be needed? Which dependencies would slow down the transition? How much disruption could users tolerate?

The answers tell leadership far more than a blanket requirement to “avoid lock-in”. Some dependencies may be acceptable as they are. Some may need mitigation. For a critical service where losing choice would have serious consequences, maintaining a credible alternative may warrant greater investment.

This is also the connection to digital sovereignty. Digital sovereignty is broader than the location of technology or data. It concerns the control and choice an organisation retains over the digital services it depends on.

Portability matters where it helps preserve a choice the organisation has decided it needs.

AN ALTERNATIVE SHOULD BE EXECUTABLE, NOT THEORETICAL.

An architecture diagram might show an alternative. A contract might provide an exit. A cloud strategy might require portability. Another provider might be available.

The harder question is what happens when the organisation tries to use that option. Could it transition the service within the time available? At an acceptable cost? Without causing more disruption than the service can tolerate? For a critical service, an untested alternative can provide false confidence. The commercial route needs to be executable too. Exit rights, licensing, committed expenditure and transition support can determine whether a technically viable alternative is realistic in practice.

That does not mean maintaining a duplicate service permanently or regularly migrating entire systems between providers. The evidence needed should be proportionate to the service.

For one service, it might be enough to demonstrate that data can be recovered and made usable elsewhere. Another may justify validating deployment into an alternative environment. Leaders may need assurance that security and operational capabilities can be recreated, that sufficient knowledge remains available, or that contractual transition support actually works as expected.

The point is to know enough about the alternative to judge whether it is real.

Where portability matters, it should be demonstrated rather than assumed.

PORTABILITY IS ABOUT PRESERVING A CHOICE THAT MATTERS.

Cloud portability can reduce technical switching barriers and give organisations more options over where workloads operate. However, a portable workload does not guarantee a portable service.

Nor should every dependency automatically be designed out. Some will deliver capabilities and efficiencies that justify the constraint they create. The leadership task is to know the difference: where dependency is acceptable, where losing choice would matter, and whether an alternative could actually be exercised when needed.

So when a critical workload is described as portable, the next question is more revealing: If we had to exercise that choice, could we keep delivering the service?

UBDS Digital’s Digital Sovereignty & Service Portability service helps organisations understand the dependencies surrounding critical services, identify where practical choice is constrained and determine where greater portability or other mitigations may be required.

Explore Digital Sovereignty & Service Portability.