How to select the best starting point when migrating to public cloud
Notice: Trying to access array offset on value of type null in /var/www/interactive.com.au/wp-content/uploads/cache/af449b902f134ca9d3e4e7ecfd9f3ec003e2da77.php on line 20
Notice: Trying to access array offset on value of type null in /var/www/interactive.com.au/wp-content/uploads/cache/af449b902f134ca9d3e4e7ecfd9f3ec003e2da77.php on line 21
Insights•6 minutes read
How to select the best starting point when migrating to public cloud
5 things to be carefully assessed when mapping out your cloud migration journey.
Spoiled for choice
Talking with IT leaders about their cloud migration plans, we find that one of the biggest hurdles to get over is picking suitable candidates.
There are many factors in selecting whether and how to migrate each of the many applications you are running – including compliance and technology limitations. But apart from that, it’s important to categorise each of your applications according to their ‘migrate-ability’. Gartner calls these categories the ‘Rs’ of assessing applications for the cloud.
The fact is your end goal may be to move your IT environment to the cloud – but you are probably going to need to make some compromises on how to get there. Here’s a short guide to the pros and cons of five most frequent options.
Rehost – or ‘lift and shift’
Rehosting (also known as redeploying) an application is possible when it is compatible with a specific cloud infrastructure – or IaaS. It is certainly the fastest way of migrating an application and has the least impact on your operations and users. It can be useful for moving applications off ageing hardware infrastructure, or from private clouds when a lease runs out.
While least risky, it is typically the most expensive way to use cloud – because you’re not taking advantage of all the benefits cloud can bring. Public cloud providers are continuously evolving new services which can be hard to take advantage of if you lift and shift legacy applications. Yes, it may be a quick stepping stone, but it can also make your applications more susceptible to security breaches as you are essentially moving legacy infrastructure into a new environment. For this reason, it is essential all components are migrated securely.
There may be other use cases for Rehosting that make sense from an operational and financial standpoint. You might have a legacy system that is no longer used, but needs to be accessible due to archiving reasons, as an example. It doesn’t make sense to maintain the hardware for such a system in the long run. Lift and Shift is perfect in this scenario, assuming you leverage tags, automation scrips and appropriate storage types to ensure it is cost effective. (refer to our article on cost optimisation for more information)
Refactor – or ‘renovate’
Your applications are made up of multiple components in addition to their specific code. Those using traditional database software like Linux or Microsoft SQL Server could candidates for ‘renovating’ by moving these systems to PaaS (platform as a service). Simply put, it’s a database service as opposed to running a virtual machine.
The advantage of refactoring is that you can use the same code – for example, your SQL queries will still work! Plus, your cloud service provider will manage the underpinning service: patching, upgrading as well as providing the relevant infrastructure to run it. It can also reduce your software licencing costs. All you need to do it take care of your own data – and your database administrator won’t need any retraining.
However, not all public cloud providers run the same native components; while their core may be the same, they may have disparity across features and security. For example, AWS may offer an equivalent SQL PaaS, but it may differ by running a different macro, say, then the Microsoft Azure version.
Rearchitect – or ‘rebuild’
While refactoring applications typically requires some tweaking, it is significantly easier than rearchitecting them for migration. If refactoring is like renovating a house, then rearchitecting is more like rebuilding it!
To realise the full benefits of the public cloud, it may be necessary to completely redesign some applications before moving them. This would done by utilising cloud native resources and services. You keep the essential core of the application but reconfigure it. You also need to consider aspects including resiliency, backup and disaster recovery – because you are essentially changing the entire paradigm on which the application was constructed.
One disadvantage is that rearchitecting applications calls for more upfront costs. On the other hand, it offers big since you are investing in easier ongoing management, maintenance and resilience. Because of this, the rebuilt application will be cheaper to run in the long term even having more initial work and cost.
Replace – or go software as a service (SaaS)
Sometimes it’s simply not worth the effort of migrating old applications to the cloud, so you are best migrating your users to a new application instead. One example is Office 365 – the obvious migration is to Exchange Server. Similarly, your software vendors may be offering SaaS rather than on-premises options – and these may be offered by one or more public cloud service providers.
Finally, once you’ve considered and assessed all your portfolio of applications for cloud migration, there will be some that won’t make the cut. You will be unable to justify even a ‘lift and shift’ or renovate in the cloud, because these are programs that are so out of date or very rarely used.
Your choice is to either just leave them puttering away on premises or to rehost them on infrastructure as a service (IaaS) – then just use them for an hour a week, or a week a year, then turn them off. If you decide to retire them, remember that they may hold data that you are obliged to keep available for seven years in case of an audit. This is also where the public cloud can help in relation to archiving and storing data.
The above considerations should be applied at the application or system level. No one expects an organisation to rearchitect every single application in one go! In reality, you may have to utilise multiple methods at the same time. Your plan may also involve using a number of these methods over time. You may choose to lift and shift an application in the first instance, and then choose to rearchitect it once it’s in the cloud, as an example.
How we help
Understanding all your different migration options can be daunting unless you are familiar with all different ‘flavours’ of cloud and the service offerings of the different providers.
Certainly, if you are pursuing a multi-cloud strategy, possible options may appear similar – even if some could end up becoming problematic or costly down the track.
At Interactive, we have rigorous methodologies for every phase of cloud migration and ongoing management – from assessments of the resources you want to move and strategies for achieving migration through to post-migration audits and optimisation services. Our team of experts can assist you in every walk of your cloud journey, no matter if you are just starting or looking to optimise!
Need help with your cloud adoption?
Interactive can help ensure a simple, straightforward and secure migration to any cloud.