I often interact with Cloud Architects as a trainer/consultant and a frequent topic under discussion is migration. So, I decided to use the APNIC Blog platform to shine some light on this interesting topic.
Importantly, migration is a one-way process (non-reversible) unlike site recovery where you can always fail back to the primary site after failing over to the secondary site. In cloud computing, migration refers to moving your workloads, assets, apps, databases, resources, virtual machines, and so on, from on-premises (on-prem) to the cloud without compromising any functionality limitations. Your organization may be completely migrating to the cloud (leaving nothing behind in your on-prem data centre) or partially migrating where you maintain a hybrid environment and only move specific assets to the cloud.
Let’s discuss some interesting points regarding cloud migration.
Can I migrate all resources, assets, workloads, apps, and databases to the cloud?
The answer is no. You can’t migrate all types of resources to the cloud because the cloud platform environment is different from an on-prem environment, which means not all protocols, interfaces, workloads, and so on that work smoothly in on-prem can also function the same way in the cloud. So even if you are able to migrate the un-supported resource, it won’t be functioning as desired. Therefore, you need to use specific virtualized tools to make an assessment of your resources as a pre-migration step that guides you on what can be migrated and what can’t.
Should my organization migrate to the cloud?
If your organization is considering using the cloud for the first time and you are not really sure if it is a justified decision or if you need to make assessments whether your workloads are cloud adoptable or not, then you can take advantage of frameworks offered by the cloud operators. These frameworks include parameters like business justifications for cloud migration, assessments of the existing resource estates, time frame, training requirements, pre-migration steps, and more, to make it a smooth process for your organization and provide advice/recommendations if it is really worth migrating to the cloud.
What are the pre-migration steps?
Assessment and discovery are the two main steps before migrating your workloads to the cloud. Cloud operators enable their customers to download a variety of virtual appliances (tools) and let them run in their on-prem environment that does the discovery and assessment. Discovery will identify the potential workloads/assets/resources/virtual machines/apps/databases in the on-prem environment that can or can’t be migrated, keeping in mind their size and compute power parameters.
On the other hand, the assessment phase will generally classify all assets to be migrated into four categories:
- Cloud-ready — Assets that don’t require any work and are ready to deploy in the cloud without worrying about their functionality or operational efficiency. This is an ideal category that makes customers’ lives easy.
- Minor changes required — This category includes assets that need to be tuned to get it working in the cloud smoothly. It’s mostly apps that need their code optimized to overcome any minor issues before operating in the cloud.
- Major changes required — Resources that require significant changes in architecture before they can work due to the cloud platform being different from the on-prem environment. Not every protocol and/or interface is supported in the cloud, so if your workload uses any non-supported protocols then you may have to look at finding a replacement or compatible solution and you may end up rearchitecting the given resource/solution to make it work. Frameworks like Well-Architected Framework provide guidance in these cases and are often used by major cloud operators.
- Start from scratch — This category of assets is the worst-case scenario from a migration perspective and requires redesign and often ‘starting from scratch’ logic. This category usually relates to legacy solutions or proprietary (vendor-specific) products that can’t be optimized or rearchitected in the cloud and requires reinventing or rebuilding to make resources work in the cloud.
How is migration different from site recovery?
Site recovery refers to your replicated backup site where you can fail over when your primary site suffers from an outage of any kind. This way, you continue to keep your production or business running from a secondary site. Once your primary site is up and running, you can always fail back to it. You can also have multiple secondary sites if desired. Organizations can also have a secondary site in the cloud to provide redundancy for their on-prem (primary) site.
Although migration initially uses site recovery steps to build a site in the cloud (just like building a secondary identical site for site recovery), once the secondary site in the cloud is up, tested, verified, and audited, you can then sunset your on-prem site. At this point, the cloud becomes your primary (and only) site, and you can’t revert to an on-prem site due to the fact that migration is a one-way process.
Will there be an outage during migration?
Yes, an outage is expected during the migration process and live resources suffer the most. During database migrations, you can expect a cut in the data so always check for lost/missing data and recover it before tearing down your on-prem databases. Some cloud operators offer both online and offline data migration methods/tools to facilitate their customers, but a data cut is inevitable in both cases.
I hope you enjoyed reading this blog. Please keep learning and broadening your knowledge using the resources and training offered by APNIC.
Azhar Khuwaja is a Telecom/IT Trainer with over 20 years of industry and training experience.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.