Key Takeaways

• Cloud migration is strategically inevitable for most organizations, but the financial model is more complex than the capex-to-opex narrative suggests. Legacy application rewriting is a capital cost that rarely appears in initial migration budgets.
• Public cloud, properly configured, can be secured to a higher standard than on-premises infrastructure. The perception gap between actual risk and perceived risk is the primary driver of regulatory conservatism in banking.
• Uncontrolled cloud costs are almost always a knowledge and architecture problem, not a pricing problem. Organizations that return to on-premises infrastructure after a cloud migration typically did so because they could not manage costs, not because the cloud was inherently more expensive.
• Hybrid cloud is not a compromise. For regulated industries, it is the rational architecture: sensitive data and core systems on-premises or in private cloud, analytics and less sensitive workloads in public cloud.
• The question organizations should ask before committing to cloud-first is not how to get there, but whether it makes sense given their current application estate, regulatory environment, and organizational readiness.

Cloud Migration in Financial Services: What the Budget Often Misses

Cloud migration in financial services is the process of moving banking applications, data, and infrastructure from on-premises data centres to cloud environments, whether public, private, or hybrid. For financial institutions, this process carries regulatory, security, and cost dimensions that do not apply to most other industries.

Cloud migration tends to enter boardroom conversations as a cost optimization story. Replace capital expenditure with operational expenditure. Eliminate hardware refresh cycles. Pay for what you use rather than what you provision. The logic is sound, and for many organizations, the outcome matches the expectation.

For a significant portion, it does not. Organizations that return to on-premises infrastructure after a migration, a trend visible in enterprise IT over the past several years, consistently cite the same reason: costs that were not anticipated, not controlled, or not understood until they had already materialized. The cloud was not more expensive by nature. It was more expensive because the organization was not prepared to manage it.

This article examines three dimensions of cloud migration that financial services organizations and other regulated industries consistently underestimate: the hidden capital costs of application readiness, the real security comparison between public cloud and on-premises infrastructure, and the operational discipline required to keep cloud costs from becoming the budget problem that nobody planned for.

Hidden Costs of Cloud Migration: What Application Rewriting Actually Costs

The capex-to-opex shift is real, and for organizations with modern applications built on microservices architecture, migration to cloud can be relatively direct. The application was designed to be portable, the infrastructure underneath it is abstracted, and the move is primarily an operational exercise.

For organizations with legacy monolithic applications, particularly those running core banking systems or long-lived enterprise platforms, the picture is fundamentally different. These applications cannot be lifted and shifted to cloud infrastructure without significant rearchitecting. In many cases, they need to be rewritten. That rewrite is a capital cost. It does not appear in the operational expenditure model that makes cloud migration attractive, and it rarely appears in the initial migration business case.

One of Poland’s largest banks by assets offers a concrete illustration. The bank has a declared ambition to move toward cloud infrastructure and has been executing on that ambition incrementally. The mobile banking application was one of the first components to be assessed for cloud readiness. The assessment required evaluating which database services within a major cloud environment would best serve specific application functions. That kind of analysis, for a single application component, is indicative of the granularity required across an entire application estate.

The practical implication for CIOs planning cloud migration is that application portfolio assessment is the first budget line, treated with the same rigor as the migration strategy itself. The readiness of the application estate determines the true cost of migration, and for large financial institutions, that cost can run into hundreds of millions before a single workload moves to the cloud.

One factor that moderates this cost for large organizations is that application modernization is rarely a discrete project. Applications that are actively maintained receive regular updates, architectural improvements, and front-end refreshes as a matter of ongoing development. For organizations whose systems are continuously evolving, cloud readiness arrives incrementally rather than as a single costly migration event.

Hybrid Cloud for Regulated Industries: Architecture and Regulatory Requirements

The binary framing of cloud versus on-premises does not reflect how most large organizations actually operate, or should operate. Hybrid cloud architecture, which distributes workloads between on-premises infrastructure, private cloud, and public cloud based on data sensitivity, regulatory requirements, and performance needs, is the practical response to the real constraints financial institutions face.

The logic of hybrid architecture is straightforward. Applications and data that carry personal information, are subject to strict data residency requirements, or represent core business IP are candidates for on-premises or private cloud deployment. Applications that handle less sensitive workloads, support analytics, or benefit from elastic scaling are candidates for public cloud. The organization maintains control over its most sensitive assets while accessing the flexibility and cost efficiency of public cloud for everything else.

For banks operating in jurisdictions like Switzerland and Luxembourg, where regulators have historically restricted or heavily qualified the use of public cloud for banking workloads, hybrid architecture is a regulatory requirement rather than a design preference. What has changed is that major cloud providers now offer deployment models that bring cloud-native services inside a customer’s own data centre. The infrastructure is owned by the organization or hosted in a co-location facility, but the management model, the scaling mechanism, and the billing structure mirror those of public cloud. Organizations in restrictive regulatory environments can access cloud economics without placing data outside their own perimeter.

The regulatory posture on public cloud for banking is not static. The argument that public cloud is inherently less secure than on-premises infrastructure is increasingly difficult to sustain technically. Data breaches from on-premises banking infrastructure are documented and frequent. The security question worth asking is whether the organization has the knowledge and discipline to configure and maintain its chosen environment to an appropriate standard, regardless of where that environment sits.

Public Cloud Security: The Perception Gap and the Technical Reality

The dominant concern among financial services organizations that have not yet moved to public cloud is security. The concern is understandable: public cloud implies shared infrastructure, and shared infrastructure implies exposure. The concern is also, in most cases, based on a misreading of how public cloud security actually works.

Major cloud providers build their security services as native components of the platform, designed from the ground up for the architecture they support. Identity and access management, network segmentation, encryption in transit and at rest, audit logging, and threat detection are integrated into the platform rather than bolted on as third-party tools. An organization deploying on public cloud has access to security capabilities that would require significant investment to replicate on-premises, and those capabilities are maintained and updated by the provider.

On-premises security requires the organization to select, integrate, configure, and maintain each security component independently. The tools available are capable, but the operational burden is substantially higher. An organization that lacks the internal expertise to configure its security tools correctly is more exposed on-premises than it would be on a well-configured public cloud platform.

The gap between technical reality and organizational perception is the primary driver of regulatory conservatism in markets like Switzerland and Luxembourg. Regulators respond to organizational risk appetite, and organizational risk appetite is shaped by perception as much as by technical assessment. As the documented security performance of public cloud deployments in regulated industries accumulates, the regulatory posture in these markets is likely to shift. The technical argument for restriction is weakening.

Cloud Cost Management and FinOps in Financial Institutions: What It Actually Means

FinOps has become one of the more discussed concepts in enterprise cloud adoption over the past several years, for good reason. Cloud pricing models are fundamentally different from on-premises cost structures, and organizations that do not understand those differences consistently overspend.

The mechanism is not complex, but it requires active management that on-premises environments did not. In an on-premises model, hardware capacity is fixed. You cannot accidentally consume more compute than you have purchased. In a cloud environment, every service call, every data transfer, every storage operation accumulates cost in real time. An architecture decision made without understanding the billing implications of a particular service can generate unexpected costs that are only visible on the monthly invoice.

A straightforward example: an organization running a small database in cloud infrastructure might expect costs consistent with the database’s storage and compute requirements. If the backup strategy routes data to external storage rather than using the provider’s native backup services, the cost driver shifts from database utilization to data transfer. Data transfer pricing in cloud environments can be an order of magnitude higher than storage pricing, and an organization that does not understand this distinction will see costs that are difficult to explain until the architecture is audited.

Organizations that return to on-premises infrastructure after a failed cloud migration almost universally cite cost as the reason. In the majority of cases, the cost was not inherent to cloud infrastructure. It was a function of architectural decisions made without adequate cost modelling, combined with an absence of the monitoring and governance practices that keep cloud consumption aligned with budget expectations.

Effective cloud cost management requires three things that are rarely in place at the start of a migration: a billing model that connects cloud consumption to business units and cost centres, architectural standards that incorporate cost efficiency as a design requirement alongside performance and security, and a continuous monitoring practice that surfaces cost anomalies before they become invoice surprises. The organizations that manage cloud costs well treat financial governance as an engineering discipline, not an accounting function.

Cloud Readiness Assessment: What to Do Before Committing to Cloud-First

Cloud-first has become a default strategic posture for many organizations, driven by genuine advantages in flexibility, scalability, and access to managed services. The posture is reasonable for organizations whose application estate, regulatory environment, and internal capabilities align with it. For organizations where one or more of those conditions does not hold, cloud-first can generate the opposite of what it promises.

The question that should precede the migration strategy is whether cloud migration makes sense for this organization, given its current state. That requires an honest assessment of the application portfolio: which applications are cloud-ready, which require rearchitecting, which are so tightly coupled to on-premises infrastructure or external vendor systems that migration would require replacing them entirely. It requires an assessment of the regulatory environment and what it permits. And it requires an assessment of the organization’s internal capability to manage cloud infrastructure, cloud costs, and cloud security to the standard required.

Organizations that skip this assessment and move directly to migration strategy typically discover the constraints partway through a project, when the cost of course correction is highest. The assessment is not a preliminary formality. It is the work that determines whether the migration will deliver its expected value.

In Practice

Cloud migration in financial services carries technology, regulatory, financial, and organizational dimensions that need to be assessed together before a migration strategy is defined. Organizations that treat it as a technology project tend to discover the other dimensions as complications midway through delivery, while those that treat it as a business decision from the start tend to move more slowly at the outset and more reliably at scale.

The shift from on-premises to cloud infrastructure is difficult to reverse in any practical sense. Cloud-native development patterns, managed services, and the organizational capabilities that grow around cloud operations create dependencies that make returning to on-premises infrastructure costly and disruptive. Getting the initial assessment and architecture right is worth the investment. Rushing it because cloud-first is the strategic direction typically is not.

FAQ

Why do some organizations return to on-premises infrastructure after cloud migration?

In almost all documented cases, the reason is cost. Organizations that migrated without adequate cost modelling, architectural standards for cost efficiency, or continuous cost monitoring find that their cloud expenditure exceeds their on-premises costs. The costs are a function of architectural decisions and operational practices that were absent before or during the migration, rather than inherent to cloud infrastructure pricing.

Can public cloud be secured to the standard required by financial regulators?

Yes, in most regulatory jurisdictions. The security capabilities available in major public cloud platforms, including identity management, encryption, network segmentation, audit logging, and threat detection, are comparable to or more sophisticated than what most organizations can deploy on-premises. The gap between what is technically possible and what regulators permit in some jurisdictions, particularly Switzerland and Luxembourg, reflects organizational risk perception and regulatory conservatism rather than a genuine technical limitation. That gap is narrowing as the evidence base for public cloud security in regulated industries accumulates.

What is hybrid cloud and when does it make sense?

Hybrid cloud distributes workloads between on-premises infrastructure and one or more cloud environments based on data sensitivity, regulatory requirements, and performance needs. It makes sense for any organization that has workloads with different risk profiles: core banking systems or data with strict residency requirements on-premises, analytics and less sensitive applications in public cloud. For large financial institutions in regulated markets, hybrid architecture is typically the rational long-term model rather than a transitional state.

What is FinOps and why does it matter for cloud migration?

FinOps is the practice of managing cloud costs as a continuous operational discipline rather than a periodic accounting exercise. It matters because cloud pricing models, unlike on-premises infrastructure, are consumption-based and can generate unexpected costs when architectural decisions do not account for billing implications. Effective FinOps requires connecting cloud consumption to business units, building cost efficiency into architectural standards, and monitoring consumption continuously. Organizations that treat cloud cost management as an accounting function rather than an engineering discipline consistently overspend.

How should organizations approach the application readiness assessment before cloud migration?

The assessment should categorize the application portfolio across three dimensions: cloud-ready applications that can be migrated with minimal modification, applications that require rearchitecting or rewriting to be cloud-compatible, and applications that are so tightly coupled to on-premises infrastructure or third-party systems that migration would require replacement. Each category carries a different cost profile and migration timeline. The assessment output should inform the migration business case, not follow from it. Organizations that build the business case before assessing application readiness consistently underestimate the true cost of migration.