We’ve been on a cloud frenzy this past month.
We’ve put out loads of content, a webinar on why to lift and shift, and even have an eBook for you to download (for free)!
In our previous FAQ on all things cloud, we looked at
- When to start your cloud migration,
- How to assess whether your organisation is ready or not, and
- How to best select cloud providers.
This time, we’re unpacking what exactly it is that you’re lifting and shifting, whether or not you can move legacy applications, and how long moving to the cloud usually takes.
Senior Cloud Architect, Brendon De Meyer helps us unpack these pressing questions on cloud migration.
What should I focus on in my first lift and shift?
Doing a lift and shift should never be your approach to modernisation. Instead, you need to treat it as an approach to risk mitigation.
When you talk about lift and shift, you’re typically looking at two major factors:
- Compute footprint, which are your virtual machines and virtual servers, and
- Any sort of latent storage that you might need.
Those are the ideal candidates for a lift and shift.
When you start changing the architecture, you have started the modernisation process. For example, if you’re moving from an on-prem SQL server to a managed SQL server in the cloud, it’s not technically lift and shift anymore. It’s modernisation, because you’re taking things one step forward.
Doing a lift and shift should be treated as a like-for-like in terms of your on-prem ecosystem with the idea that you’re going to save costs on your infrastructure spend, reduce your infrastructure risk and get a quick launchpad to modernisation.
Can I lift and shift legacy applications?
You can. It is possible. About 99% of all workloads can be left lifted and shifted.
But, there are a number of pitfalls that you should be aware of:
- You’re going to run into some potential CPU issues.
- You’re going to run into some OS support issues. The hyperscalers don’t support the entire back catalogue of all vendor operating systems.
- There might also be some odd networking requirements, i.e. parts that communicate differently than they would typically in the cloud.
You want to ask yourself these questions:
- Is the right OS available or do you need to go through an update process?
- Do you have any constraints around your CPU and chip architecture?
- Are there any issues around networking? Has anyone been hard-coding TCP/IP addresses?
How long does a lift and shift typically take?
It is possible to do it in a matter of days with the right consultancy, the right mix of infrastructure-as-code, along with a quick build. You can potentially have applications running in the cloud on the same day, depending on a number of factors.
A lift and shift typically consists of 80% preparation and 20% watching data move. Moving the data is relatively quick and the size of the dataset will usually determine that.
However, the bulk of the effort is spent doing the due diligence prior to understanding what that application needs to look (and live) like in the cloud.
We’ve seen projects range from 3 months to 12 months. Purely based on:
- The size of the estate,
- The number of VMs
- The complexity involved in that preparation.
- Governance requirements i.e. Are you actually allowed to move that data?
- Getting your vendors on board, because any changes (firewall rules, URL registrations, etc.) end up taking time and creating bottlenecks.
From day one to planning before you get your first workload in the cloud, look at three months, realistically. If you’ve got a larger estate, it’s going to be a multi-year project.
Expand Your Knowledge on the Cloud
As we answer more and more questions on cloud migration, we discover that slow, deprecating and risky data architecture affects your ability to innovate and scale.
Take the time to consider the unlimited nature and vast capabilities of the cloud and the potential that it presents your organisation.
Learn more on our blog, get our eBook, and show Brendon some love!
