Mass migration is a journey, not a destination

In my last post, I looked at the reasons why enterprise organizations are considering mass migration to the cloud for their application ecosystem. I canvassed some of the cultural, commercial, and technical challenges they face in doing so. I also laid out the migration modes available, commonly known as the “six Rs of migration,” retiring, retaining, rehosting, replatforming, refactoring, and rearchitecting.

Once the notion of mass migration and its benefits are conceived, my suggestion is to initiate a thorough discovery and create a high-level business case. In this post, I’ll explain what should not be forgotten during the process.

Discovery

First, you need to get a clear and accurate picture of your existing (legacy) application environment, including infrastructure, security, data, and commercial considerations. These insights will help to establish the parameters of the project as you’ll know which applications are suitable to migrate to the cloud and which should remain on premises. You will have the knowledge to anticipate the potential impact on the enterprise and won’t come across unpleasant surprises (and in this context all surprises are unpleasant).

The complexity of the migration process will vary from environment to environment and will depend on the applications involved. A virtualized, service-oriented architecture will be far less complex to migrate than a big legacy mainframe architecture. I would always advise starting with the least complex applications to yield some immediate “quick wins.” Your organization will gain experience and be more confident as you progress through the spectrum.

Lastly, the impact of a mass migration to a cloud environment on the people and the organizational culture are important factors to consider during your discovery. Efficiency and effectiveness of “faster” IT can only be achieved if people, processes, and tools have all transformed at the same pace.

Business case

Once you’ve devised your overall strategy on the landing platform, a business case on new costs of the platform, operations, and development will facilitate decision making.

To decide on an overarching strategy for your landing platform, you’ll need to determine the most appropriate target cloud deployment:

1. Choose the type of cloud: public, private, or hybrid
2. Decide on either a single cloud or multi-vendor cloud strategy
3. Identify the most suitable type of service – IaaS, PaaS, or SaaS.

Answering these questions at the beginning of the process, based on a clearly defined and logical set of criteria, will help you avoid the kind of “analysis paralysis” that can stall the process further down the track. As already mentioned, the results of the discovery process will help you draw up these criteria.

Time to decide

In my experience, the outcome of the business case is nearly always positive to proceed with a mass migration to the cloud, as this is the key to accelerate innovation. When your organization is ready to take the plunge, make sure that management understands the results of the discovery and the business case and is in complete agreement with your principles.

Time to get into low-level design

Once you have a go-ahead from the organization, it’s time to get into the low-level design per application, landing platform, development efforts, operating model, network design, and security architecture.

Servers, networks and data services all run and interact differently in a cloud environment, and you’ll need to make sure you update parts of your system to be ready for these changes, documenting code changes and configurations prior to execution.

Security has traditionally been one of the main deterrents to move to the cloud, prompting cloud service providers to prioritize security as they’ve developed their products and services. Now, public cloud environments are typically more secure than enterprise on-premises or private cloud environments. But, with the threat landscape and the regulatory framework presenting an ever-evolving spectrum of risks, the enterprise needs to change the way it thinks about security to embrace a more collaborative approach.

To keep your data secured, you’ll need to re-evaluate your security procedures and strategies. Applications can be extremely secure but you won’t own any of the hardware and many of your business processes might not apply to cloud applications. You will have less control over security and other procedures, and security systems will need to work seamlessly with your cloud providers’ offerings. At the same time, you need to ensure that any cloud partners handling the personal data of customers, employees, or any other stakeholders have systems and processes in place to meet the requirements of stringent privacy and data protection regulations, such as GDPR.

Time to prove the concept

So, your business case is positive and management is happy with the results on paper. But how do you know whether it will actually work and give you the desired benefits? I would certainly advise making a good proof-of-concept (PoC), which also provides you with a reference model in the future.

After these initial considerations, there is yet another decision to make: who is the best candidate for a proof-of-concept?

There are two prevailing approaches when it comes to proving your concept:

1. Choose a non-productive/non-critical part of an application/service and bring it to the public cloud and prove that the model design works with similar or improved efficiency, but with reduced costs.
2. Choose a non-critical application/service, bring all components to public cloud, change the operating model, deploy automation, and prove that the model delivers the increased pace of innovation that it promised, along with reduced costs.

Both approaches have their own benefits. The first approach will give you a quick result, the second option will take a bit more time but will leave you with greater confidence in the model.

Migrate, test, migrate. Repeat

Now that you have completed your discovery, created a business case, got a go-ahead, created the low-level design, and proven that the design works, it is time to speed up.

Consider doing the following for each application:

1. Work with the business owners to set expectations around timings and deliverables. An agile migration methodology will allow you to minimize risk and disruption by mapping out an incremental pathway to a full migration. Then, execute in sprints, with clearly defined KPIs for each stage of the process. This will allow the project team to course-correct early in the cycle.
2. Implement a series of tests for the application and your users, defining the success criteria for flipping to the new environment. Figure out how you will cut over and identify the stakeholders required for support and escalation on operational plans.
3. Finally, before going ahead, take one last baseline performance analysis of the source environment to compare to the new environment.

It’s advisable to run parallel environments while you migrate traffic, users, or content. To keep this transition period to a minimum, make sure that each business owner is involved and ready to validate the migration in real time, testing applications to confirm migration has not changed functionality and measuring differences in cost and performance as you go.

Conclusion: It’s all about the journey AND the destination

Every enterprise is different, and with widely divergent business models, digital transformation strategies and legacy environments, there is certainly no one-size-fits-all approach to something as big and complex as mass migration to the cloud.

In principle, I’ve found that the approach detailed above represents best practice when initially tackling the task, providing a jumping-off point from which all stakeholders can start to formulate their specific requirements, roles, and responsibilities.

In my next post, we’ll explore steps one and two of the process – discovery and business case creation – in more detail and provide some insight around how to choose between different vendors for public cloud.

I take this opportunity to thank Lysanne Vossen (Senior Consultant- Cloud) and Aditya Sharma (Senior Enterprise Architect)  for their contribution in this article.

Shailesh Jain

My experience as a business thinker with a technological bias spans over 20 years.
It enables me to turn the language of growth, agility, efficiency, and speed into the language of the cloud, where it takes ten minutes to make a change compared to periods of up to six weeks with legacy infrastructures.
I advise my clients on advancing their digital transformation journey by leveraging the entire power of their IT and innovate much faster and broader.
I have helped many organizations to take their first steps in cloud, where they are able to innovate faster.