Whichever cloud platform you choose, how easy is it to move away from it?

Digital sovereignty does not mean that you must avoid every dependency, but rather that you consciously manage control and freedom of action.

You choose a cloud platform with the future in mind. But the future cannot be predicted entirely.

Legislation and regulations change. Requirements around data and digital sovereignty may evolve. Technology continues to develop, and your own organisation does not stand still either. As a result, the solution that is the best fit today may no longer be the best choice five years from now.

In our view, a good cloud strategy is therefore not only about where you want to run your workloads today, but also about how much freedom to adapt you will still have tomorrow. This ties in directly with the principle that choosing a cloud platform should not create unnecessary dependencies, and that an exit strategy should form part of a considered cloud strategy from the outset.

Digital sovereignty is about more than where your data is located

At MCX, we help organisations determine where best to run their Oracle workloads. This might be on-premises, in the MCX cloud, on Oracle Cloud Infrastructure or on Microsoft Azure. The starting point is not the platform itself, but what an organisation needs in terms of continuity, compliance, security, performance, manageability and cost.

Once an organisation chooses an external cloud platform, another important consideration comes into play: digital sovereignty.

The first question is often where data is physically stored. That is important, but in our view sovereignty goes further. It is also about who ultimately has control over your data, which technologies you become dependent on and how much freedom you retain to make a different choice later.

So the question is not simply: where is our data stored? An equally important question is: do we retain sufficient control if our circumstances change?

Digital sovereignty is therefore not only about where your data resides. It is also about the extent to which you remain in control. Who has access to your data, how you meet compliance requirements and how much freedom you retain to redesign your environment if circumstances change.

Control starts with design

Digital sovereignty does not suddenly become relevant when you actually want to move to another platform. The decisions that determine how straightforward or difficult that move will be are made much earlier.

This starts, for example, with key management. With BYOK, Bring Your Own Key, you provide and manage your own encryption keys rather than handing full control of them to the cloud platform. This reduces an important dependency.

But the same principle applies to the architecture as a whole. The more deeply an environment becomes intertwined with platform-specific technology, the greater the effort that may be required to move that environment elsewhere later.

That is why, when designing an environment, we do not just consider what is technically convenient today. We also consider what today’s choices will mean tomorrow.

Open standards can help with this, as can containers and infrastructure as code. And with every managed service, it is sensible to consider not only the benefits it provides today, but also the dependency it creates.

Not every dependency is a bad thing. Sometimes a platform-specific service offers significant advantages in terms of performance, manageability or cost. What matters is that the dependency is created deliberately and that the consequences are clear if you later decide to move away from it.

This approach reflects the independent advisory role described in our earlier article about platform selection: architecture should support the organisation’s strategy, not the other way round.

An exit strategy that exists only on paper is not enough

When choosing a cloud platform, many organisations have considered the possibility of an eventual exit. On paper, they may have documented how data and workloads could be moved.

But the most important question comes next: does that plan actually work?

An exit strategy that has never been tested provides little more than theoretical reassurance. Only when you investigate what would actually be required to move an environment do the dependencies become clear.

Testing an exit strategy in practice reveals what moving to another platform would really involve. It gives you insight into which data can be transferred easily, which parts are specifically tied to the current platform and which components would need to be rebuilt. It also shows what expertise would be required and how long a migration is likely to take. This means you know not only that you can move, but also what it would take to do so.

By testing an exit strategy periodically, it becomes part of regular operational management rather than a document that is only retrieved once the need to leave has already arisen.

An exit strategy is therefore not a sign that you are planning to leave a platform. Instead, it is a way of making sure that you can leave if circumstances require it.

Not independent of technology, but free to choose again

Complete independence from a cloud platform is rarely the objective in practice. If you avoid every platform-specific advantage for fear of becoming dependent on it, you may also miss out on valuable opportunities.

The key, therefore, is to make conscious choices.

For each component, it is important to weigh the benefits of a specific service against the dependency it creates. A platform-specific solution may be perfectly appropriate for some components, while for others it may be wiser to keep the architecture as platform-independent as possible. Particularly for business-critical components, it is important to understand in advance what would be required to move them elsewhere in a controlled manner.

That is precisely why, at MCX, we look beyond the initial cloud decision. Our independent position means the answer is not predetermined. We manage Oracle environments across different platforms, allowing us to start with what an organisation needs rather than with the platform on which a workload is assumed to belong.

The best exit strategy starts before you want to leave

Choosing a cloud platform does not have to be a decision for life.

But the ability to change course later only exists if you take it into account today. In key management. In architecture. In the choice of technologies and managed services. And, above all, in an exit strategy that is not merely documented, but actually tested.

So take a critical look at your current environment.

Do you know which dependencies exist today? Who controls your data and encryption keys? Which components could be moved easily? And how much time would you actually need to move to another platform?

If those questions are difficult to answer, now might be the best time to start looking at them.