This is the second of three articles on how large enterprises can take advantage of cloud computing. It addresses the journey to the cloud. The first article identified the applications and platforms that are suitable for the cloud. The third will lay out an effective cloud operating model.

Large enterprises are increasingly adopting externally hosted cloud services, especially from such providers as Amazon Web Services (AWS), Google, and Microsoft along with such traditional tech vendors as Hewlett Packard Enterprise, IBM, and Rackspace. Done effectively, moving to the cloud can unlock significant benefits in business agility and deliver more productive, high-performing, and cost-effective technology assets.

When migrating to the cloud, however, many large enterprises struggle to realize business value quickly, enforce standardization, generate cost savings, and build the necessary capabilities. They also may encounter difficulties in moving beyond the pilot phase to achieve scale.

For example, many large organizations have found that the IT staff leads cloud initiatives without sufficient attention to business functionality. The companies subsequently generate limited incremental business value. As another example, a large industrial goods manufacturer moved its IT systems to the cloud without hiring people with the necessary cloud operations expertise or training current staff. The company was then dependent on IT vendors to manage the systems. Finally, some companies have operated IT systems in their own data centers and in the cloud, only to find that they spend more money for less reliable service.

BCG’s experience suggests that there are six simple steps that large enterprises should take to reduce risk and increase IT and business benefits.

1. Define a Cloud Strategy That Delivers Business Value and Drives IT Change

The IT organization should focus on delivering value to business customers rather than on building and managing bespoke IT systems. BCG’s experience suggests that large enterprises can deliver the most value by building their cloud strategy around four common use cases:

• An Advanced Analytics Platform. Many large enterprises have spent several years trying to build big data infrastructure in-house, with limited success. In contrast, others have found that the platform as a service (PaaS) options of cloud vendors (such as Google’s Spanner, DataProc, and Big Query) are economical ways to acquire advanced analytics capabilities, clean up and curate existing data sources, and establish effective data management.
• New Digital Systems. The default choice for new IT systems should be the cloud. Most IT departments cannot compete with cloud vendors and their advanced tools and automation capabilities. Companies can also take advantage of the hyperscale infrastructure of these vendors.
• External Websites and Collaboration Platforms. Almost without exception, the cloud should be the home for enterprises’ external websites and collaboration platforms, such as email and messaging. In-house options rarely make sense in terms of cost or flexibility.
• The Migration of Newer IT Systems. Although certain legacy systems may never be migrated to the cloud for either technology or regulatory reasons, enterprises should try to move newer systems. This generally happens in stages. The systems are initially simplified and modernized in-house before they are ported to the cloud as native apps. The migration does not have to be wholesale.

It is important for senior IT and business leaders to clearly articulate that the cloud will be the preferred home for enterprise IT systems. This message can be a powerful rallying cry for change and help ensure that the cloud does not become just another set of services in the IT infrastructure mix.

There, of course, will be exceptions to this broad-brush strategy. Financial institutions, for example, generally face greater regulatory scrutiny, as do oil and gas companies in some countries. In those instances, enterprises may need to retain data rather than expose it to the cloud. Alternatively, many financial institutions will rely on the cloud but still host golden copies of customer data internally.

2. Identify the Right Vendors and Their Scope

Enterprises should exercise care in selecting vendors for initial use cases because they will likely play an ongoing role. Choosing vendors requires analyzing the tradeoffs between having access to the advanced technologies of specific cloud vendors and avoiding vendor lock-in by encapsulating applications and services in containers using Dockers and Kubernetes.

For example, a global bank chose Google Cloud as its single cloud solution for data and advanced analytics on the basis of its assessment of Google’s expertise with artificial intelligence (AI) and machine learning and Google’s willingness to share innovations with the open source community. In contrast, another bank chose both AWS and Microsoft Azure to host its back-end systems to avoid vendor lock-in.

As the vendor with the largest market share, AWS is often the default choice for many enterprises, especially when they are selecting an infrastructure as a service (IaaS) platform. Google Cloud and Azure have sought to catch up to AWS on IaaS capabilities and set themselves apart on their PaaS and software as a service (SaaS) offerings.

For example, in addition to AI and machine learning, Google is promoting its advanced data analytics capabilities. Cloud Spanner is a globally distributed database that combines the structure and consistency of traditional databases with fast scalability. Meanwhile, TensorFlow has become the de facto standard library of machine-learning software. Google’s embrace of open source also assures customers that they will not be locked in.

In contrast, Azure builds on traditional Microsoft enterprise applications, such as Office 365, and their tight integration with Active Directory to manage user permissions. Microsoft also eases migration by packaging DevOps tools into Azure and offering superior customer support for migration—25,000 employees work in its global cloud-consulting business.

Traditional IT infrastructure vendors will continue to play key roles in hosting data centers and building and managing on-premise private clouds for large enterprises that want to avoid public clouds, often for regulatory reasons. Meanwhile, vendors such as Rackspace will offer value-added services for on-premise private clouds of midsize enterprises. Large enterprises are also likely to rely on these relationships as they wind down their IT platforms before moving them to the cloud.

Increasingly, however, the public-cloud vendors are making inroads with on-premise offerings, such as AWS Code Deploy, Azure Stack, and GKE On-Prem from Google Cloud. These services combine the advanced tools and technologies of the respective public-cloud platforms with the network isolation and control of on-premise solutions.

In their desire to acquire best-of-breed solutions, enterprises need to be careful about managing multiple cloud environments. Networking costs can rise significantly if systems need to communicate frequently across multiple clouds and data centers. When that happens, the enterprise may want to migrate the entire cluster to the same cloud to avoid additional networking and cyber-security risks.

3. Shift the Focus of the IT Organization

A successful journey to the cloud requires the IT staff to concentrate on oversight of the cloud and vendors in five key areas:

• Advisory Services, covering advice on the design of new cloud application services, the design guidelines, and a self-service catalogue of production IaaS and PaaS options
• Architecture, covering the selection of cloud providers, the design of development and production environments for cloud services, the introduction of new services, the automation of deployment, and scripting
• Overall Management, covering, among other responsibilities, service and configuration, cost, chargeback, reporting, and licensing
• Security, Identity, Network, and Access Management, covering cloud and on-premise data center connectivity, security services, detection and prevention controls, and logging
• Operations, Service, and Incident Management, covering automated end-to-end performance and security monitoring, troubleshooting, and communications with vendors’ product engineering support staff

Expertise in these areas is scarce at most vendors but especially within large enterprises. While training staff, organizations will need to rely on external resources—buying the necessary expertise and borrowing talent from vendors for temporary assignments. Enterprises may also need to improve the incentives they offer—including their compensation and work environments—to attract cloud expertise. For example, a UK bank calculated that it may need to raise the salaries of certain positions by 50% to 80% to lure cloud talent.

4. Enforce Clear Architectural Principles, with a Bias for Standardization

Clear technical design principles should guide the migration of legacy systems to the cloud and the creation of new systems. Letting a thousand flowers bloom is not a good idea.

• Ring-fence existing data centers, and redirect all new investments to either external or hosted clouds in order to contain the growth and complexity of existing technology platforms.
• Fully automate IT delivery using infrastructure as code and iterative, fast-feedback approaches, such as agile and DevOps.
• Embrace loosely coupled architectures by insisting on full compliance with API policies; move away from monolithic legacy systems to a smaller set of cloud-ready standard infrastructure patterns.
• Require all software to be resilient, fault tolerant, scalable, and infrastructure agnostic.
• Focus on data security, and use the migration to clean up and curate existing data sources, codify insights, and establish effective data management.

Discipline will determine whether the migration leads to a more responsive and agile IT environment. Complexity and costs could increase on a private or public cloud if an enterprise merely replicates legacy IT architecture that is designed for traditional standalone servers and attempts to ensure full backward compatibility with older systems. For example, unless internal business and IT teams first simplify and standardize their IT systems, large enterprises are unlikely to reduce IT costs by building on-premise private-cloud infrastructure. As we discuss in greater detail in the next article, IT architecture design boards and security review processes can help enforce design principles without slowing cloud adoption.

5. Scrutinize the IT Landscape for Initial Migration Candidates

Existing business applications hosted in enterprise data centers or by outsourcing vendors should first be assessed through three filters:

• Applications That Are to Be Decommissioned. These should be excluded from the migration and typically outsourced to IT partners to run down.
• The Remaining Applications. These should be evaluated on the basis of whether they are already being deployed as a SaaS offering or can be provided as one by vendors.
• Applications Without a Ready SaaS Solution. These should be run through various tests to determine technical constraints, including performance and compliance requirements and migration complexity. This exercise identifies three types of applications: those that are cloud-ready or that can be adapted to the cloud; legacy applications that can be refactored to move to the cloud; and legacy applications that are not suitable for the cloud because they are built on monolithic legacy architecture, the business risk is too high, or cloud solutions are unavailable.

This review can typically be completed using automated tools from cloud providers or third-party vendors such as Cast.

Short-lived environments, such as those for development and testing, are generally moved to the cloud first because they benefit both from lower unit costs and pay-for-use pricing. Backup storage is often next. The lower unit costs of such services as Google’s Coldline, Amazon S3 Glacier, or Azure Blob storage are generally compelling. In some cases, the move enables enterprises to streamline backup and archival policies and reduce the number of backups.

Applications without a ready SaaS solution can continue to be hosted in enterprise data centers, lifted and shifted to a vendor’s data centers, or hosted by an IaaS provider while a migration plan is put in place. Each move to the cloud should have a sequence and timeline and a dedicated effort to simplify and modularize the application architecture. In one example of such progressive modularization, BBVA is using the cloud to offload transactions from the mainframe, thereby reducing consumption costs.

For systems that are not cloud ready, it is important to watch out for specific technical, licensing, or contractual constraints. For example, an industrial goods company that uses an SAP enterprise resource planning system with underlying Oracle databases is migrating all but the trickiest databases to SAP Hana and SAP SQL Anywhere on the cloud; the remaining databases will be hosted on Oracle Cloud as part of a commercial deal that also includes Hyperion and other Oracle products.

6. Industrialize the Transformation and Migrate in Phases

For systems that either are cloud ready or can be made cloud ready, an industrialized approach can enable a 10% to 50% reduction in migration effort, depending on the technology stack, technical constraints, and migration volume.

A multidisciplinary cloud competency center—with cloud architects, infrastructure automation engineers, cyber-security experts, and business and finance representatives—typically oversees this industrialization. (See Exhibit 1.) 

The center generally relies on standard cloud design archetypes and migration patterns, designs the automation, and sets up migration factories for different system types, such as front-end web applications, management information systems, and reporting applications. Most enterprises rely on three broad types of cloud migration approaches. (See Exhibit 2.)

Lift and Shift. This approach typically applies to hosted applications, where an existing virtual machine is moved to a cloud IaaS without much modification. This option requires the least effort, but it also has the least benefits, because IT teams are still required to manage, patch, and upgrade these IT systems on the cloud; often, the designs of these systems are also unable to efficiently use IT resources that are available on the cloud.

Move and Improve. In this approach, the system generally needs some adaptations, typically to messaging middleware, to move to the cloud.

Transform. This approach delivers the most benefit, but it also requires the most money and work because existing applications need to be refactored to run on a PaaS, typically in portable containers such as Docker and Kubernetes. Compute and storage are also separated to optimize benefits from cloud.

In practice, most enterprises mix and match these approaches. While a full lift-and-shift approach is generally impractical, it is a helpful baseline to measure benefits and costs. In contrast, a full transformation provides the most benefits but may offer diminishing returns if more than half of the applications are being refactored. Typically, enterprises may begin to see diminishing returns when more than half of their applications must be refactored.

To test proofs of concept, enterprises can pilot each of the three migration approaches with low-risk IT systems. Early lighthouse projects use a mix of two or three simple and complex applications for each type of system. These pilots help to identify specific technical constraints, tune automated development and deployment pipelines, and develop detailed business cases for each cluster of applications.

With insights from these pilots, enterprises should create a migration factory, which essentially industrializes the process by relying on standard architecture design patterns and automated testing and packaging of code. When the approach and automation is in place, the initial factory can be scaled up and new factories can be established. (See Exhibit 3.)

Many large enterprises have a large proportion of fixed costs associated with operating their own data centers. In these cases, a “parking lot” strategy may help save money. For example, a large manufacturing enterprise parked a bulk of its applications in an IaaS environment to avoid the cost of refurbishing their data centers. Subsequently, the company transformed those applications to a PaaS over several years. Even for enterprises with efficient data centers, this strategy may make sense—typically when the remaining fixed costs for a data center are 60% to 75% of total remaining enterprise IT costs.  

The journey to the cloud can take from three to five years for most large enterprises. It depends on the size and complexity of the existing IT landscape, the appetite for change, funding, and unforeseen market and regulatory changes. That may be a long time, but it’s better than the alternative. Enterprises that take a haphazard approach will achieve haphazard results that ultimately undermine the business case for moving to the cloud.

The cloud offers tangible and quantifiable value. Enterprises can start to realize this value early by following the define, identify, shift, enforce, scrutinize, and industrialize steps that are outlined above. The steps may not be a stairway to heaven, but they’re a practical and effective approach to complete a journey to the cloud.