There are many paths which can be taken on a company’s move to the public cloud. Deciding how to migrate to AWS should be a process that focuses on each individual workload, rather than trying to find a single solution to be used across the board.
What is Cloud Migration?
Cloud migration is the process of moving data, applications, or other business elements to a cloud computing environment such as AWS. One common model of cloud migration is the transfer of data and applications from a local, on-premises data center to the public cloud via lift and shift or (our preferred method) Migration as Code.
There’s no one “right way” to migrate, however, once you’ve assessed your workload, there are a number of paths you can take. The path that you choose depends on a number of factors, including time constraints, level of engineering effort, and resource requirements.
The Four Cloud Migration Strategies
1. Refactoring for Cloud Native Design
Refactoring for cloud native design is the path that requires the most forethought, planning, engineering effort, and overall time to implement, but benefits from being the most stable solution wherever possible.
2. Repurchasing
A solution that pairs automated pipelines and processes with ready-to-use infrastructure templates.
3. Replatforming
A partially automated process that uses Infrastructure as Code methods, but also relies on manual intervention from system administrators.
4. Rehosting
The traditional “lift and shift” method of migration that offers a block-for-block match to the on-premises infrastructure.
Ready to learn more about these four paths and find the right path for your workloads? Download our whitepaper today!
Here’s a teaser:
There are many paths which can be taken on a company’s move to the public cloud. Deciding how to migrate to AWS should be a process that focuses on each individual workload, rather than trying to find a single solution to be used across the board.
Key to these decisions are factors around:
- Level of engineering effort
- Time constraints
- Licensing restrictions
- In-house vs. Commercial-Off-The-Shelf (COTS) software
- Resource requirements
With each of these limitations in mind, there are a few paths that should be assessed for viability as you decide to make your migration plans. Onica always recommends assessing these paths in this order, as they are organized from most-to-least ideal.
If a path is not possible, scrap it and move onto the next. It’s important to remember that these paths are not interchangeable. Rather you should carefully consider everything before eliminating a path from your process.
Refactor for Cloud Native Design
Refactoring for cloud native design is the path that requires the most forethought, planning, engineering effort, and time overall to implement, but benefits from being the most stable solution wherever possible.
Refactoring existing applications as they are currently used and written allows for the option to fully automate the build/test/release cycle processes (leveraging more modern CI/CD pipelines), and ensures that old workloads get updated to modern processes and architectures.
The opportunity to take an old, problematic application and re-write it to be cloud-native may include serverless options, the opportunity to incorporate native backup and restore solutions, disaster recovery or highly distributed design and architecture, and anything else that would allow you to benefit from the services provided by the public cloud.
Often this even includes moving away from existing data structures toward a more modern database engine, providing an opportunity to escape expensive licensing by choosing open-source standards, etc.
Planning around this requires extensive research to identify and resolve automated processes around every aspect of the workflow. Concepts common to this model would require DNS automation, service discovery, blue-green or canary deployment, centralized logging, version control workflows, artifact creation and storage, etc. —the list goes on, and there are a lot of things to think about.
A high level of maturity is strongly recommended for making these decisions, whether that’s internally or through the use of a trusted partner. This is the essence of “Migration as Code” and is the primary way Onica operates its migrations.
This is not necessarily always an option, however. The major factors that play into this option are the obvious ones: time and money. An organization may not have the engineering resources or maturity to implement a custom, cloud-native solution to an off-the-shelf application currently in use today.
Even in-house applications may not be worth refactoring within the given time, or other business priorities may make it an impossibility. Without available engineering resources, the company is left in a position to hire new talent with those skills, train their existing workforce and expect slower delivery of the solution, or simply choose an alternative path.
Automate with Cloud-Native Architecture
Ideally this solution is also paired with CI/CD deployment processes to solidify process and automate concepts inherently throughout the organization, allowing for simpler onboarding processes for other applications that can follow this model.
Most often this process will include several phases of pipelines, will perhaps make use of baseline machine images for ready-use in infrastructure templates, and will leverage a deployment mechanism for applications onto these machines post-creation.
Straying a little further away from a full refactor is the idea of taking the same applications and mindsets, but migrating them with more cloud-native architecture. This means using automation from start to finish, codifying all infrastructure, and designing with the benefits of the public cloud in mind for availability and disaster recovery.
An example of this would be to take a workload in your data center today and write functional code to deploy its infrastructure and application installation into the cloud in such a way that it’s highly available (self-healing with autoscaling groups and effective health-checks).
Want more information about your best cloud migration strategy? Download our Whitepaper, Optimizing Your Cloud Migration: 4 Paths to Consider for a Successful Move to the Cloud today!
