Cloud Migration. How Hard Can It Be?

You are already using the cloud and carried out some application migrations and you’re making significant digital “front end” advances. In order to shift the majority of your business to the cloud and gain competitive differentiation, you will need to build a structured technology plan.

Knowing why you are going to the cloud is the foundation of the business case behind the plan. You can start with a simple model that takes your knowledge of the IT estate (and its operating costs) plus priorities (your “why”) and some cloud build and run cost assumptions (based on your early cloud adoption). This analysis will help structure the delivery — it sets up the guide rails for formally sizing and planning the large-scale cloud migration, decommissioning and new development projects.

Let’s consider some of the many applications in your estate. Take the humble “database web app” and consider the servers where the app runs: the compute, network and storage it uses. It is usually a classic 3-tier architecture like: an HTTP server invoking business logic that connects to backend synchronous relational database processing, and probably additionally asynchronous calls out to a messaging system to transmit and receive data from other core processing systems like an inventory, ticketing or ledger.

There are millions of these types of applications around the world. In your environment I would hazard a guess you have anywhere from 100s to 1,000s to 10,000s “IT applications” depending on your global reach and line of business complexity. The variety of technology stacks will be mind boggling, often using products from external corporate vendor technology agreements. However, with the right enterprise architecture governance you have probably solidified the majority of stacks into a manageable set of patterns.

Emerging from the last 10–20 years it is going to be stacks like WebSphere Application Server/DB2, PHP/MySQL, Java/Oracle, .NET/SQL Server probably mixed in with ESB integrations and mainframe transactions exposed as APIs. Then there will be recent developments such as Go, Ruby, Node etc using NoSQL and other document and object stores.

Do you have an up to date view of the corporate application estate and its deployment model?

Many companies say they do, but I often find there are many gaps in the data. There might be a decent inventory of applications, but does it link to a good view of deployed configuration items or strong record of interfaces and dependencies? Rarely.

Whatever you’ve got, it’s a start. But do not embark on an enterprise wide analysis-paralysis development of an inventory, because it’s just delaying the start of your big shift to cloud.

Start instead with the dimensions that help prioritise which piece of the elephant to eat.

Here’s a starter list of things to get some “just enough” analysis:

• Know the major systems that support the products and services you provide to your customers.
• Know what the list of software products e.g. middleware, COTS packages that are in use and deployed on servers — and their versions.
• Know the company organisational model and key business operations across them.
• Know which systems are critical to the operation of the business — this is not just the customer facing ones, but systems for corporate accountability like safety or financial management and reporting.
• Know these systems in the context of different lines of business, division and integrated companies, and which locations and countries.

For example, you could start by asking each line of business, by region, which systems are running on software that is out of support. That can give you a list of applications that the business decide they don’t really need, leaving you with the one that you’ve perpetually missed the ball in trying to upgrade. Without upgrade that system carries a greater risk to the company of going irreversibly wrong e.g. no security patching available from the software vendor.

The discovery shapes an application modernisation plan. It requires developing the patterns — decisions and guidelines — to create a repetitive cycle of journeys for shifting similar applications to the cloud

With .NET/SQL Server as a database web app example there is the application component part and the database service part.

For the app part, a common first journey is:

Modernize by Containerize = Re-build to latest software level + Secure for the Cloud + Package with Docker + Automate Deploy and Re-Deploy + Kubernetes Cluster + Decommission Existing**

The implementation of Modernize by Containerize might be:

• Recompile the application code against the latest versions of .NET and SQL Server
• Package and manage the data set in the database and other file stores.
• Enable encryption for data at rest (TDE) and in transit (TLS)
• Package the application code with a Docker build
• Re-test interfaces (functionally is the in/out data exchange the same?)
• Create new deployment scripts and integrate them into a new automated DevOps pipeline
• Automate the pipeline to set-up a Kubernetes deployment
• Test the deployment of the application into your cloud target
• Re-test interfaces (environmental and networking changes!)
• Progress to production lifecycle rollout.
• Disable existing system.
• Run for agreed maintenance period and decommission existing system**.

** Avoid this at your peril

This is the beginning of a pattern library of recipes. The next pattern — ‘Modernize by Repackage’ — might be an iteration of this ‘where you might have spotted opportunities for repetitive sub-division of an application. For example, using a tool such as WebSphere Transformation Advisor on a traditional WAS monolith you can get some insights as to how to separate an application into multiple Liberty containers. This offers more benefits beyond basic containerization such as being able to independently scale individual containers.

The original discovery exercise gives a coarse-grained order of magnitude effort. The pattern language and its implementation steps are used to develop finer-grained effort and duration estimates.

1. Find out what needs to modernise.
2. Prioritise in the context of the big picture organisation.
3. Develop guidelines and standards for the modernisation.
4. Use patterns and inventory to create migration plans.
5. Modernise to a new cloud system and turn off the old system.

You will build up a pattern library you follow your cloud “why” — like addressing critical security risks, driving out inefficiencies in user journeys, or exploiting the latest technology to further digital ambitions. You can drive out enough of a plan and budget estimate to start and execute a parallel agile migration plan that will materially shift your business to take advantage of the cloud.