Banking on the Cloud

Many firms are eager to reap the benefits of public cloud and want an accelerated cloud adoption. Many are apprehensive of the cost and risk of modernising and transforming their systems to cloud-native technology. They are lured into a lift-and-shift of their existing systems onto the public cloud with an expectation that transformation will be easier when they are on the public cloud.

The reality is that transformation post lift-and-shift is only marginally easier. Further, technology that is lifted and shifted, like-for-like, has proven to be more expensive to operate and maintain on the public cloud. The delay in realising the potential of public cloud and escalating costs have forced many firms to pause their cloud adoption and even repatriate some of their workloads back to their data centres. 

They are also trying to negotiate more favourable usage contracts with cloud providers. Even if such contracts are agreed in favour of cloud customers, in the medium to long term, the inefficiencies of the technology will override this short term relief. This will force firms to reconsider their cloud adoption decisions later.

This raises the argument of speed vs stickiness of cloud adoption. Should firms rush to adopt cloud or should they target stickiness through transformation that helps achieve business outcomes? 

More than the firms themselves, this is also a business strategy question for cloud providers. Should they focus on short term growth of cloud revenues through rapid cloud adoption or a more financially sustainable strategy that focuses on customer stickiness to the cloud?

Transformation is sticky – and it can be speedy

Modernisation and transformation of enterprise technology is expected to provide the desired benefits on public cloud, making it stickier on public cloud. But it is commonly perceived to be complex, costly and risky. To reduce the risk, firms proceed with the like-for-like approach and try to achieve full feature parity. Firms expect the same features supporting the same business processes as they migrate to the cloud. They expect that with feature parity, they are dealing with the known which would make cloud adoption faster and less risky.

There are quite a few misconceptions here. The first is that many of the features and business capabilities in the legacy or on-prem technology may no longer be in use. Some may no longer align with the existing business processes and are used with manual workarounds. Many of the capabilities implemented on-prem may be available off the shelf on public cloud. Last but not least, the infrastructure configuration for a lift and shift migration may not utilise many cloud native capabilities requiring a more involved or complex setup.

Taking all this into consideration, a lift and shift migration, though speedy, will eventually be costly and will offer less agility and poor flexibility on public cloud. Transformation and modernisation on the cloud will not be much simpler or faster than if it would have been attempted in the first place. This will eventually lead people to question their decision to adopt cloud in the first place.

This then gives opportunities to make transformation speedy through:

1. Reducing the scope of the initiative, 
2. Prioritising the transformation and migration of business capabilities based on risk and value,
3. Lifting and shifting only the end of life applications,
4. Delivering these capabilities incrementally into production on public cloud,
5. Continuously optimising on the cloud to keep risk, cost and complexity low

Reducing the scope of initiative is crucial to reducing the risk and cost of the initiative and this involves:

1. Decommissioning products, features and capabilities that provide diminishing returns or are no longer in use,
2. Identifying the commodity and undifferentiated capabilities, and fulfilling them using off the shelf products and SaaS solutions,
3. Utilising cloud native infrastructure and platform services to reduce the effort and scope of infrastructure provisioning and operations

These steps help strike a balance between speed and stickiness when transforming an on-prem estate to a cloud-native technology.

But if you have to lift and shift …

There may be reasons that necessitate a speedy lift and shift to the public cloud. A typical example is that of a stress data centre exit on a notice too short to migrate to an alternative data centre.

Here, a business may not have the time to consider transformation of their technology estate as part of migration. But if they decide that cloud is the ultimate destination, a lift and shift migration should only be seen as an initial step in the journey. Even for this initial step, they can take measures to ensure that eventual transformation starts on the right foot. 

Some of these measures include:

1. Automating infrastructure provisioning and management, ensuring consistency and repeatability across environments,
2. Automating the delivery of applications on the infrastructure, increasing delivery efficiency,
3. Automating testing, reducing the testing overhead and increasing testing confidence,
4. Right-sizing the infrastructure based on usage statistics, optimising costs,
5. Decommissioning applications that have little or no usage and are not providing any value, reducing the overall scope

These measures will help reduce delivery friction, increase delivery confidence, optimise costs and enhance operational efficiency when on public cloud. These will also motivate the business to consider cloud-native transformation of the technology to reap further benefits of the cloud, thus increasing stickiness while pursuing speed of cloud adoption.

In a nutshell …

When targeting cloud, speed and stickiness should not be an either-or decision. Businesses can strike a balance between both when pursuing such a strategic endeavour. They should look at realising the benefits cloud provides to maintain and extend their competitive advantage. That requires taking steps that ensure long term success on public cloud.