LAB 39 (Subnet Migration) - arunsinghchauhan38-arch/CLOUDARCHITECTDOC GitHub Wiki

Subnet Migration

In Oracle Cloud Infrastructure (OCI), subnet migration refers to moving workloads or service instances from one subnet (or network environment) to another—often during a migration from Oracle Cloud Infrastructure Classic to OCI. It involves redesigning or reassigning Virtual Cloud Networks (VCNs), subnets, and related resources so that applications can run in the new environment with proper connectivity, security, and routing.

🔑 What Is Subnet Migration in OCI

  • Definition: Moving workloads or service instances from one subnet (or legacy environment like OCI Classic) into a new subnet within OCI’s modern VCN model.

  • Purpose: Align workloads with OCI’s networking architecture for better scalability, security, and automation.

  • Scope: Involves redesigning VCNs, subnets, gateways, route tables, and security lists.

Migrating a subnet in Oracle Cloud Infrastructure (OCI) while application instances are running is complex because it disrupts networking, IP addressing, and security configurations. The biggest challenges are downtime risk, IP reassignments, broken dependencies, and reconfiguration of routing/security rules.

🔑 Key Difficulties in Subnet Migration (OCI)

1. IP Address Changes

  • Instances tied to a subnet get their primary private IP from that subnet’s CIDR block.

  • Migrating to a new subnet means new IPs, which can break:

Application dependencies

Database connections

Hardcoded IP references in configs

2. Downtime & Service Disruption

  • Applications may experience temporary unavailability during migration.

  • Load balancers, DNS, and routing tables need updates to point to the new subnet.

3. Security Configuration Rework

  • Security lists and Network Security Groups (NSGs) are subnet-specific.

  • Migration requires recreating or reassigning rules to ensure traffic flows correctly.

  • Misconfiguration can block traffic unexpectedly.

4. Routing & Gateway Dependencies

  • Subnets are tied to Dynamic Routing Gateways (DRG), Internet Gateways (IGW), and Local Peering Gateways (LPG).

  • Migrating requires re-establishing these connections, which can cause routing failures if overlooked.

5. Attached Resources

  • Block volumes, load balancers, and secondary VNICs may not automatically migrate.

  • Manual reassignment or recreation is often required.

6. Application-Level Dependencies

  • Applications relying on fixed IPs, firewall rules, or external integrations may break.

  • Requires thorough dependency mapping before migration.

📋 Migration Execution Checklist

Pre-Migration

  • Document dependencies (instances, gateways, firewalls, DNS).

  • Replicate subnet configuration in target subnet.

  • Notify all stakeholders of downtime window.

Migration

  • Stop non-critical workloads.

  • Move instances to new subnet (redeploy if required).

  • Update routing tables, gateways, and DNS.

Post-Migration

  • Application team runs smoke tests.

  • Network team validates connectivity.

  • Monitor logs and metrics for anomalies.

  • Communicate completion to stakeholders.

Rollback Plan

  • Keep old subnet active until migration is validated.

  • Document rollback steps clearly.

👥 How Cloud Architects Manage It

Pre-Migration Planning:

  • Conduct workshops with network, security, application, and operations teams.

  • Document dependencies in a migration runbook.

Staging/Test Runs:

  • Perform migration in a sandbox environment first.

  • Validate routing, security, and IAM policies before production cutover.

Automation:

  • Use Terraform/OCI Resource Manager to standardize subnet creation, gateways, and rules.

  • Reduces human error and ensures repeatability.

Change Management:

  • Log every change in OCI Audit Logs.

  • Keep rollback plans ready (snapshots, backups).

👥 Team Roles & Responsibilities

Cloud Architect

  • Own the migration plan and risk assessment.

  • Define dependencies (apps, DBs, gateways, security).

  • Communicate timelines and fallback strategy.

Network Team

  • Prepare new subnet, routing tables, gateways (IGW, DRG, LPG).

  • Replicate security lists and NSGs.

  • Validate connectivity post-migration.

Application Team

  • Identify IP dependencies in configs.

  • Switch apps to DNS-based addressing.

  • Perform smoke tests after migration.

Database Team

  • Ensure DB connections are resilient (use service names, not IPs).

  • Validate replication/backup before migration.

DevOps/Infra Team

  • Automate instance redeployment if needed.

  • Handle load balancer reconfiguration.

  • Monitor performance during cutover.

Business/Operations Team

  • Approve downtime window.

  • Communicate impact to stakeholders.

  • Confirm business continuity plan.

✅ Takeaway

Subnet migration is a cross-team operation. The architect’s role is to coordinate dependencies, minimize downtime, and ensure rollback readiness. The best time is during low-traffic maintenance windows, with all teams aligned and a clear communication plan in place.