Migrating Applications to the Cloud

Chapter 1. The Cloud and Business Transformation

This leads us to one of the less obvious facts about on-premises-to-cloud migration, especially with respect to the task of migrating custom-built business applications: the goal of migration is not just to move these apps to the cloud but to transform the organization and its operations. To say this, however, is to put the proverbial cart before the horse; in order to transform the business and its operations, organizations must sometimes transform not only their applications and software architectures (e.g., by shifting apps, services, and their workloads into the cloud) but their custom-built apps and services, too. (In Chapter 5 and the Conclusion, this book addresses the different kinds of transformations—from refactoring or redesigning apps and services to scrapping and rebuilding them from scratch—that an on-premises-to-cloud migration may entail.)

It is necessary to unpack this idea in order to identify a few of the ways in which cloud migration can improve and transform an organization.

In the first place, the migration process gives the organization a chance to address problems with its software infrastructure and with the business functional areas, business processes, and workflows that this infrastructure supports. Maybe the organization is hitting a wall with respect to the capacity limits imposed by its on-premises IT resources. Maybe it is hamstrung in its ability to pursue new business opportunities by the crippling balance of its technical debt. Cloud migration does not magically fix these problems; however, it gives an organization a long-overdue opportunity to address them.

In the second place, the cloud is not just a means of driving down costs or of fixing problems, but of transforming IT operations—and, in the process, transforming business operations, too. The migration process gives business and IT stakeholders an opportunity to talk about what is new, different, and advantageous about the cloud. For example, what business benefits should the organization expect to realize by relocating its business applications to the cloud? How do cloud features such as elasticity, redundancy, security, and the ability to rapidly provision new resources translate into business benefits? What new types of use cases, practices, and users can the business enfranchise by migrating applications to the cloud? The logistics of the cloud open up new opportunities for exposing business functions to customers, partners, suppliers, and other consumers; the cloud’s colocality with useful machine learning (ML), artificial intelligence (AI), automated security, data integration, software development, and other services makes it easier for developers to incorporate advanced features into the apps and services they build.

The combination of these benefits makes it possible for the business to develop new products and services, pursue new initiatives, firm up new kinds of partnerships, and pursue other new opportunities for innovation.

This ebook will explore not only the what and how of migrating business applications to the cloud but, most importantly, the why. Enterprises are under enormous pressure to do something strategic about cloud migration. The early cloud use cases—which tended to take the form of tactical migrations, with an emphasis on reducing or eliminating especially costly apps or services—have played out. The priority now is to develop a rational, prospective, purposeful cloud migration strategy; to balance and rationalize investments in cloud infrastructure over and against investments in on-premises infrastructure, and to hash out a strategy in which the cloud—be it the on-premises private cloud, the hyperscale public cloud, the public cloud marketplace, or (a recent innovation) the on-premises public-private cloud—is at least on equal footing with traditional on-premises IT infrastructure.

It is likely that most cloud migration strategies will privilege cloud infrastructure (in one or more of its forms) over and against conventional on-premises IT infrastructure. But the goals, priorities, and content of each of these strategies—the why—are and will continue to be wholly unique to each organization. It is up to each organization itself to determine the why of cloud migration. This ebook is a resource that would-be migrators can use to formulate their own answers to this question.

Plain Truth About Cloud Migration

Cloud migration is not and probably cannot be a turnkey process; nothing worthwhile ever is.

Homogeneous migrations that entail like-for-like deployments in both the on-premises data center and the cloud are more straightforward than heterogeneous migrations; migrating from Vendor X’s packaged enterprise resource planning (ERP) suite to its equivalent cloud service is akin to “lifting and shifting” application and user data from the on-premises environment to the cloud. In such cases, it is usually sufficient to refactor custom-built business apps and services while continuing to use the same packaged application.

On the other hand, replatforming (i.e., migrating from Vendor X’s ERP suite to Vendor Z’s cloud ERP service) is usually more complicated. Customers should expect to redesign—or to rebuild from scratch—custom-built apps, or (alternatively, but not ideal) to create new services that facilitate interoperability between these legacy assets and the new cloud architecture.

The good news is that cloud vendors have a demonstrable interest in facilitating heterogeneous migration scenarios. In practice, cloud vendors offer partially automated tools and services, along with packaged consulting services, that aim to simplify heterogeneous migrations.

This is the good news. The bad news is that not all custom-built applications are designed to integrate and interoperate with packaged ERP suites. In very large organizations, some applications—usually older apps—may have been written in obsolete languages. They might consume data from applications and services that run on mainframes, proprietary systems, and other long-lived platforms. Another complication is that these applications are usually, but not always, written to frameworks and software development kits (SDKs) that have been provided by the software vendors from which the organization licensed its suites. These frameworks and SDKs depend on middleware components (application servers and application- or function-specific databases) that are likewise supported and/or developed by that same vendor.

These applications must “migrate,” too—even if they do not actually move to the cloud. Migration is as much a process of facilitating coexistence between software that lives in the on-premises environment and software that lives in the (public or private) cloud as it is of moving applications and data to the cloud. The irrefragable fact is that a portion of IT infrastructure will remain in the on-premises data center. Some IT infrastructure will be instantiated in conventional nonvirtualized systems, some in enterprise private clouds, and some in public-private clouds. Cloud migration must accommodate these resources, too. This entails managing not only service dependencies across both contexts, but also managing and enforcing information security policies and security dependencies. (As we’ll see, hybrid cloud implementations pose unique security implications of their own.) It likewise involves managing and enforcing consistent data management, data governance, data retention, and other policies.

To get a sense of everything involved here, let’s look more closely at the enterprise software stack.

Minimizing Your Technical Debt

If you imagine that an enterprise software stack comprises a kind of archaeological site, with different objects located at different strata that correspond to different (more or less disruptive) technological shifts over time, you have a feel for what application migration entails: the deeper the IT archaeologist digs, the less familiar the objects they encounter. As they dig their way down to the mainframe systems that constitute the ground floor of the enterprise and its IT history, they are increasingly likely to encounter strange hacks (called “kludges”) and accumulations of software detritus (called “cruft”).

Collectively, these artifacts comprise the technical debt of the organization. Each year, organizations allocate huge portions of their IT budgets—upwards of 50%—to pay down the interest on this debt.¹ Cloud migration is an opportunity to pay down, permanently, at least some of the principal on this debt.

The good news is that cloud providers have devoted a great deal of time and effort to addressing these and similar issues. For example, all providers that market integrated on-premises ERP-like applications suites also market these same suites—or, rather, their equivalents—as cloud services. And most of these providers offer features (for example, service- or platform-specific SDKs or frameworks) and expose functions that subscribers can use to transplant their custom-built, on-premises apps into the cloud context. Some third-party vendors also offer cloud-migration services; some of them are well-known purveyors of enterprise software, some are upstart cloud-first players.

Corralling Security Risk

In the on-premises environment, organizations have a responsibility to safeguard the integrity and consistency of their applications and data. They need to be careful about how they store sensitive data, not only to protect against possible data breaches but to comply with applicable data privacy laws.

Relatedly, organizations have a responsibility to comply with complicated data retention and data deletion statutes and regulations that vary across regions, political unions, and even states within countries. Lastly, organizations need to be able to safeguard access to their physical assets—not just server, storage, and network hardware, but the business campus (with its buildings, doors, windows, etc.), too.

In the cloud, many of these requirements either go away or are transformed in ways both subtle and substantive. Cloud providers encrypt all data by default, a practice that is not consistently applied in the on-premises enterprise. Similarly, a cloud best practice is to isolate sensitive from nonsensitive data—another practice that is inconsistently applied in the on-premises enterprise. Cloud database, data integration, data quality, identity and access management, encryption, and similar services incorporate built-in mechanisms for enforcing data governance between and among disparate regions, countries, states within countries, political unions, etc. And once applications and data move to a cloud service, the subscriber is no longer on the hook for securing the underlying hardware and software resources. This responsibility devolves to the cloud provider.

The On-Premises Capacity Conundrum

Scalability is always constrained in the on-premises environment by hard constraints that are less a function of the limitations of physical hardware—in almost all cases, nonvirtualized on-premises hardware is more performant than virtualized cloud resources—but of practical limitations with respect to data center floor space, the density of hardware resources (a maximum number of servers and storage arrays), and, most importantly, IT budget dollars. The upshot is that few organizations have a limitless pool of resources upon which to draw to support applications and workloads, to say nothing of the (ever-increasing) data volumes associated with them.

Cloud resources, by contrast, are virtually inexhaustible; in most cases, for most workloads, subscribers can cost-effectively provision cloud resources to easily exceed the performance of their on-premises environments—with headroom for expansion to accommodate aperiodic spikes in demand. This last point is critical. Vanishingly few organizations are able to respond to drastically changing conditions or unexpected changes in demand by turning on (or rapidly purchasing, configuring, and provisioning) sufficient on-premises compute, storage, and network resources. Converged infrastructure helps in this regard, but, confronted with massive spikes in demand or—just as important—with rebound effects such as the Jevons paradox, it is also insufficient.

To the extent that organizations purchase extra on-premises capacity, they usually do so for two reasons: first, as a means to provision (or augment) existing server, storage, and other sorts of resource pools; or, second, as a hedge against expected future growth. In extreme cases, however, massive aperiodic spikes in demand could easily outstrip the capacity of pooled converged resources. (Many organizations experienced sustained spikes in demand during the recent pandemic event.) Another problem, which contributes to the first, is the Jevons paradox; that is, the tendency for demand to increase in lockstep with an expansion of capacity or as a result of improvements in efficiency. If roads and highways are good examples of this, so, too, is IT infrastructure.

The economics of cloud obviate these concerns. For one thing, providers (not subscribers) are responsible for purchasing, operating, and maintaining cloud infrastructure resources. For another, the cloud leasing model permits subscribers to deduct the total amount of cloud spending for the fiscal year in which it occurs. Conversely, in almost all cases, an organization must depreciate or amortize the cost of its on-premises IT resources over a period of several years.

Most importantly, the cloud permits a resource elasticity that simply has no analogue in the on-premises environment. If a subscriber requires additional capacity, it can rapidly spin up resources in the cloud environment. Another critical difference is that, in the on-premises enterprise, acquiring additional capacity means acquiring some fixed amount of compute, memory, storage, and network resources.

In the cloud, by contrast, virtual resources can scale independently of one another. Best of all, resources in the cloud can be turned on and off—or paused and resumed—as needed. Some cloud providers charge subscribers only for the capacity that they actually use when they use it.

This is a radical departure from the status quo in the on-premises data center. That being said, all departures have costs and benefits, and cloud migration is no different. Before we explore these costs and benefits in detail, it is necessary to clarify what cloud migration is. What does it mean to “migrate” an application, service, or (even) business process to the cloud? For example, has an application or service “migrated” even if, the data or services it depends on continue to live in the on-premises data center? The next chapter explores these and other related questions.

¹ See CEB Consulting, Key Findings from the IT Budget Benchmark: 2015–2016, 2015, 17. CEB found that IT spending on maintenance declined from 63% in 2011 to 57% in both 2014 and 2015. As maintenance costs decreased in 2014 and 2015, CEB showed organizations allocating a slightly larger share of IT spending (33% in both years, as against 32% or less from 2011–2013) to “business opportunity and innovation.” (2016 is the last year for which CEB provided data; it was acquired by Gartner Inc. in 2017.) A useful comparison is the US government, which in 2019 allocated fully 80% of its IT budget to “Operations and Maintenance.” (A large chunk of this spending was used to support and maintain legacy systems.) In other words, only about 20% of federal IT spend was directed to what budget analysts described as “Development, Modernization, and Enhancement.” See US Government Publishing Office, Efficient, Effective, Accountable: An American Budget—Analytical Perspectives, February 2018, 223, for more information.