Cloud migration in regulated banking is almost always framed as a technology selection problem. Which provider? Which workloads first? What is the total cost of ownership against on-premise? These are real questions, and they will eventually need answers. But the decision that most determines whether a cloud migration delivers lasting value or simply relocates existing complexity is not a technology question at all. It is an organizational question: who owns the cloud estate once it is built, how does accountability change when the infrastructure moves, and what governance structures must exist before the first workload is migrated?
Regulated financial institutions have a particular version of this problem. They operate in environments where data residency, audit trails, regulatory access, and operational continuity standards are not negotiable. In Saudi Arabia, SAMA's cloud computing framework and the broader Vision 2030 mandate for digital infrastructure mean that the cloud is not a distant option but an active strategic direction — for government services, for payment infrastructure, and increasingly for banking operations. Yet the pattern of cloud engagements that struggle to deliver is consistent: the technology choices are made carefully while the organizational decisions are deferred until the migration is underway and the cost of getting them wrong is already high.
The question that determines cloud migration success is not which provider to use. It is which team owns the estate on Day 1 of production, what authority they have to enforce standards, and what happens when a business unit builds something outside those standards.
Answering that question before signing a cloud agreement is the governance work that distinguishes institutions that build cloud capability from institutions that build cloud debt.
The lift-and-shift trap
The default path for most regulated institutions entering cloud migration is lift-and-shift: move existing workloads to cloud infrastructure with minimal re-architecture, preserve existing operating procedures, and plan for optimization in a future phase that frequently never arrives. The logic is understandable. A direct migration reduces initial risk, preserves institutional knowledge about how systems behave, and allows teams to demonstrate progress to leadership without requiring the organization to fundamentally change how it operates technology.
The problem is that lift-and-shift captures the cost of cloud without capturing the value. Cloud infrastructure priced for on-demand, elastic workloads is expensive when operated as if it were fixed hardware. The operational model that made sense for a data centre — stable, predictable, centrally managed — does not transfer cleanly to an environment designed around ephemerality and self-service. Institutions that lift and shift their applications inherit the licensing costs of the cloud while retaining the operational habits of the data centre. They pay for both.
More significantly, lift-and-shift defers the organizational question. If the team that managed on-premise infrastructure continues to manage cloud infrastructure under the same governance structure, the cloud becomes a different place to run the same processes. The potential for cloud to change how technology decisions are made — faster, more distributed, closer to the teams that need the capability — remains unrealized. The institution has moved its estate without changing its operating model, and after two years, the cloud environment looks like a virtual data centre that costs more and behaves less predictably.
What the regulatory environment actually demands
Regulated institutions in KSA operate within a framework that is more specific about cloud requirements than it is often given credit for. SAMA's cloud computing framework establishes requirements around data classification, residency, operational continuity, and third-party access that shape which workloads can go where, under what conditions. These requirements are genuine constraints, and treating them as abstract compliance obligations rather than design inputs is a common source of migration difficulty.
The institutions that navigate this most effectively start from a data classification exercise that is tied directly to the regulatory framework. Not all banking data carries the same regulatory profile. The data that governs a customer's transaction history has different residency and access requirements than the data that governs internal analytics or staff management systems. Building a migration sequencing plan against data classification — moving low-sensitivity workloads early to build operational capability, preserving regulated data in compliant environments as capabilities mature — allows institutions to demonstrate cloud operating competency before they are required to operate regulated workloads in it.
This approach also produces something of lasting governance value: a data estate map that connects business systems to their regulatory classification. Institutions that build this as a byproduct of cloud migration planning typically find it has uses that extend well beyond the migration — in vendor governance, in audit preparation, and in the discipline of understanding what data the institution actually holds and where it lives.
The ownership question that cannot be deferred
Cloud environments without clear ownership degrade quickly. The architectural flexibility that makes cloud valuable — the ability for teams to provision infrastructure, experiment with services, and deploy independently — becomes a liability when no one is accountable for the coherence, security posture, or cost profile of what gets built. Without a cloud platform function that owns the estate — that sets standards, reviews architecture, controls access patterns, and is accountable for the total cost and risk exposure — the cloud becomes a shared space where every team builds to its own assumptions and the aggregate result reflects no one's intentions.
In regulated banking, this is not just an operational problem. A cloud environment where accountability is diffuse is an audit problem, a continuity problem, and a regulatory reporting problem. When a SAMA examination requires evidence of how a particular data set is protected in cloud infrastructure, the answer needs to come from a team that has accountable ownership of that infrastructure — not from a multi-party conversation about which team built the relevant component and whether it was built to a standard that anyone formally agreed to maintain.
The cloud platform function — whether built internally or sourced from a managed services partner with clearly retained design authority — is not a technology team. It is a governance function that happens to operate technology. Its primary output is not infrastructure; it is the set of constraints and capabilities within which other teams can build safely. Establishing this function before migration begins, with a mandate that is understood and accepted at the executive level, is the single most consequential organizational decision in a cloud migration programme.
Migration sequencing as capability development
The most durable cloud migrations treat sequencing as a capability development exercise rather than a workload delivery plan. Each phase of migration is designed not just to move systems, but to build the institutional knowledge, operational procedures, and governance reflexes that will be required to run regulated workloads in cloud environments at scale.
This means that the first migrations are deliberately chosen for learning value, not just technical simplicity. A workload that is technically easy to move but operationally identical to what the team already manages does not build new capability. A workload that requires the team to develop new incident response procedures, learn new observability tooling, and establish new vendor escalation paths for the cloud provider — even if it is moderately complex — produces institutional capability that persists after the workload is live.
By the time a regulated institution reaches the migrations that genuinely require cloud governance maturity — core processing systems, payment infrastructure, customer data environments — it should be drawing on accumulated experience rather than developing capability under operational pressure. The sequencing decision is a learning investment decision. The institutions that treat it as such arrive at their most consequential migrations with significantly more governance confidence than those that optimize each migration in isolation.
The conversation that actually needs to happen
The cloud conversation that needs to happen in regulated banking leadership is not about which provider offers the best terms or which workloads have the highest migration return. It is a conversation about how the institution intends to govern a technology estate that will increasingly live outside its direct operational control — and what organizational capability it needs to build to do that responsibly.
That conversation requires honest answers to questions that are frequently avoided because the answers are organizationally uncomfortable. Which team will be accountable for the cloud estate's security posture, and what authority will they have to enforce standards that business units find inconvenient? What will happen when a business unit builds outside those standards — and it will happen — and who has the mandate to require remediation? What is the institution's genuine risk tolerance for incidents in cloud environments during the period before full operational maturity is achieved?
These are leadership questions, not technology questions. The technology choices that follow from clear answers to them are almost always manageable. The technology problems that result from avoiding them are frequently not. Regulated institutions that want to build cloud capability rather than cloud debt need to have this conversation early, honestly, and with the organizational authority to act on what it concludes.