Most financial institutions today have a presence in the cloud, but adoption in the financial-services sector is still at a relatively early stage. Among the financial-services leaders who took part in a recent McKinsey survey, only 13 percent had half or more of their IT footprint in the cloud. But migration to the cloud is gathering momentum. More than half of the survey respondents—54 percent—said they expect to shift at least half of their workloads to the public cloud over the next five years.1
Given the value at stake, this sense of urgency is hardly surprising. A McKinsey analysis found that Fortune 500 financial institutions alone could generate as much as $60 billion to $80 billion in run-rate EBITDA in 2030 by making the most of the cost-optimization levers and business use cases unlocked by cloud.
Some early adopters are already making inroads into this pool of value. One European bank was able to deliver the same output with 20 to 30 percent smaller teams, after onboarding them on DevSecOps and cloud. Another bank in Asia that migrated more than half of its workloads to the cloud can now develop and launch multiple new products rapidly and at scale in international markets. And another European bank has partnered with a leading cloud service provider (CSP) to develop AI-based cyber-defense capabilities to improve security for its customers.
These examples are still outliers in the financial sector, where most companies have been tentative about moving to cloud at scale. There is good reason for this hesitancy, since cloud migration is uniquely complex for financial institutions. Furthermore, the IT landscape at financial institutions is particularly varied, with 40-year-old applications running alongside more modern systems.
These challenges and others have led financial institutions to move in a more incremental fashion when it comes to cloud, running limited experiments, for example, or targeting a subset of applications based on the ease of migrating them, or phasing their efforts to coincide with a planned exit from a particular data center. Focusing on a few of these kinds of high-impact “lighthouses” can be effective in creating early momentum. However, institutions that do not define an overall aspiration and put in place the right success factors to achieve it often fail to capture value from the cloud.
Three shifts to accelerate your cloud migration
Working with dozens of financial institutions on their cloud migrations, we have found that those seeking to evolve beyond nascent cloud programs need to make critical shifts across three dimensions: strategy and management, business-domain adoption, and foundational capabilities (exhibit). Which dimensions they choose to prioritize or emphasize will depend on their particular needs and the stage they have reached in their cloud journey.
1. Strategy and management
From ‘We need to experiment’ to ‘Cloud is in our future’
The most important step a financial institution can take in capturing cloud’s value is building awareness across the organization about the practical value of cloud as distinct from the exciting marketing material from vendors.
One route is to use lighthouses to demonstrate the future value potential and make them truly scalable. We find, however, that many institutions use what they call lighthouses as limited-life-span experiments. Persuading them to change that mindset and to treat them instead as “incubators”—which, with the right support and capability building, could be practical at-scale destinations themselves—is a big unlock. The best way to convince a CFO that cloud can reduce total cost of ownership or a business leader that cloud can speed innovation is to demonstrate that it does.
Another route is to work with CSPs as partners rather than vendors. Striking strategic deals can lower barriers to entry, especially costs, and signal full-scale commitment to cloud across the organization. This happened at one North American bank, which had been struggling to make much progress in its cloud migration. Technology was leading the charge, but it lacked sufficient investment and a plan for scaling, primarily because it couldn’t win the business’s support.
Realizing that this “slow-roll” approach would not scale, the CEO and business leadership got involved. They approached several CSPs to structure a strategic partnership with a primary provider. Not only did they manage to secure significant discounts to offset initial “bubble” costs, but the process also forced the bank to take a more comprehensive approach to its cloud migration in order to take advantage of all the services that the CSP offered.
The process also led them to secure a commitment from the CSP to train the bank’s staff on key tools and capabilities and co-invest in innovative propositions that could take advantage of the assets of the CSP’s parent company, such as its ecosystems and marketplaces. When the deal was announced, it was a clear signal internally and externally of the bank’s commitment to the migration, which quickly led many of those who had been resistant to get on board. The bank is now on track to migrate 70 percent of its applications to the cloud within three years.
Still another approach is to develop a comprehensive business case built around specific levers and use cases. Those break down into technology benefits in the form of better resiliency, lower maintenance and operations costs, and elastic infrastructure to meet varying demand, as well as business benefits, such as speedier innovation, lowered costs to experiment, and the ability to scale up advanced analytics. In this way, institutions can place less emphasis on the theoretical value of cloud and use the business case as a practical guide to real value, which makes it easier for the organization to understand and support the goals of a migration.
Would you like to learn more about Cloud by McKinsey?
2. Business-domain adoption
From ‘Make IT run better’ to ‘Make our business more valuable’
If an institution treats cloud migration as a way to improve IT, it will struggle to capture the cloud’s full value. Moving cloud out of the realm of an IT project to a business-backed initiative requires two things:
- First, change the operating model. Companies that have the most success have a working model where technology and business work together in cross-functional teams. This approach orients the entire cloud migration toward the business value it might generate.
- Second, start your migration at the domain level—a complete product, service, or function, such as the checking suite or security foundation—rather than by opportunistically moving disparate applications. Migrate one business domain and use it to build a repeatable approach, complete with support skills, that can be rolled out domain by domain across the institution. In the interest of practicality, companies sometimes choose to start with applications, which are easier to migrate, as a way to build skills and experience. But the full value of migration comes when those applications are mutually reinforcing within a domain. One institution calls this effect “app magnetism.” Within these parameters, joint teams calibrate the level of application modernization needed to capture business benefits and then build a pipeline of business use cases that can be enabled in the cloud, such as advanced analytics use cases, AI-enabled process automation, and innovative customer journeys.
One leading payments company initially struggled to make much progress on its cloud aspirations because it was limited to an “IT initiative.” That changed when it needed to integrate a major acquisition. Successful integration required closer collaboration between the business and technology groups, which allowed the company to shift its cloud strategy to a top business priority, a significant unlock.
In addition, the deal enabled the company to pilot new products on cloud as well as to modernize its IT’s core transaction-processing system. The company has since mandated that all new development will occur only in the cloud platform.
Over and above the benefits to IT, such as the consolidation of data centers and greater cost efficiency, the business benefits have been significant. The company has increased the velocity of its application modernization by 300 percent, improved data integration between the parent company and the acquisition, and established protocols that support the easy reuse of applications or features developed for different use cases. This has both decreased the time required to launch new products and increased customer satisfaction.
Cloud by McKinsey Insights
3. Foundational capabilities
From ‘Migrate apps but keep the same processes in place’ to ‘Automate as much as possible and install a hybrid ops foundation’
The short-term, incremental approach to cloud migration creates significant barriers that make it all but impossible to scale. For instance, defaulting to on-premises security controls, which are not well suited to the cloud, leads to delays or, worse, breaches. Investing in migrating apps without investing in a strong cloud foundation creates an economic reality where each successive app costs at least as much if not more to migrate than the first one. That’s because this approach doesn’t address the underlying infrastructure, security, and governance processes and merely transfers to the cloud existing process and operational issues that increase the “tech debt” the cloud is creating for management.
Building out an effective cloud foundation requires doing a variety of things, such as setting up the right number of isolation zones to limit fallout from issues affecting any one application. One of the most important actions is to automate everything that is possible to automate. Successful cloud innovators do the following:
- automate infrastructure processes through infrastructure as code (IaC)
- implement end-to-end application patterns that can be consumed as code by developers to enable a frictionless, self-serve experience
- use automated continuous integration/continuous delivery (CI/CD) pipelines
- adopt “policy as code” (PaC) and “security as code” (SaC)
SaC essentially automates the testing of application and infrastructure code to ensure that it meets security, resiliency, and compliance needs using policies that are instantiated as code rather than in word-processing documents. Any code that doesn’t meet these policy requirements is automatically rejected before it’s deployed. What needs to be corrected is clearly articulated so that the code can come into compliance.
When properly implemented, this SaC approach can also allow companies to more easily and clearly meet regulatory requirements and satisfy audit needs without significant disruptions. To define how the new foundations will improve the institution’s compliance, security, and resilience, top institutions integrate their risk functions across all three lines of defense.
This focus on automation also extends to FinOps (financial operations), the process of dynamically managing application costs in the cloud. Because the cloud is so dynamic—new servers can come online as needed, and capacity can be extended to meet unforeseen spikes in usage—automating finances can help to flag or adjust financial issues to keep costs in line with the business’s goals.
Lastly, leading institutions also rewire their operating model across application development, infrastructure, risk, and security to take full advantage of the automation enabled by cloud, particularly during the period before the full cloud migration is complete. This requires DevOps and site-reliability-engineering (SRE) practices, productized infrastructure services, outcome-driven governance, and engineering-centric capabilities. This “hybrid ops” management of both on-premises and cloud operations—for incident management, as an example—can set the stage for the institution’s eventual cloud destination while making sure nothing slips during the extended period when it is operating in more than one environment.
When one US regional bank began its migration, it planned to move 40–50 percent of its IT workloads to the cloud within three years, with the rest following in the next few years. But halfway through the first phase of the effort, it found that provisioning cloud infrastructure, such as environments, network changes, and access and identity management, still took three to four months—nowhere near the target of less than 24 hours. Only some aspects of the process had been automated, forcing application teams to continue using manual security controls and ticket-based requests, which introduced significant delays, limited the agility that cloud was expected to bring, and created additional risk.
Leaders decided to hit pause in order to build technical tools and capabilities that would enable them to make faster progress in the future. To lay a firm foundation, they committed to fully automating their cloud foundation and security controls. Another key step was to streamline policies and governance processes to take advantage of automation and minimize manual handoffs. Thanks to these and other efforts, the bank now expects to complete its cloud migration and exit its data centers ahead of its original schedule.
While most financial institutions are still early in their cloud journey, we are already seeing a widening gap in success between those taking a tentative, experimentation approach and those working backwards from a well-defined destination to architect lighthouses and a plan characterized by the three shifts outlined here. We believe this offers financial institutions their best chance of capturing the significant business value cloud can offer.
