7 key strategies to transform applications with the Cloud

Deploying new infrastructures is only ever rarely an end in itself: migrating to the Cloud is generally part of a modernising project implemented by a company to reduce costs, improve performance or increase productivity, all whilst cutting back on investment and maintenance costs.

 

Now we just need to find out how to bring together these promises with the legacy system, which often has significant technical debt, and numerous interdependencies with the rest of the information system. Should the application be ported as it is? Or would it actually be better to rethink its entire architecture? Perhaps reduce it? Or replace some of its components? Maybe even rethink the entire production process? If so, which provider to call?

 

Each application is unique, particularly when it is an old one. There’s no magic wand that you can wave to solve all these problems. But we can follow Gartner’s seven paths to modernise to get the ball rolling.

 

According to Garner, encapsulating is the first step towards modernisation. This involves replacing the application’s standard calls with equivalent functions transmitted via an application programming interface (API). Access management and security can then be delegated to services that are managed independently of the application. For instance, using this approach will allow an older application to be reintegrated into a modern information system, so that it can regain some of its value without the need for modification.

 

Rehosting aims to accurately imitate the architecture of the infrastructure and application services using cloud resources. This “lifts and shifts” the application from one environment to another without modifying its features and functions.

 

This process allows for quick and affordable migration. In theory, you should only have to provide the same or similar resources as the original architecture before duplicating tasks and data. In practice, the approach still involves checking that all the parameters in the new environment (network, storage, performance, operating system) are compatible with the application.

 

Rehosting is often preferred when the company is looking to reduce the cost of ownership (TCO) associated with its infrastructures, or when looking to benefit from the provider’s service level agreements (SLA). Rehosting alone will usually not allow the application’s intrinsic value to be modified, as this always depends on the original architecture. However, migration is often the first step towards large-scale transformations.

 

With replatforming, application deployment is entrusted to an execution environment that connects the application and its basic Cloud infrastructures. This middle layer allows to replace all or part of the components in the application’s context history can be replaced with services able to benefit fully from the elasticity of the Cloud.

 

The application isn’t simply copied, rather it is truly redeployed in a new environment, allowing you to consider using managed services, implementing automation scenarios, optimising the architecture and changing the configuration without even modifying the main activity in question. However, replatforming will reach its limits when the application mobilises a high number of external services.

 

Refactoring comes in when the application code requires a few adjustments, either to increase the produced value, to erase the technical debt or to adapt to the future execution environment. Refactoring is a form of investment that aims to develop the application and make it last longer by giving it foundations adapted to the Cloud, whilst preserving the bulk of previous investments in the architecture.

Does it make sense to move an ageing, monolithic architecture to the Cloud? Sometimes the modernisation project requires a more significant disruption with the current one. Refactoring, then, gives way for a proper redesign, via the design of a distributed, service-oriented architecture and process management. This strategy consists in isolating the functional bricks in order to reintegrate them into a new, flexible and scalable structure.

When there is a skill, language or operating systems shortage, you might need to consider starting over and rewriting the application. In this context, the application keeps its scope and specifications but will be completely redesigned. This means that the technical debt can be erased and the best tools and environments for the Cloud can be adopted.

What if your application  doesn’t do the trick? The replacement strategy is particularly interesting when the modernisation project involves a much higher investment than the expected benefits. Gartner suggests reconsidering your limitations and goals in order to determine if there isn’t already an application on the market that can meet your needs. Replacing your HR software, ERP or CRM with a SaaS solution will release you from the design and development stages, which frees up time and resources for your most important applications. However, be wary of the integration process, which can be laborious.