The benefit it offers over other methods is the speed it requires to execute. Rehosting can be performed quickly and with the fewest number of changes to existing applications. For an organisation that needs to move swiftly – one that has come to the end of contract with its data centre, for example – rehosting offers a way to migrate and be up and running again in very little time. The reason for this is that fundamentally it entails taking everything that is running on one operating system and moving the whole thing straight into the chosen cloud system without changing too many parts of the puzzle.

Possible Pitfalls

There are trade-offs for this speed and simplicity of execution, however. The first is making the move and then not fully utilising or exploring the native features of the new environment. If these considerations are not taken into account and accommodated, it is possible to end up with higher costs but no additional value than before the shift.

Before contemplating a rehosting scenario, it’s also important to really understand the technologies that are going to be used. If there are such elements as storage area networks with shared discs, for instance, it may not be possible to rehost. In this case it would then be necessary to consider the options with the individual components.

Disaster recovery (DR) strategies should be considered too. If a business recovery plan requires the use of underlying technologies and procedures, such as the replication of storage area networks to another data centre, consider how those possible scenarios would play out in the cloud.

A common scenario in data centres today is having a highly available cluster with nodes close together in the same physical location. Perhaps there is another cluster or single node in another data centre, at a different physical site. If a DR situation occurs, it is possible that the clustering software wouldn’t run as-is in the cloud due to some of the limitations and that a single node cluster may need to be configured to ensure fast recovery. When fully migrating, you would need to consider changing the clustering software to something that is more cloud native.

This could also entail a change of the technology underlying it.

Another consideration is licensing, as many vendors have end user licence agreements that restrict where their software can run (for example, it is often the case that software can be run on bare metal with certain numbers of CPU/cores, but then that licence or EUA [end user agreement] continues on to virtualisation and still counts the physical cores, which could be substantial in the cloud or even on in-house virtualisation). It may be required to negotiate new licensing agreements or look to purchase licences via the cloud provider or to invest in changing technology.

Use Cases

Depending upon the skillsets and experience of the IT team, rehosting could be a similar operation to earlier migrations to virtual machines. Perhaps an organisation has previously taken a group of physical machines and organised them into a VMware cluster. A lift and shift scenario would require the same level of skill, unlike replatforming or refactoring, which utilise more cloud-native components and may be beyond the team’s capabilities.

And outside of a possible DR scenario, an organisation may be simply facing end of life on a specific piece of hardware. If the preference is to avoid the significant capital expense of replacing that hardware or having to rely on a downgraded style of support for it – from a third-party vendor instead of the original equipment manufacturer (OEM), for example – rehosting could be an appropriate alternative.

Seamless Lifting and Shifting

Once rehosting has been selected as the migration path, there are steps to ensure the procedure goes smoothly:

  • Get buy-in – engage with the stakeholders early to explain the benefits of the process and ensure any fears or concerns are addressed and assuaged.
  • Plan – understand the environment and complete a thorough audit. This process may reveal other Rs that can be utilised, such as the retirement of a redundant piece of kit. As with physical house moves, there is no point in moving something that is no longer needed.
  • Lay out the cloud – the cloud moves quickly, so it’s important to consider potential activity and need. While no one can predict the future, leaving enough networking capacity gives room to move and preparation for different eventualities. Consulting or engaging a cloud specialist with knowledge of scale is always advisable here.
  • Select the cloud provider – considering the equipment and services already in use is important. Many cloud service providers, as well as hyperscale public cloud providers like AWS and Azure have good tools to help with planning and tried and tested blueprints.
  • Use cloud-native tools – these can be low cost or free and they work well with the end solution.
  • Start small – as proof of concept (POC), begin with a couple of small workloads that aren’t business critical to get a handle on how the migration will be run. If there is a huge environment to migrated, break it down into waves.

Test, test and test again…