Say ‘cloud’ and by now anyone in the tech sector – and a good few people outside it – will be able to rattle off the benefits. Security, scalability, flexibility, resilience, cost-efficiency. Cloud is no longer a challenger delivery model – increasingly, it’s the dominant way of doing things.

For new companies, or companies building new applications, that’s good news. They can build from scratch in the public cloud and access the benefits straight away. Indeed, Gartner recently published a report revealing that the majority of cloud implementations are new builds.

The use of cloud for new builds is now well-established. Organisations always want new software, either brand new, large applications or smaller ones that sit at the edge of their system. Faced with the decision on where to run these apps, organisations are increasingly putting them directly into the cloud. If you were to start your own business now, you’d put it all in the cloud – it’s been done enough times now that the pathway to the cloud via public providers like AWS and Azure is well-trodden.

How do you move apps to the cloud?

But the flipside of that good news is that for those organisations that have essential, hefty applications sitting in a data centre, things are more complex.

It’s far from simple to recreate existing, organically-grown apps and guarantee that the new version will provide exactly the same results as the old one. Testing and the creation of test data is problematic, especially identifying the edge cases where differences in computation will produce different results.

Testing applications is particularly difficult where the passage of time is an important dimension. For example, interest calculations in banking and credit card applications or utility bill and statement systems can only be tested over several  periods. Because the bill is due on a certain date and automated follow-ups are only required after those points, test scenarios are time and date dependent.

In other circumstances the complexity and risk go even deeper. In insurance and banking systems, the logic in the application is itself the realisation of the product. as it was originally sold. In other words, the way the insurance policy dictates claim pay-outs is built into the on-premise software and embodied in the contract which the customer signed thirty years ago. If the application is rebuilt in the cloud and the change of coding has any material impact on the policy rules, the insurer will be in breach of contract.

Lift, shift and refactor

In short, rewriting an app shouldn’t be undertaken lightly. So, what’s the answer for companies that need to get out of costly on-premise contracts without altering their apps?

In a nutshell, organisations should lift and shift their application into the cloud with minimal or no changes, if at all possible. You can then modify them once they’re running in the cloud, which will still be cheaper and more cost-effective than running them in the data centre. Move your application as quickly as possible to the cloud along with its supporting structures, and then set about redeveloping it.

It’s important to note that sooner or later there will need to be changes to these existing applications, whether or not you move them to the cloud. Legislative and regulative changes such GDPR, for example, have forced many organisations to review and make modifications to their applications to ensure compliance. To make changes, you need a test environment. If the application is running in a data centre, the test environment will have to reside there too, spinning away even when it’s not in use, costing money and generating management overhead. Better to run it in the cloud and pay for the usage when you use it.

When you put your applications in the cloud, you also have your test environment there with it. It’s much cheaper to run development and testing in the cloud , you can turn off the  environments when you’re not using them

Migration tools are your friend

Let’s look at a worked example. Say a company has an application running with an Oracle database and wants to move it onto an AWS cloud infrastructure. You could set up the cloud environment, applications and databases and copy the data into the new cloud environment.  Each element that has been hand crafted (such as table structures, indexes and permissions) will need to be tested to ensure that the copy will run as expected. That has to happen before porting the data into it and cutting over, while keeping the old system live in case you need to back out the migration.

That’s the costly way. Instead, companies need to start lifting and shifting straight to the cloud using migration tools such as AWS Endure or Azure Site Recovery (ASR). Using tools that were originally designed for creating disaster recovery in the cloud means that the software and data is replicated to the cloud. Additionally, the data can be synchronised with the live system, until you want to make the cloud version live.

Making money

Clearly, cloud migration just isn’t the same low-hanging fruit as a new-build application in the cloud. For a large organisation that may have  thousands of commercial apps, moving that portfolio into the cloud can be a major headache, and if it’s done inefficiently it will reduce the cost benefit of the cloud migration business case.

The crunch point is that cloud migration needs to make business sense. If there’s an advantage to being in the cloud, then it makes sense to do it as soon as possible. Don’t hold it off while you tinker about in the data centre getting your applications ‘ready’ for the cloud – the time that takes could run off the value altogether, given each application has a limited shelf life.

Lift, shift and refactor is the mantra. If you’re considering migrating apps to the cloud, make sure you’re working with a technology partner who can help you do it quickly, efficiently and intelligently.