What approach should you take with your cloud migration project? It’s a really important question to ask to ensure a smooth transition towards a solution that will deliver on your business goals.
In the third of our series on successful cloud migration, Alex Drake, an Azure architect in our Cloud Migration Services Team, guides you through the different models you can consider and how to decide which is best suited to your organisation.
Deciding which cloud model is right for your organisation is crucial in any successful cloud migration project – but it’s not the first thing you should be thinking about. If you’re just at the start of thinking about moving your business’s tech infrastructure to the cloud, it’s worth reading my earlier articles on effective planning for successful cloud migration and the questions you need to answer during the discovery phase before you start making any central decisions. The discovery phase is essential to get a comprehensive idea of the existing workloads and IT estate, as well as the project goals and the motivating forces behind them. These will then inform your decisions about the right cloud migration approach to take.
What works will almost certainly be a reflection of the business goals that are driving the project. For example, if you’re aiming for a fast datacentre exit, you might consider rehosting; whereas if you want to drive product innovation you might look at options that involve a hybrid approach and/or mapping out a path for application modernisation.
With that in mind, there are three main cloud models. You will almost certainly end up selecting one, or possibly two, of the following:
Let’s go through these individually.
With Infrastructure as a Service (Iaas) you’re essentially renting space in the cloud. Back in the day you might have rented actual servers on a server farm. Now you’re replacing the machines that you might have on-premises with capacity on other people’s machines. This is typically referred to as a ‘lift and shift’. In layman’s terms, it’s putting the trailer or house you live in on the back of a lorry and putting it down somewhere else familiar; you’re not buying a villa in Spain, learning the language and living like a local.
You’re taking your web servers, your SQL servers, your file servers – the assets we identified during the discovery process – and simply replicating them in the cloud. There aren’t any configuration changes. The only thing that changes is the networking because they're physically located in a different location on a different network. The server is identical: it's the same operating system, it's the same files inside the server, just like it was on-premises.
The tool I mentioned in an earlier post, Azure Migrate, not only does an inventory of all your assets; you can use it to migrate all those assets into the cloud pretty much with one click. Yes, there are tests you’ll want to do, failover and so forth, but the tool can even do that for you.
Pros and Cons of picking Infrastructure-as-a-Service:
Pros
Cons
Cloud native – what we used to call Platform-as-a-Service (PaaS) – involves ‘refactoring’ – the restructuring of existing code – so that, for example, systems become compatible with a new platform, without changing their external behaviours.
PaaS allows you to make use of the full range of tools available on a cloud platform. It also allows you to delegate more of the management to the cloud platform provider. So, with Azure you’d be able to use Azure App Service for your web applications and Azure SQL for your databases. Rather than manage your own virtual machines – which you’d have to deploy, configure and patch yourself – you can let Microsoft do all of that for you. This can be cost effective, given that you’re not either having to pay someone in-house or contracting out the management.
The upside is that you're reaping more of the benefits that the cloud can offer. However, there might be some development time to get your applications fully compatible with the platform and that may add to the migration time as well.
It's important to get as accurate an assessment as possible at the outset of just how much refactoring work is involved. At one end of the scale you might just need to tweak code here and there. At the other end, refactoring is a rebuild in all but name; you may end up recreating your application, more or less from scratch, for a cloud-native environment. This front-loads the project with time and expense, though in the longer term it may well prove a much better option.
Pros and Cons of picking Platform-as-a-Service:
Pros
Cons
Cloud model 3: Software as a Service (Saas)
Lastly there’s Software as a Service (SaaS), which will be a very familiar concept to anyone who licences and uses software in the cloud. You’re essentially getting the entire software package in exchange for a monthly direct debit.
Here your involvement is essentially limited to configuring the software product to your organisation’s needs. Microsoft 365 offers many of the software tools businesses typically use. You might already use MS Exchange Server on-premises; in this case, I’d absolutely recommend looking at Exchange Online. If your file server is pretty modest, for instance it only stores a couple of terabytes of data, you would probably be better off using MS SharePoint for departmental files and OneDrive for personal ones. MS Teams is also a great option to replace an old-fashioned phone system.
Plenty of businesses offering their own application may opt for SaaS office systems and so end up using a combination of SaaS with IaaS or PaaS.
Pros and cons of Software-as-a-Service
Pros
Cons
Rehost - Also known as ‘lift and shift’, rehosting replicates the servers as is, with minimal configuration changes, and runs them as virtual machines in the cloud (IaaS).
Refactor – using PaaS options can cut operational costs associated with many applications. However, to be compatible with Azure PaaS services, some application development time may be needed.
Rebuild – creating a new code base for a cloud-native solution. This can maximise the capability and functionality of the application, but development is often high cost in terms of time and effort.
Replace – use SaaS applications like Exchange for mailboxes, SharePoint for file storage and Microsoft Teams as a phone system.
Once the business goals have been identified and the approach to migration has been chosen, priorities should be defined (which applications are business-critical for instance), and that will then shape the migration plan. I’ll cover that in my final blog in this series.
Want to lay the foundations for a successful cloud migration? Get in touch
Read all of our successful cloud migration series articles:
2 – Discovery