Migrating Applications to the Cloud

Chapter 4. Building a Business Case for Cloud

The inconvenient truth about cloud resources is that they are inexpensive… until they are not. A large organization that fails to properly anticipate the resources its applications will consume in the public cloud could incur significant monthly charges. This is not just a problem of resources running wild in the hyperscale public cloud. Rather, it stems from an essential difference between the way software performs in the public cloud as distinct to the on-premises data center. As a general rule, software that runs in the public cloud usually requires more resources to perform the same operations than software running in on-premises systems. The good news is that the economics of the cloud model make it possible—and, for many purposes, cost-effective—to solve most, but not all, scaling problems.

Estimating Costs

Cloud service providers offer different kinds of fixed-pricing models. The basic rule is that they charge customers a predetermined price for cloud resources, sometimes for the duration of a lease period, sometimes on a rolling basis (i.e., per minute, hour, day, week, etc., of use).

So far, so good. But different cloud providers offer different types of fixed-price leases, and some fixed-pricing models are more favorable to certain use cases than others.

For example, some cloud providers offer a subscription pricing option in which customers are charged for a definite reserved amount of compute and storage capacity. (Note: This fixed price typically does not include region-to-region data transfer costs or outbound data transfers that leave the provider’s cloud infrastructure.) So an IaaS subscriber that reserves 32 virtual servers and a total of 100TB of cloud storage pays a fixed monthly fee for this capacity, regardless of whether it uses all of it. This subscriber must pay a per-GB fee for outbound data transfer, too. Or a PaaS database subscriber pays for a definite reserved amount of compute power and a definite reserved amount of storage. The benefit to the customer is that costs are predictable and—over a long enough lease period—comparatively low. The caveats are obvious, however; the customer must have a high level of trust in the cloud provider as well as an excellent understanding of the IT resources it will require in the cloud.

Some cloud infrastructure providers charge strictly on the basis of usage. To refer to the earlier example, rather than the subscriber leasing a definite fixed amount of capacity at all times (that is, 32 virtual servers and 100TB of cloud storage), it pays only for the capacity it actually uses during the time period that it uses it. In all hosting regions, subscribers will pay more for cloud capacity during the business workday than at night, for example, because they use fewer resources (and so are charged less) after hours. The advantage of usage-based pricing is that subscribers pay only for what they use; the drawback is that usage-based pricing is typically more expensive than subscription pricing. In usage-based pricing schemes, too, subscribers pay a fixed price for outbound data transfer costs.

These are high-level descriptions that mask a great deal of variation and complexity. For example, most hyperscale providers also charge for cloud capacity on a per-service basis: a customer signs up for a relational database service, along with data warehouse, general-purpose compute, general purpose storage, and one or more cloud data integration services. Each of these is exposed (and billed) as a distinct service; each has its own fixed (per-minute, per-hour, per-month) charge. And, again, all providers charge more for data egress than ingress. The problem is that egress charges can be especially difficult to anticipate and/or account for in budgeting. Some subscribers will be surprised if/when the cost of a cloud service exceeds their initial projections. In such cases, data egress charges are often a material contributing factor.

Planning the Migration

An important consideration is that core ERP, SCM, HR, and CRM systems support critical business processes. As we have seen, common business processes layer over and consume functionality from these systems. The upshot is that to move some or all of these systems to the IaaS or PaaS cloud is to impact the business processes that depend on them. It is essential, then, that the migration plan accounts for this impact. In this sense, on-premises-to-cloud migration is not just an IT-driven exercise but, rather, requires organization-wide alignment. The organization must develop and formalize a detailed migration plan to avoid business disruption.

Having said this, migrating packaged business applications from the on-premises data center to a cloud service can be a relatively straightforward process; at a bare minimum, the subscriber rehosts—or lifts and shifts—the application and user data associated with these applications to the cloud environment.

This description elides an enormous amount of complexity, however. As noted, most organizations prefer to custom-build business applications that run on top of an ERP, SCM, HR, or other system and its constitutive application modules. For example, a custom-built sales application might exploit functions that are exposed by the ERP system’s finance modules. Or a custom-built inventory application might consume functions exposed by the ERP system’s finance and sales/marketing modules, as well as consume core functionality provided by a separate SCM system. Another example is a custom application that an employee can use to schedule time off, schedule half-days, or—depending on the organization—adjust their work schedule. These custom-built applications are typically designed to do specific things. To cite a few common use cases, an organization might design custom-built apps in order to extend the capabilities of the core ERP, SCM, HR, or other system’s functional areas, or to provide functions that are tailored to a specific business process in a specific organization. Some of these custom-built apps are relatively new, while some are a decade or even two decades old. Is the process of migrating custom-built applications relatively straightforward, too? Is it as simple as lifting and shifting them, too? The simple and unequivocal answer is: it depends.

Prioritizing the Applications and Data to Migrate to the Cloud

Organizations must identify and prioritize candidate applications and/or workloads for cloud migration, as well as determine how rehosting or moving applications and data to the cloud will impact critical business processes and their associated workflows. But they must also determine what, if anything, needs to be done to these apps to permit them to thrive in the cloud.

Along with this, there are several different tactical approaches to cloud migration. These are:

Rehost

Moving application and user data as-is from the on-premises data center to the cloud.

Replatform

Adapting applications to thrive in the cloud.

Refactor

Reengineering applications to scale better, behave more reliably, and improve security in the cloud environment. Some proportion of an organization’s custom-built applications will need to be refactored to behave as expected in the cloud.

Rebuild

Redesigning and rewriting applications from scratch.

Replace

Some on-premises applications perform functions that are provided by cloud services. It is a safe bet these cloud services are better (more scalable, reliable, and secure) than custom-built apps.

Chapter 5 will explore the challenges involved in refactoring, rebuilding, and replacing applications.

Migration Strategies: Rehosting

Rehosting, otherwise known as lifting and shifting, is straightforward enough: the organization transplants its existing applications and data to the cloud environment. On-premises applications are either virtualized in the IaaS cloud or exposed as SaaS and/or PaaS cloud services. On-premises data is either replicated in virtual databases in the IaaS cloud or exposed via a PaaS cloud service. On-premises storage is configured in different ways: first by reduplicating direct-attached and network storage (such as SAN and NAS) resources, and second by re-creating on-premises network storage, such as NFS and SMB shares, object storage, etc. It is usually practicable to lift and shift a specific vendor’s packaged ERP suite from the on-premises environment to that same vendor’s cloud service. This is the fastest and most direct route to migrate an on-premises ERP suite to the cloud. What’s more, the vendors who develop and maintain these suites usually offer quasi-automated tools and an assortment of migration options, including the on-premises public-private cloud, traffic-prioritized VPN connections between the on-premises environment and the cloud, consulting assessment and migration services, etc. On-premises-to-cloud migration is a hugely disruptive change in this market, with the result that vendors are anxious to retain their existing customers—as well as to poach customers from competitors. This is why most also offer tools, services, and consulting to encourage users of competitive ERP suites to migrate to their cloud services.

Operational applications (i.e., business applications) do not typically generate extremely large data volumes. For this reason, most subscribers will opt to transfer application and user data over the public internet to the cloud environment. Cloud providers offer several options to accelerate this process. For example, some offer secure, traffic-prioritized connectivity between their cloud “edge” locations and the customer’s on-premises data center. Some also bundle this connectivity with best-in-class data replication and data synchronization tools.¹ These technologies feature data connectors that are optimized for different kinds of ERP suites, databases, messaging middleware, mainframe data sources, and a range of vertical-specific data sources. By using a combination of data replication and data synchronization, subscribers can replicate on-premises application and user data to the cloud, as well as synchronize cloud and on-premises resources on an ongoing basis. This ensures the integrity of critical business data along with the continuity of business operations.

Rehosting is the fastest and, notionally, the most direct method of moving on-premises software and data to the cloud. Because of the issues discussed above, organizations usually combine rehosting with other methods, such as replatforming, refactoring, and, in some cases, redesigning software. It is worth emphasizing that the decision to refactor or redesign software is not contingent on a decision to rehost. After all, some custom-built applications will move to the cloud without modification of any kind.

Migration Strategies: Replatforming

Replatforming describes the process of adapting applications to exploit new features, functions, etc., that are specific to the cloud. Replatforming is not a cloud-only play, however. Software that stays in the on-premises data center could benefit from replatforming, too; it can invoke cloud features or functions, exchange data with cloud services, call event-driven cloud services, persist data to cloud storage, and so on. Replatforming is something to think about in connection with all applications, regardless of whether or not they actually move to a cloud context.

Replatforming is an opportunity to make the most of cloud migration. Think of an online sales app that schedules the creation and fulfillment of a web order by invoking functions across different systems that correspond to different business functional areas—sales and marketing, finance, inventory, shipping, etc. This app might likewise make calls to external services (i.e., services exposed by credit-scoring agencies, suppliers and resellers, shipping companies, etc.). In some cases, the app itself might have been written when these external services either did not exist or were not yet exposed as RESTful services. So developers built applications or services that implemented these functions.

In the cloud, external services are complemented by services that either reduplicate most of the functions that applications require (e.g., authentication services, certain kinds of data transformations) or extend this functionality in useful ways. For example, in fulfilling a new sales order, the organization might need to determine if it should offer financing to a customer, especially a new one. This is an analytic question, one that—in the on-premises environment—might be answered by calling an external service to perform a credit check and triggering a stored procedure that runs one or more analytic models in a data warehouse. It is possible to replicate this scheme in the cloud, but it is likewise possible to extend it in useful ways by, for example, invoking an ML service. The colocality of resources in the cloud makes it easier to perform other useful analytic-driven actions at the same time; not just name, address, and payment verification, but also fraud detection and product upsell or cross-sell. If the application is redesigned to expose a RESTful interface, it becomes easier to exchange data with other cloud resources, including partner or supplier systems, third-party resellers, etc.

Migration Strategies: The On-Premises Public-Private Cloud

Cloud infrastructure software uses virtualization to decouple hardware resources from one another. This is a condition of the possibility for the elasticity (i.e., the ability to start or stop, scale up or scale down resources as needed) that is the cloud model’s defining characteristic.

But virtual resources in the public cloud are nonlocal with one another, too; virtual CPUs and other virtually instantiated hardware resources communicate with one another over network transport, not via local computer buses. So, too, do applications and services. In most cases, the virtual “disks” that a virtual server reads data from and writes data to are actually implemented in object storage. In all cases, network transport comprises the biggest bottleneck in the public cloud. Sometimes, for especially demanding applications, this bottleneck is just too constraining.

This is one of the problems that the on-premises public-private cloud aims to address. For event-driven and other types of low-latency applications, performance in the on-premises private cloud may be indistinguishable from that of the on-premises data center. It could, notionally, be better.

The on-premises public-private cloud has other useful applications, too. For one thing, it gives enterprises a viable option for realizing the benefits of cloud in connection with sensitive applications and data that they are unable (or unwilling) to move to the cloud. One benefit of cloud migration is that subscribers are no longer responsible for servicing, maintaining, and upgrading on-premises hardware and software. Another is that cloud subscription services are recorded as OpEx, not CapEx. The on-premises public-private cloud delivers on both of these benefits. The cloud infrastructure provider owns and manages the hardware. If necessary or applicable, it services, replaces, or upgrades this hardware. It exposes the same ease-of-use and ease-of-configuration facilities and wizards in its public-private cloud systems as in its public cloud infrastructure software.

Migrating Packaged Business Applications

The easiest applications to migrate to the cloud are packaged business applications, such as those integrated into an ERP suite. These include:

Financial applications

In large enterprises, accounting and financial management functions are usually provided by a “module” exposed as part of an ERP-like ERP suite. This module also supports the workflows and business processes associated with these functional areas.

The cloud is already a popular destination for financial applications—and for ERP-like suites in general.² For one thing, financial applications that move to a cloud service benefit from ML, AI, data transformation, and other colocal services. For another, most cloud ERP-like suites now integrate planning and forecasting capabilities into their finance modules, too.

Human resource information system (HRIS)

In large enterprises, human capital management functions are performed by an HR module that lives in an ERP-like ERP suite. HR systems contain highly sensitive data: the names and social security numbers of employees and their dependents, as well as information about employee salaries, work visas, and sometimes pertinent medical information, too. Even though there usually is no regulatory or statutory reason restricting an HRIS system to the on-premises environment, some organizations prefer to keep it in place.

That said, the cloud is already a popular destination for HRIS applications—a trend that should accelerate over the coming years as companies embed ML and AI services into HR functions.³

Customer relationship management (CRM)

CRM was one of the first applications to take off in the cloud, and CRM remains a popular SaaS and PaaS cloud offering. Many large businesses already host their core CRM functions in a cloud service of some kind; however, according to market watcher Gartner Inc., cloud CRM spending accounted for just 20.4% of overall CRM spending in 2019.⁴ The upshot is that a clear majority of organizations still own and operate on-premises CRM systems.

All ERP suite vendors offer cloud PaaS suites that are at least equivalent to their on-premises ERP suites. But the cloud teems with cloud-first ERP service providers, too, the majority of which also offer ERP PaaS offerings. The thing is, ERP systems are notoriously difficult to configure and, in some cases, onerous to change. Cloud migration does not magically fix this, and this has implications for migrating custom business applications, which is addressed in the next section.

In general, homogeneous (like-to-like) migrations are more direct than heterogeneous (like-to-unlike) migrations. This is certainly the case if migrating from physical on-premises infrastructure to the virtual IaaS cloud. But cloud providers, both established ERP-like suite vendors and upstart providers, are especially keen to entice users of on-premises ERP-like suites to migrate to their PaaS offerings.

The upshot is that the average ERP-like PaaS provider offers migration tools, features, and services; some even partner with regional and national services firms to offer consulting engagements of one kind or another. However, large cloud providers are able to offer features (e.g., on-premises public-private cloud configurations) that are beyond the reach of most upstarts. In any case, customers should critically evaluate all migration tools, features, services, etc.

Migrating Low-Latency Applications

As a general rule, application performance is inversely related to latency; the lower the latency, the better the performance of the application. In this context, “latency” is an expression of the amount of time it takes for a program to exchange messages (data) with another program.

Latency is not necessarily a function of (higher or lower) data throughput but, rather, of faster or slower input/output performance (in this context, a low-latency application is able to rapidly exchange messages with other applications) and of consistent message delivery. Some applications in specific verticals—finance and telecommunications, for example—have extremely demanding latency requirements. Certain kinds of mainframe applications (some of which are also used in the finance and telco low-latency use cases) likewise have extremely demanding latency requirements, as do a subset of decision-support workloads—for example, those associated with real-time data processing.

Organizations will find it challenging to migrate these applications to the cloud—assuming (with respect to applications that live in mainframes and to proprietary telco systems) that it is even possible to move them. But other types of applications, especially event-driven applications, tend to perform better and more reliably in low-latency contexts, too. This does not mean, however, that they must remain in the on-premises environment—or, more precisely, that these applications cannot move to a cloud context of some kind. In the public cloud, hyperscale providers usually offer different kinds of low-latency options that may (or may not) suit the requirements of a specific application. Again, a growing number of cloud providers now offer on-premises versions of their cloud services, making it possible for an organization to deploy public-private cloud services in its own data center. Not all providers offer this option, and those that do tend to use dissimilar product names to describe the on-premises public-private cloud, but the concept is that of a hardware and software combination that is owned and managed by the provider but that is installed in the customer’s own data center.

Another option for latency-sensitive applications is a cloud-based high-performance computing (HPC) service, which typically offers comparatively low-latencies (priced at a premium) relative to standard cloud services. Most hyperscale providers offer HPC services, but PaaS HPC offerings are available, too. These services are nominally designed for scientific computing—their métier is parallel processing on massive data sets—and are normally used to support demanding applications in specific verticals, including oil and gas, financial services, and pharmaceuticals. The tools and features they expose—and their overall feature sets—may be less IT-friendly than conventional cloud computing services. That said, HPC services give organizations another option for hosting low-latency apps and workloads.

Application migration is in no sense a turnkey proposition, but cloud providers do offer a large, and growing, assortment of tools, features, and services (in the form of the on-premises public-private cloud, the availability of “edge” or local public cloud services and the emergence of dedicated HPC cloud services) to ease the transition. Providers can do just so much, however. In many cases—and in basically all large-scale application migration efforts—subscribers must shoulder their share of the work, too. For all practical purposes, this means refactoring, redesigning, and sometimes scrapping older, custom-built applications. The next chapter will explore this process in more detail.

¹ In this context, “best-in-class” is not marketing boilerplate; these are cloud providers that acquired third-party vendors that once marketed standalone data replication and data synchronization products. Some built robust data replication and data synchronization features into their core relational database products.

² See Chris Pang, John Kostoulas, Neha Gupta, and Supradip Baul, Market Share: Enterprise Resource Planning, Worldwide 2019 (Gartner Research, May 29, 2020). The report cites 8.8% ERP market growth year-to-year from 2018–2019 and lists a prominent cloud-first vendor among the top three ERP vendors overall.

³ See KPMG International, The Future of HR 2019: In the Know or in the No, 2018. According to this report, almost one-third (32%) of HR executives invested in cloud HR services in 2017 and 2018, while 49% invested in HR (or “human capital management”) software over the same period. For both 2019 and 2020, majorities said that they expected to prioritize HR-related investments in predictive analytics (60%) and enhanced process integration (53%). Almost half (47%) expected to prioritize HR-related AI investments. On balance, executives say that more than one-third (36%) of their HR functions already incorporate AI-like capabilities.

⁴ See Robert DeSisto, Software as a Service: Uncertainties Revealed (Gartner, 2019). DeSisto’s comments are specific to SaaS CRM, although it is not clear that Gartner distinguishes between SaaS and PaaS in this space. He notes that a single cloud CRM vendor—namely, the earliest and most prominent—accounts for about half of the entire cloud market, as well as almost 15% of all enterprise SaaS spending.