Not to be confused with "wham-bam" methods :) This approach, well-known as “rehosting” too, is about applying minimum changes to your infrastructure, no redesigning, and moving simple as it is. Yes, it's faster than any other strategy, but it definitely is not the best idea for projects with long-run plans, a complex infrastructure, multiple integrations, and massive databases. If you need a stable app for 100% of your time, it's better not to risk using this strategy. To get the minimal migration time, you'll have to avoid the thorough study of the best solutions for each part of your application. It may cause you complications in the future.
But anyway, if you do migrate on the basis of rehosting strategy, the following edits of your app will be much easier to implement by means of the cloud tools.
Replatforming strategy assumes that your team makes some partial changes for your infrastructure to make it fit better to the cloud, but not changing things up completely. This approach requires extremely attentive planning and active integration testing. Your new scaling tools may work for your future cloud platform, but require those formats of input that your old database can't produce. That's the typical pitfall waiting for unaware developers.
With this strategy, you may waste a lot of resources on understanding that you are still right in the middle of nowhere: with a non-cloud basis and a few fancy features of the cloud that don't benefit you.
Refactoring or re-architecting
This strategy assumes you rewrite the whole app to become cloud-native. It takes time and requires a separate qualified team or an experienced Senior like from Dysnix to reinvent the whole app by means of cloud instruments. But you'll get all the expected benefits from the cloud incarnation of your app: fast scaling, nearly effortless automatization, improved security, and so on.
Instead of rewriting your app, you simply buy another one, cloud-native, that's similar with similar functions. That's likely not the best strategy for large businesses, but quite a trick for startups and those companies that aimed at quick hypothesis check and growth.
If you need to change your cloud provider, you'll build up your own cloud-to-cloud strategy. Typically, each service of one vendor has its analog for another. Be ready to choose an alternative for each part of your app and choose the right time for migration.
Reverse cloud migration
Yes, sometimes projects go back to on-prem because of legal, security, or business reasons and restrictions. While doing that, you should take over all the support that the previous cloud provider gave you.
Cloud migration services and tools
Each provider is literally boiling over with utilities, tools, and services that help companies build up their apps in a cloud environment.
Basic set of tools
The most popular tools with proved efficiency and reliability we offer to use for the implementation of your approaches to cloud migration:
Using cloud-agnostic orchestration tools (like Kubernetes) let you create an additional level of abstract that's minimally tied with the underlayer infrastructure (both for on-prem or a cloud company). No matter what kind of infrastructure you had previously and what you want to reach in the cloud, K8S can make it possible.
Velero is one of the best tools for migration of Kubernetes clusters. It creates reserve copies of resources, clusters, and persistent data, and deploys them successfully in the new environment of literally any type of underlayer infrastructure.
While migrating with Kubernetes, these two tools are typically enough for the most uncomplicated projects. If your project is from the last mentioned, you shouldn't worry, as each app can be migrated with a separate set of dedicated tools.
Tools for migration from on-prem environments
If you're moving from on-prem environments, we always recommend migrating everything to the SaaS level. For most services, there are multiple analogs. For example, Amazon offers AWS Database Migration Service for simple migration to RDS. This is a similar service you can find at Google — Google Cloud Database Migration Service — and with many other cloud providers.
In our future articles, we'll dive deeper into the details of migration to different cloud providers and the problem of the fast scaling setup after moving to a new environment. Additionally, we plan to write about Block Storage, how to establish monitoring for migrating and migrated projects, and DevSecOps for cloud projects.
CTO and Co-founder at Dysnix
Brainpower and problem-solver, meditating and mountain hiking.