The cloud migration challenge – getting there, staying there

Cloud computing has moved from being a promising option to becoming a concrete set of technologies that are now road-tested and sturdy. The leader in the public cloud space, Amazon, is thought to be earning more than $2billion in revenue per year – Morgan Stanley estimated that these revenues will grow to $24billion by 2022. Microsoft is now hitting $1.5billion in annual earnings from Office 365, while it claims more than $1billion in revenue for Azure and its cloud tools.

Amazon and Microsoft have seen most of their growth so far through working with early adopters – this is a mix of small companies, larger organisations that embrace innovation early, and software developers that use cloud computing for testing and pre-production work. As these different groups of users have proved that the cloud can meet their needs, their use of this platform has continued to expand.

However, the next step in the migration to the cloud is more complex. Rather than building applications from scratch and running them in the cloud, IT departments within companies are now looking at how they can migrate more of their existing IT infrastructure over to the cloud. This is a fundamentally different challenge.

Moving existing workloads over to the cloud involves more than simply spinning up new instances on a public or private cloud. Each application or server workload can have its own interdependencies to other server instances, for example. The networking set-up between these machines and those that access them is a complex one to recreate as well.

The spectre of migration failure is a big concern for any IT team and it can happen for any number of reasons. When you are moving to the cloud and have less control over the target compared to a traditional migration, this can be an additional cause for concern. Regardless of the cause, the impact of any failure will be extensive and would result in additional downtime while the IT team tries to track down the problem and correct it.

You can also experience major migration setbacks when the tools that you’re using fail to work as expected because of locked files, network disruptions or site outages. It’s important that your migration tools are able to perform under adverse conditions, without production impact and without sacrificing data integrity. Otherwise, you’ll be forced to start the migration over from the beginning when the initial attempt—or attempts—fails.
Beyond outright failure, there might be performance issues encountered after a migration. Some migration technologies are one-way affairs, with no ability to support a return to the existing systems if something goes wrong. This can become a major problem for migration planning. The risk of a migration going wrong can stop the cloud being seen as a viable option.

The process of planning is therefore essential in order to overcome this potential reticence and ensure that any financial or service improvement opportunities can be delivered. This involves looking at the overall mix of applications, data and services that will be part of the migration, and then working out the optimum approach to moving those workloads over and in the right order.

From a business continuity perspective, there are two issues to consider. The first is what dependencies there are between applications and data. If one application depends on data from another source as part of its work, then any migration will have to be planned to have the least possible impact on that application functioning. Potential options here include moving these workloads in stages or grouping batches of workloads together so that the amount of potential downtime is minimised.

In the case of staged migrations, there is a “hybrid” phase when some workloads will remain on the original platforms while others will be hosted in the cloud. There is a potential bandwidth issue when applications are ‘chatting’ to each other over a wide area network, but this can be taken into account during the planning phase.

Whichever approach you decide to take around migration, there are ways to reduce the potential time it takes to move over to the cloud. Existing technologies, like replication and snapshot products, can help cut migration times down or reduce them to near-zero if they are used in the right way.
The first option is snapshotting, which is exactly what it says – it provides an image of a server, application or data set at a given point in time. This can be moved over to the cloud platform either over the Internet if there is sufficient bandwidth available, or loaded onto physical media and sent over to the cloud site. Once there, the snapshot can be booted up and then used.

While this approach can reduce the amount of time needed to set up the servers or data, it does create a migration planning issue in that the snapshot will not be updated between the time it is taken and the time it is loaded into the cloud. If the application is a critical one, then taking it off-line while a migration goes on can be difficult to plan for.

The second option is replication – taking a copy of the machine and sending data over to the cloud section by section. This approach does have the benefit of being able to store changes as they take place and then apply them to the cloud. However, bandwidth can be a potential challenge for organisations as they will have to dedicate part of their Internet connectivity to this process. Ring-fencing some of this connection so that day-to-day work can carry on as normal can therefore be a necessary step to take.

It is possible to combine snapshotting and replication methods together. In this case, a snapshot of the server is taken and moved over to the cloud. In the meantime, the server and application can carry on running as normal. Any transactions that are carried out can be captured by the replication engine and then applied to the cloud server instance as part of the hand-over from the primary site to the cloud instance. The window of downtime here is minimal both on the technical side and on the end-user as well, as they can carry on using their applications as normal.

This technique has come from the world of disaster recovery, as it is based on keeping applications available as much as possible during downtime events. The migration from one site to another is essentially just like a fail-over during a business continuity incident. The main goal for this is to ensure that users remain as productive as possible and connected to their application instances, wherever they happen to be hosted.

This model can also be extended and the cloud used for disaster recovery planning as well. Rather than traditional two site implementations, the cloud opens up many more options for organisations that want to improve their approach to data protection and availability. This ranges from simple cloud storage all the way up to full Recovery as a Service plans, where companies can run all their applications and workloads in the cloud for as long as is required.

Recovery as a Service (RaaS) is itself a potential migration plan. For some organisations that don’t want to move over to the cloud straight away, DR represents a great way to dip a toe into the cloud. By using RaaS, they can test their cloud DR strategy and prove that it works while continuing with their existing IT strategies. If and when a disaster event does take place, the cloud DR strategy can then come into play.

When the implementation can prove its value in these circumstances, it does build up more trust in the cloud. Each of these organisations may choose to shift over to using the cloud as their main location rather than their on-site IT assets as well.

The future for the cloud is a bright one, as companies continue to see new ways in which they can exploit this approach to delivering IT services. Planning a migration over to the cloud involves a deep knowledge of what is currently being done within the organisation and what can be achieved in the future. By combining cloud with replication technologies, the migration process can be made easier, cheaper and less risky.