The No-Nonsense Guide to Migrating On-Prem Deployments to the Cloud

Cloud migration is the classic ‘buy vs. buy’ dilemma, except in this context, it takes the form of ‘expand vs. migrate.’ Once your on-premises workloads encounter physical limits and operational challenges, the next logical step is to scale up your infrastructure and move to the cloud. 

Nearly 50% of organizations are cloud-native or fully cloud-enabled. Of those that aren’t, over a third will migrate from legacy systems to cloud-based tools by the end of the year. But among the benefits of cloud migration lie many common pitfalls. 

What is cloud migration?

One of the goals of cloud migration can be moving IT infrastructure, applications, and data from an on-premises environment (a physical data center facility) to a cloud computing platform. Upon migration, the infrastructure is replaced by a remote data center or a set of managed cloud services, and a dedicated private cloud solution is leased from a third-party service provider. Alternatively, migration can happen to managed cloud services provided on a public cloud owned and operated by a Cloud Service Provider (CSP).

Migration can happen at various levels, resulting in partial or complete data movement. In most cases, this results in a hybrid cloud architecture, where some infrastructure elements are migrated to the cloud and the rest of the infrastructure stays on-premises.

Why you should migrate from on-premises to the cloud?

There are many benefits of migrating to a cloud infrastructure versus sticking with on-premises:

• Lower capital expenditure (CAPEX): Building and maintaining an on-premises data center typically involves significant upfront costs. 
• Lower real estate costs: An expanding on-premises infrastructure entails high real estate costs especially when you factor in fault tolerance and disaster recovery.
• Effective cost management: Buying servers, power, cooling, and backup systems are important considerations for hardware longevity, performance, and availability.
• Better security: You can unify your workload visibility with a multi-cloud security strategy to complement your migration journey. 
• Flexibility: On-premises infrastructure cannot scale up or down automatically depending on the application load or user traffic, unlike the cloud. 

Source

What are the different cloud migration strategies?

Here are the four most common cloud migration strategies.

1. Rehosting

Also called ‘lift and shift,’ rehosting involves moving an application from the on-premises hosting environment to the cloud without changing its architecture or functionality. It is a relatively quick and risk-free approach to migrating any application.

2. Replatforming

Replatforming is a modified version of rehosting, also known as ‘lift, tinker, and shift.’ In this case, some portion of the application architecture is tweaked to leverage the cloud environment. 

3. Refactoring

Refactoring is a more intricate migration strategy involving significant changes to an application’s architecture to enable deeper integration with cloud services. One of the common examples of refactoring is moving to serverless architecture to save on the costs of renting dedicated servers and improve scalability. Often, many additional steps need to be taken like rethinking security strategies or configuring routing for low latency.

4. Replacing

The replacing migration strategy best suits scenarios where you find a better alternative to in-house developed applications. In this case, you can discard an in-house application hosted within an on-premises environment and replace it with a cloud-based SaaS or PaaS offering. This strategy has a lot of risks and requires a lot of pre-planning to ensure that both applications are compatible in terms of data and functionality.

How to migrate from on-premises to the cloud

Cloud migration is not a ‘one size fits all’ initiative. It is a complex project that requires significant planning with a mix of strategies, followed by careful technical execution.

Here is a seven-step framework you can follow for a successful cloud migration.

Step 1: Set goals for migration

At the onset, define your business needs and KPIs for migration. Ideally, you should define these needs objectively in terms of the business metrics, such as:

• % OPEX reduction: The percentage of operational expenditure that will be reduced after cloud migration. 
• % TCO reduction: The percentage of the Total Cost of Ownership of all assets after cloud migration.
• Duration: Estimated duration for the migration process to complete.
• Cost of migration: The cost of undertaking the migration process, including CAPEX, OPEX, and external costs, such as hiring a consultant.

Apart from these metrics, there are also application-level technical KPIs related to the functional and non-functional requirements. You should measure these KPIs within the existing on-premises environment and record them to establish a benchmark for post-migration performance.

Step 2: Take stock of inventory

This step involves identifying and auditing all the digital and physical assets and listing them based on the following broad categories:

• Hardware.
• Software.
• Source code.
• Third-party applications/software/library licenses.
• Security vaults.
• Data stores (including all live databases, secondary data infrastructure, metadata repositories, and data archival systems).

Source

Step 3: Identify vendors and needs

Now, you can identify vendors and migration strategies that align with your goals and KPIs. There are two exercises you can do as part of this step:

1. Shortlist the preferred vendors

Perform a detailed technical analysis of data center and CSP vendors to check their compliance level in supporting each inventory item per its technical specifications. The vendors who offer the maximum compliance at the least estimated cost, considering a favorable service level agreement and legal terms, can be shortlisted as the preferred vendors.

2. Build the differentiated deployment model

With your existing on-premises application deployment architecture as a reference, build a superimposed deployment architecture considering the vendor’s environment. This exercise helps identify application workloads that differ between the two deployment architectures and sets the migration strategies for addressing them.

Step 4: Create a migration plan

From this step onwards, migration planning becomes an intensive technical brainstorming process. Based on the identified vendor’s capabilities and the migration strategies, you can create a detailed migration plan document for each workload, with emphasis on:

1. Data migration.
2. Compute and storage migration.
3. Hosting and configuration migration. 
4. Network configuration migration.
5. Cloud security tools, configuration, and hardening migration.
6. Procedure for transitioning application traffic from on-premises to cloud workload.
7. Post-migration KPIs.
8. Migration rollback procedure.

In case of migration strategies other than rehosting, you should define additional documents, including:

1. The architecture of migrated applications.
2. High-level/low-level design.
3. Test cases for verifying application requirements.

Additionally, you can assign a criticality score ranging from one to five to all workloads, with one being the least critical score from a business and customer standpoint. This ensures business-critical workloads are handled as a matter of priority, and it will help you in launching the pilot. 

Step 5: Develop a pilot

It is best to initiate the migration process on a small scale to avoid risks of application downtime or user experience setbacks. For this purpose, you should identify workloads with a criticality score of one and sequence them for migration. 

This step should also document KPIs and test cases to decide whether the migration was successful. In case of unexpected results, the rollback procedure defined in the detailed migration plan should help you mitigate the risks.

Step 6: Optimize post-migration performance

You’ll continuously evaluate and tweak the migration process, and this step comes into the picture when all the workloads have been migrated. Now, the migrated system is kept under observation, and you can evaluate your overall business and technical goals.

This step does not involve any prior documentation at the migration planning phase. However, as a best practice, you can maintain a log during the migration execution phase to capture the continuous optimization cycles and all the tweaks and changes performed on the migrated workload.

Source

Step 7: Declare the migration completed

By step seven, you have performed all the necessary optimizations on the migrated application to meet the goals and KPIs defined in step one. As a final step, you should document the post-migration checklist, which includes key procedures such as:

• Backup and disaster recovery.
• Regulations and compliance checks.
• Real-time security monitoring between on-premises and cloud (in case of hybrid cloud).
• Disbandment/decommissioning of the on-premises infrastructure.

Centralized Multi-cloud Setup Quickly and Easily with Control Plane

Real-world cloud migration projects have many complexities and risks. Depending on the architectural complexity, it can take a few months to streamline DevOps and maintenance operations on a migrated workload. An Internal Developer Platform (IDP) like Control Plane removes the complexities of cloud migration by managing your entire infrastructure in one codified infrastructure backed by all the major CSPs such as AWS, Azure, and GCP. Control Plane makes the migration process cloud-agnostic by leveraging cloud-native architecture.
Interested in enabling streamlined developer self-service for your team? Request a demo today and see if the Control Plane platform is a good fit for you.