Compelling Events

The analysis above is, as already stated, a gross simplification, and there are other considerations that must be taken into account and can shift the decision to one of the other options. Let’s take a look at some of the most common elements :

Hardware Aging & Refresh Cycles

Unfortunately, IT infrastructure and hardware doesn’t last forever, and an often overlooked fact is that the older the hardware, the highest the maintenance costs. Not only is it increasingly difficult to source parts, but the vendor will increase support costs as their costs increase over time. At some point, it becomes uneconomic for a vendor to continue to support and so the hardware becomes deprecated.

Even before the vendor drops all support, the increasing support costs can outweigh the cost of a migration, and so a common driver to move to cloud is where the on-premises infrastructure has already become too costly to continue to run.

For some companies (especially in heavily regulated industry sectors) regulatory compliance can be lost when hardware or software goes out of support, and so this can force organizations to upgrade even when parts are available and the system is running very well.

There is a second important point to note is that if a hardware change is necessary, then the cost of moving the system to new hardware will be incurred whatever the destination - on-premises or to public cloud. It’s also very likely that an on-premises replacement will require significant capital expenditure for new hardware. In many cases, as a migration costs is _baked-in_to every option, then a public cloud destination will likely work out as the cheaper TCO option.

Datacenter Initiatives

While we have focused so far on individual applications, many organizations will wish to adopt cloud because of a much broader datacenter level initiative, and this will impact on the choice made.

For example, many organizations have datacenters that are aging or below the resilience levels required for the applications they host. Here are some examples of reasons why datacenters may become obsolete :

In addition, some organizations may decide that owning a datacenter is no longer core to their business and so wishes to divest itself of any owned data centers. While may companies will sell off and outsource datacenters and their operations, an increasing number of organizations are seeing this as an opportunity to move to a more flexible public cloud approach.

Non-functional Enhancements

The service levels offered by modern public clouds will almost always be capable of delivering a quality of service equal or above the level of service an organization might deliver within an on-premises environment. Some of these benefits are automatic (e.g. the durability of storage, automatic database backups) and others will require some level of change to enable the higher service levels (e.g. cross-region data replication).

Storage capacity increase is a very frequent driver for an application to move to cloud, and the public cloud is able to provide virtually unlimited capacity for many different types of storage. However, your application may not be able to take advantage of storage flexibility without some degree of change. If n application is wholly embedded within a VM (including data) then you will be constrained by the maximum VM size - moving to external storage is a small change but will enable greater capacity. If you are using a database, then some managed database services (e.g. Autonomous DB) will offer storage that will automatically extend as you need more.

Adding CPU capacity to an application is also a very common requirements. In many cases, an application will see a performance boost where the legacy hardware is relatively old - the CPUs on the public cloud are more likely to be faster. In addition, public cloud servers generally have modern CPUs with large core densities per server, and so moving to cloud may give greater headroom on a single server.

Adding compute beyond a single server is much more complicated, and for some applications impossible. If your starting point is an entire application on a single server (e.g. web server, application server and database) then it should be possible to split up the layers into different servers, or use native cloud services for one or more layers (e.g. the database service) and this could deliver significantly higher CPU resources. However, if you need to split a service (e.g. the application server) over multiple cloud server, then this is a change from a single-node to a clustered service. Many applications will require significant change to enable clustering, and for some (especially some ISV applications) it may be impossible.

If your middle-tier is stateless, then the switch to a clustered architecture is relatively straightforward - this is then natively supported by many mid-tier application servers (e.g. Websphere, Weblogic, JBoss etc), and you also have to option to move to Kubernetes cluster model.