Combination Approaches

Of course, the modernization patterns are not an exclusive choice. In a significant proportion of cases, the favored approach is a combination of techniques that builds to the desired outcome over time. This is often the preferred approach for an overall Invest approach.

Lift and Shift

Rehost

We have included this option here for completeness, however a lift and shift is really just a rehost where as little as possible is changed.

Move and Improve

Rehost & Replatform

A Move and improve is probably the most popular of all the cloud migration approaches. It combines a re-hosting to cloud, with a degree of replatforming. As discussed in the benefits section, while changing some aspects of the platform will take a little longer and cost a little more, that cost is quickly recuperated with improvements to scalability, resilience, availability or security.

Changing the storage platform is unavoidable when moving to cloud, while changing the operating system to a standardized vendor and version is also very common occurrence. Changing the database version or service level is similarly common, while changing the database family would be a much more challenging degree of change. Other middleware changes vary in complexity depending on the vendor and the degree to which vendor-specific functionality is used. A more recent trend is to switch traditionally built applications to run within a Kubernetes cluster, and while this offers few of the major benefits, moving to a single application clustering technology for all applications is clearly desirable from a pure IT perspective.

Move and Evolve

The typical sequence is :

Rehost -> Refactor -> Revise

This allows an application to be moved to a new target cloud platform, and then the application can evolve over time. This has a number of advantages over an approach which attempts to make enhancements in the on-premises environment before migrating. It’s main advantage over Move and Improve is that it gets an application to the cloud more quickly - so is helpful in the case of a data centre closure.

The application is migrated with the refactoring limited a minimal set of technical aspects to enable the migration. When the environment has been proven and is stable, then additional refactoring can be considered. Alongside the technical refactoring, the cloud environment also makes it easy to extend an application with additional capability built on modern could principles.

However, the key disadvantage with this approach is that it delays the majority of the cloud benefits until later, and that it involves a double move - i.e. a shift to a new hosting platform, and then a separate shift to the new platforms thus incurring double the test costs. A Move and Improve is done as a single, integrated platform.

The final option to consider is changing the application in-place, i.e. while it is still running on-premises before it is moved to the cloud. This is frequently infeasible as many of the modern cloud platform services are simply on available on premises. In addition, the Move and Evolve approach has the following additional advantages:

Non-production prioritization

This approach is often used for large and critical applications where there is significant business risk associated with non-availability of the system.

Instead of focusing on the production environment, a less critical environment is selected to trail a migration to cloud - perhaps a test, development or training system. This allows detailed and in-depth testing of the new cloud environment whilst minimizing risk. In many cases, multiple systems will be migrated, gradually increasing in size and complexity until the final tests are demonstrated to be able to deliver the SLAs and resilience required for the production system.

This approach has the strong advantage of using a traditional application lifecycle approach where bugs and issues with the cloud environment can be dealt with as they are encountered through the increasing size and complexity of the dev->test->pre-production environments. It also means that when the production system is finally migrated, then all of the supporting non-production systems are already in the cloud and in the correct state to support the production environment.

Disaster-recovery first

The public cloud provides an ideal environment for disaster recovery systems - where they can be kept ready to take over at comparatively low cost as they can be scaled up to production sizes very quickly with the cloud’s ability for elastic scaling.

It is a common approach for organizations to provide a new disaster recovery capability on the cloud whilst retaining the on-premises primary production system.

However, it is also very common for the creation of a disaster recovery system in the cloud to be the first step to migrating the primary production application. This provides a number of similar benefits to the other non-production prioritization options mentioned above.

Now that we have covered the different modernization patterns at a general level, let’s take a look at each of them in a little more detail.