Identify workloads to be migrated to the cloud. Decide for each item to lift & shift, make cloud native, or retire. Lift & shift approach mean to rehost, replatform, or relocate. Taking a cloud native approach involves either refactoring or repurchasing.
Migration Strategies
Lift and shift migration is the fastest migration mode. the most common migration strategies (rehost, replatform, and relocate) that are often utilized to lift and shift.
Rehost: Rehosting is fast, predictable, repeatable, and economical, where the server or application is lifted and shifted from the source on-premises environment to the cloud. Minimal changes may be made to the resources during the migration process.
Replatform: The strategy involves upgrading the platform as a part of the cloud migration project without changing the application architecture. You can decide to update your OS or application to a newer release as part of the migration. When using the replatform migration strategy, you may need to reinstall your application on the target environment, which triggers application changes. This requires thorough testing on your application after replatforming to ensure and validate its post-migration operational efficiency.
Relocate: When applications are deployed using containers or VMware appliances in your on-premises datacenter, you can move such workloads to the cloud using Relocation, allowing you to move hundreds of applications in days. minimal effort and complexity, only requires a little upfront developer investment or a test schedule since it provides the agility and automation you expect from the cloud. You need to determine existing configurations and use VMotion or Docker to relocate your servers to the cloud.
Refactor: The refactor method involves rearchitecting and rewriting: an application to make it a cloud-native. In refactoring, you change the application to a more modular design, such as from monolithic to microservices. Refactoring requires more time and resources before migration to recode the application and archi tecture.
Repurchase: Some IT resources will require new cloud-compatible license or release. You may decide to repurchase the existing solution or replace it with another one.
Retain: You might encounter a few applications in your on-premises environment that are essential for your business but unsuitable for migration. In such situations, your application cannot be migrated to the cloud but you can continue running it in your on-premises environment.
Retire: While migrating to the cloud, you may discover the following: Rarely used applications Applications consuming an excessive amount of server capacity Applications that may not be required due to cloud incompatibility In such a situation, you can retire the existing workload and take a fresh approach that is more cloud native. Hosts and applications that are commonly suited for retirement include the following: On-premises servers and storage for disaster recovery purposes Server consolidation to resolve redundancies Duplicate resources due to mergers and acquisitions Alternative hosts in a typical high-availability setup Third-party licensed tools (such as workload monitoring and automation) that are available as in-built capabilities in the cloud
Possible Risks
Data loss and leakage: During the migration, sensitive data can be exposed to risks if no properly enctyyned and managed. Ensuring data integrity and security during the migration process is crucial to prevent data breaches.
Downtime: Migration can lead to system downtime, affecting business operations. Planning and executing the migration is phases or during off-peak hours can minimize the impact on business continuity.
Cost overruns: Without the proper planning and understanding of cloud pricing modes, ganizations can face unexpected costs. It’s essential to have a clear roadmap and budget fur the migration process.
Performance issues: Applications may not initially perform as expected in the cloud due te differences in the architecture or unforeseen enmpatibility issues. Rigorous testing and opt mication are necessary post-migration
Skill gaps: The lack of expertise in cloud computing within the organization can hinder the migration process and future operations. Investing in training and possibly hiring specialists can mitigate this risk. Interoperability and integration challenges: Ensuring that existing systems and applications work seamlessly with cloud services can be complex, requiring robust integration and testing strategies
Compliance: Adhering to industry regulations and compliance standards can be challenging in the cloud environment, especially if the organization operates in a highly regulated sector.
Vendor lock-in: Relying too much on a single cloud provider’s technologies and services can lead to difficulties in switching providers in the future, potentially affecting flexibility and cost-efficiency.
To reduce the risks associated with cloud migration, it’s always recommended to take a phased approach when migrating applications to the cloud.
Discovering Portfolio & Workloads
Portfolio discovery identifies all the IT assets involved in your cloud migration project, servers and applications, their dependencies, and performance metrics.
It is essential to understand that your discovery landscape will depend on various factors
- What has already been migrated to the cloud?
- What application dependencies are there, along with resources and assets
- What are the business drivers for cloud migration?
- What is the estimated duration for the entire migration project?
- How many phases is the migration process going to happen in?
Performing thorough portfolio discovery helps in answering questions such as the following:
- Which applications, business units, and data centers are good candidates for migration?
- How suitable are the applications for migrating to the cloud?
- What are known or possible unknown risks associated with migrating an application to the cloud?
- How should the applications be prioritized for migration?
- Which other IT assets is the application dependent on?
- What are the best migration strategies for the application?
- Is it better to have some downtime for the application than to perform a live migration due to its dependencies and risks?
Components Include:
Storage: Identifying the amount and type of data stored, such as databases and files. For ex ample, discovering whether an application uses 1 TB of block storage for database operations.
Networking configurations: Understanding network topology, including subnets, firewalls, and load balancers. For instance, identifying that an application is spread across multiple subnets with specific firewall rules.
Security and compliance needs: Documenting security policies, data protection mechanisms, and compliance requirements, like identifying that an application must comply with GDPR and use encryption for data at rest.
Application release frequency: Knowing how often new releases are deployed, such as deter mining whether an application follows a bi-weekly release schedule.
DevOps model: Understanding the integration and deployment processes, tools used, and automation level. For example, noting that the organization uses Jenkins for CI/CD with a high degree of pipeline automation.
Escalation path: Documenting the process for handling incidents and outages, like identifying key contacts and procedures in case of a service disruption.
OS maintenance and patching: Understanding how and when OS updates are applied, such as if servers are auto-patched monthly or manually updated.
Licensing requirements: Identifying any software licenses that need to be maintained or updated, like checking whether the application uses licensed middleware that needs to be accounted for in the cloud.
Other associated assets: Noting additional components tied to the workload, such as external dependencies, third-party services, or integrated tools. For example, recognizing an application’s dependency on an external payment gateway service.
For each resource that is part of your cloud migration portfolio:
- Choose a migration strategy, retain, retire, relocate, repurchase, rehost, replatform, or refactor strategies.
- Assign a priority for migrating the resources to the cloud. This priority will determine the urgency of that migration. A higher-priority resource might move earlier in the migration schedule.
- Document the business driver for migrating the resources to the cloud, which will drive the need and priority for migrating the resources to the cloud.
Create a Plan
Utilize the information collected to create migration waves. Waves are logical groupings of resources that can be sequentially deployed By the end of this phase in your migration project, you should be able to create an ordered backlog of applications that can migrate to the cloud.
The main goals of the migration planning phase include the following:
- Defining the success criteria for the migration
- Determining the right size of the resources in the cloud
- Determining the priority of applications to migrate to the cloud
- Identifying migration patterns
- Creating a detailed migration plan, checklist, and schedule
- Creating migration sprint teams
- Identifying tools for migration
Migration planning includes determining the cloud account structure and creating a network structure for your application. It is also essential to understand hybrid connectivity with the target cloud environment. Hybrid connectivity will help you plan for applications that depend on resources that are still running on-premises.
The order of application migration can be determined through three high-level steps:
- Evaluate each application across several business and technical dimensions associated with a potential migration to accurately quantify the environment.
- Identify the dependencies for each application with locked, tightly coupled, and loosely coupled qualifications to identify any dependency-based ordering requirements.
- Determine the desired prioritization strategy of the organization to determine the appropriate relative weighting of the various dimensions. If the organizational strategy is to minimize risk, then business criticality will have more weight in identifying the applications. If ease of migration is the strategy, applications that can be migrated using the rehost method will have higher priority, as rehosting is a more straightforward process than other strategies.
The outcome of planning should be an ordered list of applications that can be used to schedule the cloud migration.
Design
When migrating to the cloud, you can design your application architecture to benefit from the global cloud infrastructure, increase the proximity to your end users, mitigate risk, improve security, address data residency constraints. Systems expected to grow over time should be built on top of scalable architecture that can support growth in users, traffic, or data with no drop in performance
When thinking about your application’s network design, you need to consider the following:
- Network packet flows entering the boundaries of your application
- External and internal traffic routing
- Firewall rules for network protection
- Application isolation from the internet and other internal applications
- Overall network compliance and governance
- Network log and flow audit
- Separation of application risk levels, as per their exposure to data and users
- DDoS attack protection and prevention
- Network requirements for production and non-production environments
- SaaS-based multi-tenancy application access requirements
- Network boundaries at the business unit level in an organization
- Billing and implementation of the shared services model across the business unit
Depending on your connectivity needs, you can consider hybrid connectivity options with an on-pren ises system.
As an output of your design phase, you should create a detailed design document for the architecture of your application in the cloud. The design document should include details such as:
User account migration: The user accounts that will be transferred during the migration process
Network configuration: The network setup required for the application in the new environment
Access control lists: A comprehensive list of users, groups, and applications requiring access to the migrated data
Hosting details: Where and how the application will be hosted post-migration
Backup requirements: The backup strategies and requirements specific to the application
Licensing needs: Any licensing requirements associated with the application
Monitoring protocols: The monitoring systems and protocols that will be in place
Security measures: The security measures and compliance standards that the application must adhere to
Maintenance and patching: Procedures for regular maintenance and patching schedules
Execute Plan
Data migration
Two approaches:
- Lift & Shift: Copy data from source, shut down service, redirect traffic to new instance
- Hybrid Sync: Copy data from source, continuously migrate data as application runs, ease traffic to new source in cutover
Validation
Perform the necessary cloud functionality checks is to ensure that the application is running with proper network configuration( desired geolocation),validate the server configuration (such as RAM, CPU, and hard disk) Some knowledge of the application and its functionality is required to perform these checks. Perform integration tests for the application.
Integration
Check integration with external dependencies and applications. When the integration process is complete, you need to validate the integration by performing unit tests, smoke tests, and user acceptance tests (UATs), The results from these tests help you get approval from the application and business owners. The final step of the integration and validation phase includes a sign-off process from the application and the business owner of the application, which will allow you to cut over the application from on-premises to the cloud.
Cutover
The next phase of cloud migration is the cutover process. In this phase, you take the necessary steps to redirect your application traffic from the source on-premises environment to the target cloud environment. Some factors to consider when determining a cutover strategy include the following:
- Acceptable downtime for the application
- The frequency of the data update
- Data access patterns such as read-only or static data
- Application specific requirements such as database syncs, backups, and DNS name resolutions
- Business constraints, such as the day or time during which the cutover can happen and the criticality of the data hanging management guidelines and approvals
Here is how to perform a live migration cutover:
1. Overview
Live migration cutovers using a blue-green deployment strategy are designed to ensure a smooth transition of services from an existing (blue) environment to a new (green) environment with minimal downtime and risk. This guide provides a generalized framework that can be adapted to any infrastructure and cloud provider.
2. Current Setup (Blue Environment)
The blue environment represents the current operational setup. It typically includes:
Web Servers: Handles incoming user requests.
Application Servers: Processes business logic and serves user requests.
Database: Stores application data, often hosted on-premises or in a legacy environment.
The blue environment may handle a percentage of user traffic during the migration process to maintain continuity.
3. Target Setup (Green Environment)
The green environment is the new infrastructure, prepared to take over the full workload. It generally consists of:
- Scalable Compute Resources: Such as virtual machines or containerized services.
- Modernized Database: Hosted in a cloud platform or other scalable environments, continuously synchronized with the blue environment to ensure data consistency.
- Traffic Management Tools: Capable of dynamically routing user traffic between environments.
4. Traffic Routing and Initial Distribution
Initially, a small percentage of traffic (e.g., 20%) is routed to the green environment for testing and validation, while the majority of traffic continues to flow to the blue environment. This ensures:
- Minimal risk to user experience.
- Thorough testing of the green environment under live traffic conditions.
Routing can be managed using tools like load balancers or DNS management systems that support gradual traffic shifts.
5. Data Replication
Continuous data replication is crucial for a seamless cutover. Key practices include:
- Real-Time Synchronization: Ensuring all data changes in the blue environment are mirrored in the green environment.
- Consistency Checks: Regularly validating the integrity of the replicated data.
- Final Sync: Before the cutover, perform a final synchronization to ensure no data discrepancies.
6. Live Migration Cutover Process
- Thorough Testing: Before full traffic redirection, validate the green environment’s stability and performance by conducting comprehensive tests.
- Gradual Traffic Shift: Gradually increase traffic to the green environment while reducing traffic to the blue environment.
- Example: Shift 20% increments of traffic until 100% is handled by the green environment.
- Monitor and Optimize: Continuously monitor the green environment’s performance during the transition.
7. Fallback Strategy
Maintain the blue environment on standby during the cutover phase. If critical issues arise:
- Redirect traffic back to the blue environment to ensure service continuity.
- Address and resolve issues in the green environment before retrying the cutover.
8. Completion and Decommissioning
- Final Verification: Confirm the green environment is fully operational and handling all traffic.
Decommissioning:
Once the migration is deemed successful decommission or repurpose the blue environment.
Archive any necessary data or resources from the blue environment.
Post-Migration Optimization
Optimize the green environment for performance, security, and scalability.
Alternative Cutover Strategies
For scenarios where downtime is acceptable, consider these options:
Scheduled Downtime:
- Pause application traffic.
- Perform a final data sync and conduct smoke tests.
- Redirect all traffic to the green environment post-verification.
Quick Sync and Redirect:
- Use Change Data Capture (CDC) techniques for faster synchronization.
- Perform a final validation before going live.
Best Practices for Success
Plan Extensively: Define clear migration phases and fallback strategies.
Test Thoroughly: Conduct multiple rounds of testing in the green environment.
Monitor Continuously: Use robust monitoring tools to track performance and identify issues.
Communicate Clearly: Inform stakeholders of the migration schedule and potential impacts.
Operations
The following are the IT operations to address and document:
- Server patching
- Service and application logging
- Cloud monitoring
- Event management
- Cloud security operations
- Configuration management.
- Cloud asset management
- Change management
- Business continuity with disaster recovery and high availability