The 10 Steps for Cloud Migration

Knowing where to start for cloud migration can be a tricky thing. So we’ve compiled a “10 Step Migration Plan” to help the process.

1. Look for an established vendor with a track record.

A Cloud vendor that is well established will have a wider breadth of knowledge and deeper insights into potential pitfalls than a smaller less-established vendor. They are also more likely to have higher security standards, a better range of services, more resources available to meet peak demand, and a better quality of support and training available for their users. The support and training provisions alone are likely to make the biggest difference to a customer that is new to the Cloud – the vendor must be able to answer questions in great detail and within an appropriate timescale.

2. Does the project really need to be migrated?

It may sound obvious, but not every project is suited to migration to the cloud. If management and customers are happy with the current hosting arrangements, and particularly so if they are cheaper than the cloud option, then there is no reason to move. Cloud migrations are usually only necessary when considering large-scale hardware purchases in order to sustain or scale existing in-house projects or enable new projects to take place. Such migrations are only value-for-money if the perceived benefits of the migration outweigh the costs of performing it.

3. Consider data security.

When putting applications and data onto a system outside an in-house data centre, customers will want to be sure that only the right people can access it and that its contents remain secure. Use firewalls liberally to ensure no accidental backdoors are opened through routes other than the application itself. Encrypt all communications with the external application and lock it away behind a proven authentication system that will guarantee that the only people who can access it are those who are permitted to.

4. Data transfer.

IaaS Clouds are internet-based, therefore there is usually only one method of getting data into them: uploading files across the internet. Many internet connections used by smaller businesses offer far slower upload speeds than download speeds and it can take an eternity to upload even a gigabyte of data. Even the fastest corporate networks struggle to upload a few tens of gigabytes within a reasonable timeframe, e.g. a dataset from a DNA sequencing machine. If the transfer of large datasets to and from the migrated software is a requirement then careful consideration needs to be made as to how this could be achieved, reduced, or avoided.

Some IaaS providers offer the option of shipping hard drives of data to them to avoid these upload bottlenecks, but be aware that shipping delays and workload at the vendor’s data centre may mean the process is far from instant. The best approach is to take a very close look at the data transfer requirements and see if they can be minimised, e.g. by pre-processing large datasets locally to produce a smaller summary dataset for upload. Conversely, the cloud can be a good way of improving download speeds for customers using an application. Cloud vendors can deploy an application on whichever of their physical servers are closest to a customer’s location. This can make a big difference to the response times customers get from the application.

5. Data storage and location.

How much data does the application really need? Cloud data storage can be expensive, particularly for very large quantities, so consideration should be given to data retention policies. Should old data be archived off-cloud to a tape library or other external resource? Is raw data needed at all or are summaries sufficient? Whilst not hugely expensive, movement of data within the cloud does cost money in terms of internal bandwidth charging, depending on the vendor, so applications should avoid moving it around unnecessarily. Shared data resources such as shared drives or central relational databases can be more effective than directly copying data between virtual machines, particularly for data sources that are usually accessed randomly or partially rather than sequentially or in their entirety.

Using licenced software on the Cloud may in some cases contravene the terms of the licence, or may invoke special clauses that would not apply elsewhere. Check the licence text carefully and if necessary consult with the software vendor to gain appropriate permissions or renegotiate the licence.

6. Scaling.

The scalability of Cloud applications is not something that magically happens upon deployment (at least, not in IaaS – although PaaS deployments of single applications do inherit a certain amount of scalability from the host environment). Applications have to be placed behind load-balancers/auto-scalers within the cloud in order to be scaled up on demand. Some cloud vendors offer these as part of the service, others require the installation of third-party tools, however most scaling and balancing solutions incur some additional expense.

Once the application is behind a load-balancer or auto-scaler, the application itself needs to be aware that it could be scaled. If migrating an in-house application that already sits behind an in-house load-balancer than chances are that very little will have to be changed to support scaling in the Cloud. For applications that have not yet been load-balanced in house, developers will need to assess the code to ensure that it can cope with a changing environment. How will user sessions be persisted? How will they co-ordinate access to any central data resources in order to avoid conflict? – the vendor must be able to answer questions in great detail and within an appropriate timescale.

7. Service level guarantees.

The first question to ask any cloud vendor is what their availability guarantee is, and what recompense there might be if they fail to live up to their claims. A cloud vendor failing to provide the agreed service is the worst possible situation for any cloud application to be in. Particular attention should be paid to the processes in place in case of vendor collapse or takeover. Once confident of the vendor’s service guarantees, the next check is to look at vendor backup plans. Do they take on- or off site backups? What is their disaster recovery plan in case of loss of a data centre? Do they guarantee to recover the data.

8. Upgrade and maintenance schedules

Cloud vendors will need to update their systems from time-to-time to install the latest security patches and new features. Applications built on top of the cloud will need to be aware that these patches take place and have plans in place to ensure that they won’t be adversely affected after the upgrade. Vendors often give an option to decide when the upgrade will take place, subject to a fixed final deadline when it will happen anyway, so application developers should carry out testing well in advance to ensure service continuity.

Likewise, if a vendor schedules planned downtime of cloud services to perform maintenance, try to schedule application maintenance windows to coincide with this in order to prevent excessive numbers of outages for customers using the application.

9. Software architecture.

Traditional applications are designed for traditional hardware configurations. Cloud applications are designed for Cloud infrastructure and features. The two are not necessarily equivalent. Whilst it is entirely feasible to take a traditional application and simply copy it to a Cloud-based replica of its original environment, this is not always the most effective use of Cloud functionality.

Questions need to be asked regarding the choice of infrastructure – does it need a grid/cluster equivalent or can Cloud alternatives such as Hadoop or self-instantiating instances provide a better service? Does it need an integrated load-balancer or can the Cloud’s default load-balancer suffice? Does it need database replication to distribute requests or can a single larger virtual database server handle all the traffic on its own?

10. Check with the lawyers.

The final hurdle when migrating to the Cloud is almost certainly going to be a legal one. Data protection or other acts of law may prevent the placement of data in certain locations (e.g. French law prevents clinical trial data from being transferred to locations in other countries, even within the EU). The contract with the cloud provider must also provide suitable protection for data transmitted to it. Checks must also be made to establish which jurisdiction’s laws will apply in case of a dispute – the application owner’s, or the vendor’s head office, or the vendor’s data centre locations where the application and data is being kept?

Some lawyers express concerns regarding intellectual property (IP) of any data that is outsourced to an external location, Cloud or otherwise. The opinions and rules vary widely depending on local custom and precedent so seek legal advice before putting anything on the cloud that could construe potential IP.

Using licensed software on the Cloud may in some cases contravene the terms of the licence, or may invoke special clauses that would not apply elsewhere. Check the licence text carefully and if necessary consult with the software vendor to gain appropriate permissions or renegotiate the licence.