Cloud Migration: the Fast Beats the Slow

by Eban Escott, Jan 27, 2016

The cloud enables an on-demand business model. No huge upfront resource costs, simply use as much or as little as needed. This is why by 2018, more than 60% of businesses will have at least half of their systems on cloud services and solutions. Right now, most businesses are undergoing some sort of digital transformation and the truth is, if you are not innovating in this direction, you are at serious risk of being disrupted.
It's no longer the big eats the small. It's the fast beats the slow.

Some of the IT budget must go towards innovation and CIO’s around the world have acknowledged digital transformation as a key challenge. On one hand, you will need to support existing software, and on the other hand you will need to innovate. This is the role of Bimodal IT. The two modes of delivery in Bimodal IT are mode 1 and mode 2. Mode 1 is about stability and supporting existing systems. Mode 2 is about innovation and exploring new possibilities.

At some point in the business’s digital transformation, you will likely be faced with an application modernisation project. This project would be considered legacy software and has been maintained under the mode 1 banner, but has become at risk due to market changes or loss of internal resources. A legacy system migration legacy can occur under the mode 2 banner. Legacy modernization is an opportunity to innovate, so get on your marks, because the race is on.

From here there are lots of options to consider, though they generally fall under three broad approaches:

  1. Do nothing: Ignore business trends at your own peril

  2. Uncover: Leave the intellectual property (IP) as is and use a platform to uncover

  3. Rewrite: Start again on a new technology stack

The do nothing approach is the elephant in the room, ignoring the obvious. The other 2 options are both legitimate. So what is the best way to decide? The answer can be revealed by considering the intellectual property (IP) in the legacy application. Consider if the IP is so specialised that rewriting it would be too costly, for example something like a complex mathematical simulation. If it is, then the uncover approach is good. If the IP could be rewritten or the IP is how a problem was solved, for example, something like a workflow that helps a business sector. Then the rewrite approach is good.

The pitfalls of the uncover approach is to simply replicate the legacy user interface (UI) in a browser, as many opportunities to innovate would be lost. Firstly, one of the biggest drivers of digital transformation is to increase customer satisfaction and today’s users expect a great user experience (UX). Secondly, putting more code on top of legacy systems is compounding the actual legacy problem. The true IP of the legacy system should be identified and the rest of the application deprecated. If it is left in play it will niggle at the business for years to come.

A platform can uncover the IP and modernise the software into a cloud-based environment.
So, if the IP is to be preserved, the rest of the legacy software that is deprecated will need to be modernised. This means that the uncover approach still ends up with some rewriting.

To rewrite a legacy application is an opportunity to wipe the slate clean and lay down a new foundation for the future. However, there is no doubt that this is a serious undertaking and that many smart people have impaled themselves on these types of projects. Some of the key challenges to be mindful of are:

  1. Break the project down into iterations or sprints. Don’t go for the big bang entire rewrite in one go.
  2. Find a lighthouse client. Users breathe life into the soul of software and the earlier the software is being used the better.
  3. Use a scientific approach. Put forward a hypothesis that can be validated. In the lean startup, this is about the build-measure-learn cycle.
  4. Test, test and test. To be confident that any non-trivial sized software application works, is to ensure the quality of the software through software testing.
  5. Consider the commercial outcomes. The project will open business opportunities and the C-suite should be involved in the planning process.
  6. Don’t forget the culture. Introducing new software changes the landscape of the people using it. A change in the management plan could be worthwhile.
  7. Last and not least, is the technical challenge. Follow a systematic process from the legacy application to the new modernised application in the cloud. This is such an integral part of the process that the rest of the article below will be spent discussing it.

Let's imagine a hypothetical scenario where you have identified the first part of the legacy application to be modernised. This is the Minimum Viable Product (MVP). It should be just big enough to be useful for the first lighthouse client, but not too big to include excess functionality.

The first step, seen in the diagram below, should be to start with the legacy database and reverse engineer it to a model (more on models shortly). The reason for starting with the legacy database is to ensure there is a data migration plan for existing customers that will eventually want to move from the legacy to the cloud.

Now, it is the actual model that is the key to the success of the project. Academics everywhere have been very busy researching, but if you have not heard of the work yet it falls under the banner of Model-Driven Engineering (MDE) and Domain-Specific Languages (DSL). In essence, the idea is to work at a higher level of abstraction than the code. Then use robots (or code generators) to generate large portions of the target. This creates all sorts of efficiencies.

This means that in steps 2, 3 and 4 in the above diagram, the goal is to create the models of the target application. Then in step 5, the new cloud application can be generated. Finally for step 6, since the first step was to start at the legacy database and MDE is used, there will be a path for the data migration for the legacy customers to the cloud.

In summary, a cloud migration project is a serious undertaking. With many examples of failed cases there is no doubt why the topic can send shivers down your spine. There is still some good news for you! The software engineering community has been innovating and there are now some very good and viable options that can minimise the risk involved.