A bank can spend years moving its technology infrastructure to the cloud, only to discover that moving it somewhere else is considerably more difficult. Applications that were once hosted in its own data centres are now connected to cloud-specific databases, security services, analytics platforms and increasingly sophisticated AI capabilities. These services make banking systems easier to develop, operate and scale, but they also create dependencies that are not always apparent when the original technology decisions are made. The problem becomes particularly significant when a financial institution wants to change providers, negotiate new commercial arrangements or reduce its exposure to a single technology company. Although cloud computing has long been associated with flexibility, the practical ability to switch providers depends on much more than whether an application can run on another server. For banks operating payment platforms, customer databases, fraud detection systems and other critical services, portability is becoming an important test of how much control they retain over their technology infrastructure.
The Cloud Lock-In Problem Is More Complicated Than It Appears
Cloud computing has allowed banks to modernise applications without having to build and maintain every component of their underlying infrastructure. Instead of purchasing servers, configuring databases and managing storage systems independently, technology teams can use services supplied by Amazon Web Services, Microsoft Azure, Google Cloud and other providers. This has made it possible to develop new banking applications more quickly, scale computing resources according to demand and access sophisticated technologies that would otherwise require significant internal investment. However, the same convenience can gradually create dependencies that make changing providers difficult. A banking application may use one cloud service for storing customer records, another for processing transactions, a third for managing encryption keys and several others for monitoring performance, analysing data and supporting machine learning. Each service may be well suited to its particular function, but the combined architecture can become closely tied to the original provider.
Consider a bank that develops a cloud-based fraud detection platform. The system may receive payment events through a managed streaming service, process them using cloud-native computing resources, retrieve customer information from a proprietary database and run machine learning models through the provider’s AI platform. Although the bank owns the application and the business logic, much of the supporting technology may depend on services that are not directly available in another cloud environment. Moving the application would therefore involve replacing or adapting these components, transferring historical information, rebuilding integrations and demonstrating that the replacement system can process transactions with the same speed and reliability. The application itself may represent only a small part of the migration effort. This is the central difficulty with cloud portability: banks can retain ownership of their software while becoming operationally dependent on the infrastructure and services surrounding it.
Why Kubernetes Does Not Completely Solve the Portability Problem
Containerisation and Kubernetes have become important technologies in banking modernisation because they allow applications to be packaged and deployed more consistently across different computing environments. A container can include an application and many of the software dependencies required to run it, while Kubernetes provides a standardised way to deploy, manage and scale those containers. This offers meaningful advantages for banks seeking to operate applications across private infrastructure and public cloud platforms. Development teams can establish more consistent deployment processes, automate infrastructure management and reduce some of the differences between computing environments. For applications designed around standard interfaces and relatively independent components, these technologies can make migration considerably easier than it would be with traditional infrastructure.
The limitation is that a banking application rarely operates independently of its surrounding systems. Kubernetes can manage application containers, but it does not automatically make cloud databases, identity management systems, storage platforms or networking services interchangeable. An application developed using Kubernetes on one provider may still depend on proprietary database capabilities, encryption services or monitoring tools that require significant changes when deployed elsewhere. Differences in network configuration, persistent storage and managed Kubernetes services can also introduce complications. For banks, the issue is particularly important because technical compatibility alone is not sufficient. A payment processing application must continue to meet transaction integrity, security, availability and performance requirements after migration. Kubernetes can reduce some forms of vendor dependency, but it cannot remove the need to redesign and validate the broader banking environment.
Data Is Often the Hardest Part of Moving to Another Cloud
Moving software between cloud environments can be relatively straightforward compared with transferring the information that the software processes. Banks maintain extensive collections of customer records, account histories, payment information, transaction logs, regulatory data and analytical datasets. These records may be distributed across operational databases, data warehouses, object storage and specialised processing platforms, with numerous applications depending on their availability. When a financial institution considers changing cloud providers, it must establish how these datasets can be transferred without compromising their integrity, confidentiality or accessibility. The complexity increases when systems must remain operational during migration, because new transactions and changes to existing records continue to occur while the data is being transferred.
For a core banking or payment processing platform, data migration is not simply a matter of copying information into another database. The bank must ensure that account balances, transaction histories and financial records remain consistent throughout the transition. This may require change data capture, database replication, transaction reconciliation and carefully controlled cutover procedures. If the original and replacement environments operate simultaneously, the institution must also determine how updates will be managed and how inconsistencies will be prevented. Proprietary database features can create further complications because equivalent functionality may not be available on the replacement platform. Even when the technical challenges can be resolved, transferring large volumes of data may require substantial network capacity, extended migration periods and temporary duplication of infrastructure. Data architecture therefore has a direct influence on how much practical freedom a bank has to change cloud providers.
Banking Workloads Cannot Always Be Moved Like Ordinary Enterprise Applications
Financial institutions face operational constraints that make cloud switching considerably more demanding than a typical enterprise technology migration. A company transferring an internal administrative application may be able to schedule downtime while systems are moved and tested. Banks operating customer authentication, payments, trading infrastructure or core banking platforms may have much less flexibility because interruptions can affect financial transactions and essential customer services. Even a technically successful migration can create serious problems if the replacement environment processes transactions more slowly, introduces unexpected latency or fails to maintain consistent records across connected applications. These risks mean that banks must validate the entire operating environment rather than simply confirming that the application starts successfully on another cloud platform.
The challenge extends to cybersecurity, regulatory compliance and operational resilience. Encryption keys, access permissions, network controls and monitoring arrangements must be recreated or transferred without introducing security weaknesses. Applications may also need to comply with requirements governing the location and processing of customer information, while outsourcing arrangements can involve contractual obligations relating to audit rights, regulatory access and incident management. A new cloud provider may offer suitable computing infrastructure but still require extensive assessment before it can support a critical banking function. These considerations explain why switching providers can become a major transformation programme involving technology, risk management, compliance, cybersecurity and business operations. The technical ability to deploy software elsewhere is only one part of establishing that the bank can safely operate it there.
Regulators Are Taking a Closer Look at Cloud Concentration Risk
The growing reliance of financial institutions on a relatively small number of hyperscale cloud providers has attracted increasing regulatory attention. In Europe, the Digital Operational Resilience Act (DORA), which began applying in January 2025, introduced a more comprehensive framework for managing information and communications technology risks and dependencies on third-party technology services. Among its requirements are provisions addressing contractual arrangements and exit strategies for ICT services supporting critical or important functions. The objective is not to prevent banks from using cloud infrastructure, but to ensure that they understand the risks associated with outsourcing important services and can respond appropriately when those arrangements become unsuitable or unsustainable. This includes considering how critical functions could be transferred to another provider or brought back within the institution without unacceptable disruption.
The European Central Bank’s July 2025 guide on outsourcing cloud services further illustrates the supervisory attention being given to cloud dependency. The guidance addresses concentration risk, the use of proprietary technologies and the importance of credible exit arrangements. A bank may have a contractual right to terminate a cloud agreement, but that right offers limited protection if its applications cannot be transferred within a realistic timeframe. Supervisors are therefore interested in whether institutions have identified technical dependencies, assessed migration costs and developed workable transition plans. An important distinction is also emerging between business continuity and portability. A bank may be able to recover from a temporary outage using backup infrastructure while remaining unable to move a critical service permanently to another provider. These are different operational capabilities, and both need to be understood when assessing the resilience of outsourced banking technology.
Europe’s Data Act Could Make Switching Easier, but Not Necessarily Cheaper Overall
The European Union’s Data Act is another development with implications for cloud portability. Applicable from September 2025, the legislation includes measures intended to reduce obstacles to switching between data-processing service providers and improve interoperability. Its provisions address contractual restrictions, the transfer of data and digital assets, and the conditions under which customers can move between providers. The Act also provides for the removal of covered switching charges from January 2027, including relevant data egress charges. This could reduce one of the financial barriers faced by organisations transferring substantial volumes of information between cloud environments, particularly where large datasets have accumulated over several years.
However, the removal of switching charges does not eliminate the broader costs associated with migration. Banks may still need to redesign applications, replace proprietary services, transform data, rebuild security arrangements and conduct extensive testing before a new environment can be used in production. They may also need to operate both environments simultaneously during the transition, creating additional infrastructure and operational expenses. The receiving provider will continue to charge for the services used on its platform, while specialist engineering resources may be required to resolve compatibility problems. The Data Act can improve the commercial conditions under which switching takes place, but it cannot make different cloud technologies automatically compatible. For financial institutions, the practical value of these changes will depend heavily on the architecture of their existing applications and the extent to which portability was considered when those systems were developed.
Is Multi-Cloud Really the Answer?
Many financial institutions have responded to concerns about cloud concentration by adopting multi-cloud strategies. Rather than relying exclusively on one provider, they distribute applications and services across several cloud environments, sometimes alongside private infrastructure. This can provide access to different technologies, support commercial flexibility and reduce the institution’s overall dependence on a single supplier. A bank might use one platform for customer-facing applications, another for analytics and AI, and its own infrastructure for selected critical systems. Such arrangements can be useful, particularly where different workloads have distinct technical, regulatory or operational requirements. However, operating across multiple cloud providers should not be confused with the ability to move individual applications between them.
A bank may have substantial workloads on AWS and Azure while remaining unable to transfer a critical application from one platform to the other without significant redevelopment. In this situation, the institution has diversified its cloud suppliers but has not necessarily achieved application portability. Multi-cloud can also introduce additional complexity because technology teams must manage different networking environments, identity systems, security controls, monitoring tools and commercial agreements. Operating the same application across multiple providers can be even more demanding, particularly when financial records and transactions must remain consistent between environments. For certain critical services, the additional cost and complexity may be justified by resilience requirements. For others, a well-designed architecture within a single cloud provider, supported by appropriate recovery and exit arrangements, may offer a more practical balance. The important question is whether multi-cloud is addressing a clearly defined operational risk or simply adding another layer of infrastructure to manage.
Cloud Portability Needs to Be Considered During Application Development
One of the difficulties banks face today is that portability is often examined after an application has already become deeply integrated with a cloud provider. By that stage, replacing proprietary services can require extensive engineering work and may affect systems that have been operating reliably for years. A more effective approach is to consider portability during application design, particularly for systems expected to support critical banking functions over long periods. This does not mean avoiding every cloud-native capability. Managed databases, analytics platforms and AI services can deliver substantial operational advantages, and rejecting them purely to maintain theoretical portability may create unnecessary costs. The objective should be to understand where dependencies are being introduced and whether the benefits justify the difficulty of replacing those services in the future.
Banks can improve deployment flexibility by separating business logic from infrastructure-specific components, using well-defined APIs and adopting open standards where they are appropriate. Infrastructure-as-code tools can help recreate environments consistently, while containerisation can reduce dependencies associated with application deployment. Database selection is particularly important because the use of proprietary features can make future migration significantly more complicated. Technology teams should also consider whether identity management, encryption, monitoring and operational processes can be reproduced in another environment. For banking software vendors, these considerations are becoming relevant to product design. A solution that can be deployed across different infrastructure environments may offer an advantage to customers concerned about cloud concentration, sovereignty requirements or long-term technology flexibility. However, vendors must balance that flexibility against the performance and functionality available through specialised cloud services.
AI Could Create a New Generation of Cloud Dependencies
The rapid introduction of AI into banking technology may make portability even more complicated. Financial institutions are increasingly using cloud platforms not only for computing and storage but also for model development, inference, data retrieval, vector databases and agent orchestration. These capabilities are often delivered through tightly integrated managed services that simplify the deployment of AI applications. A bank building a customer service assistant or fraud investigation agent may use a cloud provider’s AI platform to access models, retrieve information, manage workflows and monitor performance. The application may work effectively within that environment, but transferring it to another provider could require replacing several interconnected services rather than simply selecting a different AI model.
There is also a behavioural dimension to AI portability. Two models may offer similar capabilities but produce different responses to the same instructions, interpret information differently or select different actions when connected to banking systems. Replacing one model with another can therefore require extensive evaluation to establish that the application continues to meet accuracy, security and operational requirements. For an AI-powered banking workflow, a technically successful migration does not necessarily mean that the system will behave in the same way. Banks may need to repeat model evaluations, test connected tools and review the controls governing automated decisions. This creates a new consideration for technology procurement: financial institutions must understand not only whether their data and applications can be transferred, but also how much of their AI functionality depends on a particular provider’s technology ecosystem.
A Cloud Exit Strategy Is Only Useful If It Can Be Executed
One of the most important questions for banks is whether their cloud exit plans have been tested under realistic conditions. An institution may have documentation describing how a critical application could be transferred to another provider, including estimated migration periods and responsibilities. Yet those assumptions may depend on data transfer speeds, application compatibility, technical resources and operational procedures that have never been validated together. When a provider relationship ends unexpectedly or a serious operational problem occurs, weaknesses in the plan may become apparent at precisely the moment when the bank has the least flexibility to address them. This is why practical testing of exit arrangements can be more valuable than simply maintaining detailed documentation.
A meaningful portability exercise should examine whether the application environment can be recreated, whether the required data can be transferred or restored and whether the replacement system can operate within acceptable performance and security parameters. For critical banking workloads, the testing must also establish that transaction records remain accurate, connected systems function correctly and operational controls are maintained. Banks do not necessarily need to conduct full production migrations every time they test an exit strategy. Representative workloads, controlled migration exercises and recovery environments can provide useful evidence while limiting disruption. These exercises can also reveal hidden dependencies, such as cloud-specific encryption services or monitoring components that were not originally included in the migration plan. Over time, this information can help institutions improve their architecture and develop a more realistic understanding of the cost and complexity of switching providers.
What Cloud Portability Means for Banking Technology Providers
Cloud portability is likely to influence how banks evaluate software vendors, infrastructure providers and technology partners. Financial institutions purchasing core banking systems, payment platforms, lending applications and financial crime solutions may increasingly examine the extent to which those products depend on specific cloud technologies. Questions about deployment flexibility, data extraction, integration standards and migration support could become more important during procurement, particularly for applications supporting critical business functions. Vendors able to demonstrate that their products can operate across different infrastructure environments may appeal to banks seeking greater control over outsourcing arrangements and long-term technology choices. Equally, providers offering highly specialised cloud-native capabilities will need to explain the benefits of those services and the implications of becoming dependent on them.
This could create opportunities for companies specialising in cloud migration, infrastructure automation, database replication, resilience testing and application modernisation. System integrators may also play a larger role in helping banks identify which workloads genuinely require portability and which dependencies can be managed through contractual protections, recovery arrangements and other controls. The commercial opportunity is not necessarily to make every banking application compatible with every cloud platform. It is to help financial institutions make informed choices about where portability matters, what it would cost to achieve and how those decisions affect operational resilience. As cloud infrastructure becomes more deeply embedded in banking operations, the ability to demonstrate practical deployment flexibility may become an increasingly valuable part of a technology provider’s offering.
The Real Question Is How Much Control Banks Want to Retain
Cloud computing has delivered substantial benefits to financial institutions, from faster application development and scalable infrastructure to access to advanced analytics and AI capabilities. These advantages are unlikely to diminish, and there is little reason for banks to abandon valuable cloud-native services simply because they introduce some degree of dependency. The more important consideration is whether those dependencies are understood and whether the institution has realistic options if its technology requirements, commercial arrangements or risk appetite change. Some banking applications may be relatively easy to move between providers, while others will remain closely tied to a particular platform because of their architecture, data requirements or use of specialised services. Treating all workloads as equally portable can create unrealistic expectations and lead to expensive technology decisions.
For banks, the strongest approach may be to distinguish between systems where portability is essential, applications where alternative recovery arrangements provide sufficient protection and services where the benefits of proprietary technology justify a greater degree of dependence. That assessment should influence application architecture, vendor selection, contract negotiations and operational resilience planning. Cloud portability is ultimately less about proving that a bank can move everything to another provider and more about ensuring that it has meaningful choices when circumstances change. A financial institution that understands its dependencies, tests its exit arrangements and makes deliberate architectural decisions is in a much stronger position than one that assumes the flexibility of cloud computing automatically extends to switching providers.
What this means for the industry
- Cloud adoption does not automatically provide cloud portability. Banks may own their applications while remaining heavily dependent on proprietary databases, security services, analytics platforms and other cloud infrastructure components.
- Regulatory expectations are increasing. DORA and supervisory guidance are placing greater emphasis on credible exit strategies, operational resilience and the management of critical technology dependencies.
- Data architecture can determine the feasibility of switching providers. Database compatibility, transaction integrity, replication requirements and data transfer complexity may present greater challenges than moving application code.
- Multi-cloud does not necessarily eliminate vendor lock-in. Using several providers can diversify technology relationships without making individual banking applications portable between them.
- AI introduces another layer of dependency. Proprietary model platforms, retrieval systems and agent orchestration services can make AI-enabled banking applications more difficult to transfer and validate in alternative environments.
- Cloud exit testing could become an important technology discipline. Financial institutions need evidence that critical services can be migrated, restored or replaced within realistic operational constraints.
- Banking technology vendors may face growing demand for deployment flexibility. Open interfaces, transparent dependencies and practical migration capabilities could become important differentiators in enterprise technology procurement.
