- Support:+971 4 3364 840
- Email:[email protected]
- Address:Level 3, A1, Dubai Digital Park, DSO, UAE
How do you successfully migrate to the cloud?
In an age of rapid technological change, the flexibility and innovative power of the cloud is crucial for securing the future of companies and maintaining competitive advantages. Companies migrating their on prem IT components to the cloud can reap the benefits of the cloud: lower costs, higher speed and optimized processes ensure that companies can concentrate on the innovative design of their core business. Migration, however, is fraught with risks, and rarely does a lift and shift migration work. As an AWS Advanced Consulting Partner we support our customers in migrating to Amazon Web Services (AWS). From the roadmap to the implementation, we help you migrate to the cloud successfully.
AWS Migration Phases
The first phase of the database migration process is preparation. During preparation, you identify the interdependencies between your applications and databases. You also analyze the database workloads to determine the migration categories: from simple rehost (homogeneous) migration to re-architect (heterogeneous) migration. Without completing this phase, you risk running into delayed migration timelines.
In this phase, you use the information gathered during the preparation phase and come up with the migration strategy. A critical aspect of migration planning is rationalizing the information you collected against the 7 Rs of migration: rehost, replatform, relocate, repurchase, refactor, retire, and retain.
Choosing your migration strategy depends on your business drivers for cloud adoption, as well as time considerations, business and financial constraints, and resource requirements. If you want to sustain your current workload in the cloud, choose rehosting. However, if you want to optimize and scale your workloads, consider one of the other options.
After completion of the planning steps, the next step is the actual migration:
- Design: migration pattern, application architecture, operation, cutover plan and process, reusable templates, migration tooling and validation test plan
- Migration: servers, databases, data, infrastructure services, followed by a basic validation test
- Integration: connectivity, application interfaces, operation (backup/restore, …)
- Validation: functionality, performance, reliability, security, compliance
- Cutover: Discussion of the rollback plan
The next is to operate and optimize. Specifically:
- Cost optimization (e.g. right-sizing services, resource reservation, use of spot instances, monitoring and analysis of service usage and costs)
- Application optimization (for example, performance, functional, design)
- Process optimization (e.g. automation of development processes)
- Operational optimization (e.g. operations support systems, infrastructure as code)
What are the 7R's of Migration?
This is the migration strategy for the applications that you want to decommission or archive. Retiring the application means that you can shut down the servers within that application stack. The following are common use cases for the retire strategy:
There is no business value in retaining the application or moving it to cloud.
You want to eliminate the cost of maintaining and hosting the application.
You want to reduce the security risks of operating an application that uses an operating system (OS) version or components that are no longer supported.
You might want to retire applications based on their performance. For example, you might want to retire applications that have an average CPU and memory usage below 5 percent, known as zombie applications. You might also choose to retire some applications that have an average CPU and memory usage between 5 and 20 percent over a period of 90 days, known as idle applications. You can use the utilization and performance data from your discovery tool to identify zombie and idle applications.
There has been no inbound connection to the application for the last 90 days.
This is the migration strategy for applications that you want to keep in your source environment or applications that you are not ready to migrate. You might choose to migrate these applications in the future.
The following are common use cases for the retain strategy:
Security and compliance – You might want to retain applications in order to remain in compliance with data residency requirements.
High risk – You might decide to retain an application because it requires a detailed assessment and plan prior to migration.
Dependencies – You might decide to retain an application if you need to migrate one or more other applications first.
Applications that are recently upgraded – You might want to postpone migrating the application until the next technical refresh because you recently invested in upgrading your current system.
No business value to migrate – There is no business value for migrating some applications to the cloud, such as those with only a few internal users.
Plans to migrate to software as a service (SaaS) – You might choose retain an application until the SaaS version is released by the vendor. This is a common strategy for vendor-based applications.
Unresolved physical dependencies – You might choose to retain an application that is dependent on specialized hardware that does not have a cloud equivalent, such as machines in a manufacturing plant.
Mainframe or mid-range applications and non-x86 Unix applications – These applications require careful assessment and planning before migrating them to the cloud. Examples of mid-range applications include IBM AS/400 and Oracle Solaris.
Performance – You might want to retain applications based on their performance. For example, you might want to keep zombie or idle applications in your source environment.
This strategy is also known as lift and shift. Using this strategy, you move your applications from your source environment to the AWS Cloud without making any changes to the application. For example, you migrate your application stack from on-premises to the AWS Cloud.
With rehost, you can migrate a large number of machines from multiple source platforms (physical, virtual, or another cloud) to the AWS Cloud without worrying about compatibility, performance disruption, long cutover windows, or long-distance data replications.
Your application continues to serve users while the workloads are being migrated, which minimizes disruption and downtime. The downtime depends on your cutover strategy.
This strategy helps you to scale your applications without implementing any cloud optimizations that could save you time or money. Applications are easier to optimize or re-architect when they are already running in cloud because it is easier to integrate to AWS services and manage your workloads.
Using this strategy, you can transfer a large number of servers, comprising one or more applications, at a given time from on-premises platform to a cloud version of the platform. You can also use the relocate strategy to move instances or objects to a different virtual private cloud (VPC), AWS Region, or AWS account. For example, you can use this strategy to transfer servers in bulk from VMware software-defined data center (SSDC) to VMware Cloud on AWS, or you can transfer an Amazon Relational Database Service (Amazon RDS) DB instance to another VPC or AWS account.
The relocate strategy doesn’t require that you purchase new hardware, rewrite applications, or modify your existing operation. During relocation, the application continues to serve users, which minimizes disruption and downtime. Relocate is the quickest way to migrate and operate your workload in the cloud because it does not impact the overall architecture of your application.
This strategy is also known as drop and shop. You replace your application with a different version or product. The new application should provide more business value than the existing, on-premises application, including features such as accessibility from anywhere, no infrastructure to maintain, and pay-as-you-go pricing models. Repurchasing the application typically reduces costs associated with maintenance, infrastructure, and licensing.
The following are common use cases for the repurchase migration strategy:
Moving from a traditional license to SaaS – This removes the burden of managing and maintaining the infrastructure and helps reduce licensing issues.
Version upgrades or third-party equivalents – By replacing your existing on-premises application with the vendor’s latest version or third-party equivalent in the cloud, you can leverage new features, integrate with cloud services, and scale the application more easily.
Replacing a custom application – You can avoid recoding and re-architecting a custom application by repurchasing a vendor-based SaaS or cloud-based application.
Before purchasing, you need to assess the application according to your business requirements, especially security and compliance.
After you purchase the new application, the following are the next steps:
Training your team and users with the new system
Migrating your data to the newly purchased application
Integrating the application into your authentication services, such as Microsoft Active Directory, to centralize authentication
Configuring networking to help secure communication between the purchased application, your users, and your infrastructure
This strategy is also known as lift, tinker, and shift or lift and reshape. Using this migration strategy, you move the application to the cloud, and you introduce some level of optimization in order to operate the application efficiently, to reduce costs, or to take advantage of cloud capabilities. For example, you might replatform a Microsoft SQL Server database to Amazon RDS for SQL Server.
Using this strategy, you might make a few or many changes to the application, depending on your business goals and your target platform.
You want to save time and reduce cost by moving to a fully managed service or serverless service in the AWS Cloud.
You want to improve your security and compliance stance by upgrading your operating system to the latest version.
You can reduce costs by using AWS Graviton Processors, custom-built processors developed by AWS.
You can reduce costs by moving from a Microsoft Windows operating system to a Linux operating system. You can port your .NET Framework applications to .NET Core, which can run on a Linux operating system.
You can improve performance by migrating virtual machines into containers, without making any code changes.
The replatform strategy keeps your legacy application running without compromising security and compliance.
Replatform reduces cost and improves performance by migrating to a managed or serverless service, moving virtual machines to container, and avoiding licensing expenses.
Using this strategy, you move an application to the cloud and modify its architecture by taking full advantage of cloud-native features to improve agility, performance, and scalability. This is driven by strong business demand to scale, accelerate product and feature releases, and to reduce costs.
The following are common use cases for the refactor migration strategy:
The legacy mainframe application can no longer address the demand of the business due to its limitations or is expensive to maintain.
You have a monolith application that is already hindering efforts to deliver product quickly or address customer needs and demands.
You have a legacy application that nobody knows how to maintain, or the source code is unavailable.
The application is difficult to test, or test coverage is very low. This affects the quality and delivery of new application features and fixes. By redesigning the application for the cloud, you can increase the test coverage and integrate automated testing tools.
For security and compliance reasons, when moving a database to the cloud, you might need to extract some tables (such as customer information, patient, or patient diagnosis tables) and retain those tables on premises. In this situation, you need to refactor your database in order to separate the tables that will be migrated from those that will be retained on premises.