Cloud Migration Pro

Strategic cloud migration agent for planning, executing, and optimizing the transition of on-premise applications to AWS, Azure, or GCP environments.

When to Use This Agent

Choose this agent when you need to:

• Assess on-premise workloads and create a phased cloud migration roadmap
• Containerize legacy applications with Docker and orchestrate with Kubernetes
• Design Infrastructure as Code templates for reproducible cloud environments
• Optimize cloud resource allocation and reduce monthly spend after migration

Consider alternatives when:

• Your modernization is focused on frontend framework migration (use Expert Architecture Bot)
• You need to refactor legacy code patterns before migrating (use Specialist Legacy Modernizer)

Quick Start

Configuration

Copy
name: cloud-migration-pro
type: agent
category: modernization

Example Invocation

Copy
claude agent:invoke cloud-migration-pro "Plan migration of a 3-tier Java application from on-premise VMware to AWS with minimal downtime"

Example Output

Cloud Migration Plan: Java 3-Tier Application
===============================================

Phase 1 - Assessment (Week 1-2):
  Workload: Java 11 app server, PostgreSQL 13, Nginx reverse proxy
  Dependencies: LDAP auth, NFS file shares, cron jobs
  Data Volume: 420 GB database, 1.2 TB file storage
  Current SLA: 99.5% uptime

Phase 2 - Lift and Shift (Week 3-6):
  Compute: EC2 m6i.xlarge (app) -> ECS Fargate (target)
  Database: RDS PostgreSQL 13 with Multi-AZ
  Storage: EFS for shared files, S3 for archival
  Network: VPC with private subnets, ALB frontend
  Estimated cost: $1,840/month (vs $3,200 on-premise)

Phase 3 - Optimization (Week 7-10):
  Containerize app server with multi-stage Dockerfile
  Migrate cron jobs to EventBridge + Lambda
  Replace NFS with S3 + CloudFront for static assets
  Implement auto-scaling policies
  Target cost: $1,200/month

Downtime Budget: 45-minute maintenance window for DNS cutover
Rollback Plan: DNS failback to on-premise within 5 minutes

Core Concepts

Migration Strategy Overview

Aspect	Details
Assessment	Workload inventory, dependency mapping, TCO analysis
Migration Types	Lift-and-shift, re-platform, re-architect, retire
IaC Tools	Terraform, AWS CloudFormation, Pulumi, CDK
Container Runtime	Docker with ECS Fargate, EKS, or GKE
Database Strategy	Managed services (RDS, Cloud SQL), DMS for migration
Networking	VPC design, VPN/Direct Connect, load balancing

Migration Pipeline Architecture

┌─────────────┐     ┌─────────────┐
│  Assessment  │────▶│  Planning    │
│  & Discovery │     │  & Design    │
└─────────────┘     └─────────────┘
        │                   │
        ▼                   ▼
┌─────────────┐     ┌─────────────┐
│  Migration   │────▶│  Optimize    │
│  Execution   │     │  & Monitor   │
└─────────────┘     └─────────────┘

Configuration

Parameter	Type	Default	Description
cloudProvider	enum	"aws"	Target cloud: aws, azure, or gcp
migrationStrategy	enum	"replatform"	Strategy: lift-shift, replatform, re-architect
iacTool	enum	"terraform"	Infrastructure as Code: terraform, cloudformation, pulumi
multiRegion	boolean	false	Deploy across multiple regions for DR
costOptimization	enum	"balanced"	Priority: performance, balanced, or cost-first

Best Practices

1. Run Assessment Before Writing Any Infrastructure Code Catalog every workload, dependency, and data flow before selecting migration strategies. Applications with tight coupling to on-premise services (LDAP, NFS, hardware HSMs) require re-platforming rather than simple lift-and-shift.

2. Implement Infrastructure as Code from Day One Never provision cloud resources manually through the console. Every VPC, security group, database instance, and IAM role should exist in version-controlled Terraform or CloudFormation templates. Manual resources become undocumented drift.

3. Use Database Migration Service for Zero-Downtime Data Transfer AWS DMS, Azure Database Migration Service, and GCP Database Migration Service handle continuous replication from on-premise to cloud databases. This allows the application to keep running on the source until the final cutover.

4. Right-Size Resources After Two Weeks of Production Metrics Initial sizing is always an estimate. Collect CloudWatch, Azure Monitor, or GCP Monitoring data for at least two weeks before adjusting instance types, memory allocation, and storage IOPS. Premature optimization wastes both time and money.

5. Design Rollback Procedures Before Starting Migration Every migration phase needs a tested rollback path. For DNS-based cutover, ensure the on-premise environment remains operational and can accept traffic within minutes. For database migrations, maintain replication in both directions until cutover is verified.

Common Issues

1. Application fails after migration due to hardcoded IP addresses Legacy applications often reference on-premise servers by IP address rather than DNS hostname. Audit configuration files, connection strings, and environment variables for any hardcoded IPs and replace them with DNS names or service discovery endpoints before migrating.

2. Cloud costs exceed on-premise estimates within the first month Over-provisioned instances and unoptimized storage tiers are the usual culprits. Enable cloud provider cost analysis tools immediately, set budget alerts, and schedule a right-sizing review after collecting two weeks of utilization metrics.

3. Database migration stalls at 95% with replication lag increasing Large tables with high write rates can cause DMS replication to fall behind. Increase the replication instance size, optimize the source database by pausing non-critical batch jobs during final sync, and schedule the cutover during a low-traffic window.