TH 11 ‐ Document different scenario & steps for migration - DevWithNehaCloud/Oracle-Cloud-Infrastructure-wiki GitHub Wiki

☁️ Cloud Migration – End-to-End Migration Lifecycle

📖 Overview

Cloud migration is the process of moving applications, databases, storage, networking, and business workloads from one environment to another while maintaining security, availability, performance, and business continuity.

Migration is not simply copying data from one location to another. It is a structured process involving assessment, planning, design, implementation, testing, validation, cutover, and post-migration support.

The primary goal is to migrate workloads with:

Minimal downtime
Minimal data loss
Proper security controls
Business validation
Rollback capability if required

🌍 Types of Cloud Migration

1. On-Premises to Cloud

Move workloads from a physical data center to OCI.

On-Premises Data Center
           │
           ▼
          OCI

Common Reasons

Hardware refresh
Data center closure
Cloud adoption
AI / GPU requirements
Scalability needs

2. Cloud to Cloud Migration

Move workloads between cloud providers.

OCI
 │
 ▼
Azure

Common Reasons

Multi-cloud strategy
Business merger
Vendor diversification
Regulatory requirements

3. Region to Region Migration

Move workloads between OCI regions.

OCI Ashburn
      │
      ▼
OCI Hyderabad

Common Reasons

Disaster Recovery
Latency optimization
Regional expansion

4. Tenancy to Tenancy Migration

Move resources between OCI tenancies.

Source Tenancy
       │
       ▼
Target Tenancy

Common Reasons

Company split
Ownership transfer
Business restructuring

📦 Migration Strategies (6 R's)

Not every application is migrated in the same way.

Strategy	Description
Rehost	Lift and Shift
Replatform	Minor cloud optimization
Refactor	Application redesign
Repurchase	Move to SaaS product
Retain	Keep existing workload
Retire	Decommission workload

🚀 Cloud Migration Lifecycle

Phase 1 – Discovery & Assessment

Objective

Understand the current environment and identify everything that needs to be migrated.

Activities

Application Discovery

Collect:

Application names
Application owners
Business criticality
Dependencies
Third-party integrations

Compute Discovery

Collect:

Server Name
Operating System
CPU
Memory
Shape / Configuration
Utilization

Storage Discovery

Collect:

Block Volumes
File Storage
Object Storage
Backup Storage

Database Discovery

Collect:

Database Type
Database Version
Database Size
Backup Requirements

Network Discovery

Collect:

CIDR Ranges
Subnets
Route Tables
Security Rules
VPN Connectivity
FastConnect Connectivity

Security Discovery

Collect:

IAM Requirements
Compliance Requirements
Encryption Requirements
Access Requirements

Deliverable

Migration Inventory Report

Client Sign-Off

Discovery Approval

💰 Phase 2 – Cost Assessment & Budget Approval

Objective

Estimate the cost of running workloads in the target cloud.

Activities

Calculate:

Compute Cost
Storage Cost
Database Cost
Network Cost
Monitoring Cost
Backup Cost
Disaster Recovery Cost

Inventory Items Collected

CPU
Memory
Shape
Block Volume
Object Storage
Database
Public IP
Private IP
Load Balancer
Monitoring Requirements

Deliverable

Cost Estimation Sheet

Client Sign-Off

Budget Approval

Migration does not proceed until budget approval is received.

📐 Phase 3 – Architecture Design

Objective

Design the target cloud architecture.

Activities

Prepare:

Region Selection
Compartment Structure
IAM Design
Network Design
Security Design
Backup Design
Monitoring Design
DR Design

HLD (High Level Design)

Contains:

Architecture Diagram
Security Architecture
Network Architecture
DR Architecture

Focuses on:

WHAT are we building?
WHY are we building it?

LLD (Low Level Design)

Contains:

IP Planning
Security Rules
Route Tables
Server Configurations
Build Instructions

Focuses on:

HOW exactly will it be built?

Deliverables

Client Sign-Off

Architecture Approval

🔗 Phase 4 – Dependency Mapping & Migration Waves

Objective

Understand application dependencies before migration.

Applications rarely work independently.

A single application may depend on:

Databases
APIs
File Shares
Active Directory
DNS
SSL Certificates
Third-Party Services

Migration Waves

Applications are grouped into waves.

Wave 1 → Low Risk Applications

Wave 2 → Medium Risk Applications

Wave 3 → Business Critical Applications

Deliverable

Dependency Mapping Document

Client Sign-Off

Wave Plan Approval

🏗️ Phase 5 – Landing Zone Setup

Objective

Build the cloud foundation before application migration.

Activities

Create:

Compartments
Users
Groups
Policies
Dynamic Groups
VCN
Subnets
Route Tables
Security Lists
NSGs
DRG
Bastion
Monitoring
Logging

Typical Architecture

                HUB VCN
                     │
     ┌───────────────┼───────────────┐
     │               │               │
     ▼               ▼               ▼

 SPOKE DEV      SPOKE QA      SPOKE PROD

Validation

Verify:

IAM Access
Connectivity
Security Controls

Client Sign-Off

Landing Zone Approval

🌐 Phase 6 – Network Connectivity Setup

Objective

Connect source and target environments.

Options

On-Prem → OCI

FastConnect
Site-to-Site VPN

OCI → Azure

FastConnect
ExpressRoute

OCI Region → OCI Region

Remote Peering Connection (RPC)

Validation

Perform:

Ping Test
Route Verification
DNS Resolution
Port Testing

Client Sign-Off

Connectivity Approval

🧑‍💻 Phase 7 – Development Environment Build

Objective

Create the first migrated environment.

Activities

Deploy:

Application Servers
Database Servers
Storage
Load Balancers

Configure:

DNS
Monitoring
Security Rules

Validation

Development Team Testing

Sign-Off

Development Approval

📦 Phase 8 – Initial Data Migration

Objective

Move non-production data.

Common Methods

scp file.zip opc@target:/data

Other Methods:

SCP
Rsync
Data Pump
RMAN
Object Storage
Migration Tools

Important Note

Migration tools are generally used during data transfer stages.

The architecture, networking, security, and landing zone are usually built before migration tools are introduced.

Validation

Verify:

File Count
Record Count
Checksums
Data Integrity

Sign-Off

Initial Data Migration Approval

🧪 Phase 9 – QA Environment

Objective

Validate application functionality.

Activities

Perform:

Functional Testing
Regression Testing
Integration Testing
Performance Testing

Validation

QA Team Approval

Sign-Off

QA Sign-Off

👔 Phase 10 – User Acceptance Testing (UAT)

Objective

Business users validate the application.

Activities

Business teams execute:

Login Validation
Business Transactions
Report Validation
End-to-End Workflows

Deliverable

UAT Acceptance Letter

Sign-Off

Business Owner Approval

🔐 Phase 11 – Security Validation

Objective

Verify security posture before production.

Activities

Perform:

Vulnerability Assessment
Penetration Testing
Compliance Review
Security Audit

Validation

Security Team Approval

Sign-Off

Security Clearance

🔄 Phase 12 – Final Data Synchronization

Objective

Synchronize latest production data before cutover.

Activities

Perform:

Delta Data Transfer
Incremental Database Sync
Final Backup

Validation

Compare:

Source Records
Target Records
Database Counts
Reports

Sign-Off

Migration Team Approval

🚀 Phase 13 – Production Cutover (Go-Live)

Objective

Switch production traffic to the target cloud.

Source Environment Activities

Freeze Changes
Stop Application
Take Final Backup

Target Environment Activities

Restore Latest Data
Start Services
Validate Application

Cutover Flow

Source Environment
        │
        ▼
 Final Sync
        │
        ▼
 Application Validation
        │
        ▼
      GO LIVE

🚦 Phase 14 – Go / No-Go Decision

GO Decision

Proceed when:

Application is healthy
Database is healthy
Security team approves
Business team approves

GO

NO-GO Decision

Rollback when:

Critical defects exist
Data validation fails
Business validation fails

NO-GO

Stakeholders

Cloud Team
Network Team
DBA Team
Application Team
Security Team
Business Owner

↩️ Phase 15 – Rollback (Fallback) Plan

Objective

Return to the source environment if migration fails.

Common Rollback Triggers

Data mismatch
Critical application failure
Performance degradation
RTO violation

Rollback Activities

Redirect Traffic
Restore DNS
Restart Source Environment
Re-enable Original Services

Example

Rollback Window = 48 Hours

👀 Phase 16 – Hypercare Support

Objective

Provide intensive monitoring immediately after go-live.

Typical Duration

48 Hours to 2 Weeks

Activities

24x7 Monitoring
Incident Management
Performance Validation
User Support

📚 Phase 17 – Project Closure & Handover

Objective

Transfer ownership to support teams.

Deliverables

Inventory Report
Cost Sheet
HLD
LLD
Migration Report
UAT Sign-Off
Security Report
Cutover Report
Rollback Plan

Handover To

Operations Team
Monitoring Team
Support Team

🌱 Post-Migration Optimization

After migration is completed:

Cost Optimization

Right-size instances
Remove unused resources
Configure budgets
Configure cost alerts

Monitoring

Monitor:

CPU
Memory
Storage
Application Health
Database Health

Disaster Recovery

Validate:

Backups
Replication
DR Procedures
DR Drill

📈 Migration Success Criteria

Migration is considered successful when:

All applications are operational
No critical defects exist
RTO targets are achieved
RPO targets are achieved
Security validation is passed
Monitoring is active
Backups are active
Business owner signs off
Legacy environment is safely decommissioned

🎯 Interview Summary

Cloud migration starts with discovery and inventory collection, followed by cost estimation, architecture design, dependency mapping, and landing zone setup. Connectivity is established between source and target environments, and workloads are deployed in Development, QA, and UAT environments for validation. After security testing and final data synchronization, production cutover is performed. A Go/No-Go decision is taken, and a rollback plan remains available until the migration is fully stabilized. Once the environment is stable, hypercare support, optimization, and project closure activities are completed.

📝 Industry Notes

1. Inter-Cloud Migration (OCI ↔ Azure ↔ AWS)

Inter-Cloud Migration is commonly used when organizations want to avoid vendor lock-in and take advantage of services offered by different cloud providers.

For example:

AWS may provide better services for certain workloads.
Azure may be preferred for Microsoft-based workloads.
OCI may offer better pricing for Oracle workloads.

If a company depends entirely on a single cloud provider, future pricing, licensing, or service limitations may create operational risks. To reduce this dependency, organizations may migrate workloads between cloud providers or adopt a multi-cloud strategy.

Interview Note:

One common reason for Inter-Cloud Migration is avoiding vendor lock-in and leveraging the strengths of multiple cloud providers.

2. Inter-Region Migration (OCI Ashburn → OCI Phoenix)

Inter-Region Migration is commonly used for:

Disaster Recovery (DR)
Business Continuity
Regional Expansion
Regulatory Requirements
Reducing latency for users in another geography

If a complete cloud region becomes unavailable because of a large-scale outage, natural disaster, or regional service disruption, workloads can continue running from another region.

Organizations maintain secondary regions and Disaster Recovery (DR) environments to ensure business continuity and minimize service disruption during regional outages. Critical workloads should not rely on a single region, as failures or large-scale incidents can impact availability.

Interview Note:

Inter-Region Migration is primarily performed for Disaster Recovery, Business Continuity, and reducing dependency on a single region.

3. On-Premises to Cloud Migration

Organizations migrate from on-premises environments to the cloud to avoid managing physical infrastructure.

In traditional data centers, companies must purchase:

Servers
Storage
Memory
Network Equipment
Backup Hardware

During periods of high demand, hardware procurement can become expensive and time-consuming. Cloud platforms eliminate the need to purchase and maintain physical infrastructure because resources can be provisioned on demand.

This is one reason many organizations move from on-premises environments to cloud platforms.

Interview Note:

On-Premises to Cloud Migration helps organizations avoid hardware procurement challenges and provides scalability without purchasing physical infrastructure.

4. Inter-Tenancy Migration

Inter-Tenancy Migration is commonly used when resources must be moved between different OCI tenancies.

Typical scenarios include:

Company mergers
Company acquisitions
Business unit separation
Organizational restructuring
Regulatory or ownership changes

Example:

A company acquires another company that already has its own OCI tenancy. To standardize operations, applications and resources may be migrated into a common tenancy.

Another example is when a business unit becomes an independent organization and requires its own OCI tenancy.

Interview Note:

Inter-Tenancy Migration is usually performed during mergers, acquisitions, ownership transfers, or organizational restructuring.