On-Premises to Cloud Migration Roadmap: A Step-by-Step Strategy Guide

Reality Check Before Migration

Lifting and shifting on-premises systems as-is can actually increase costs. Successful migration starts with thorough preparation.

The 6R Migration Strategies

TCO Comparison Example

On-premises annual cost: KRW 112 million
- Server hardware depreciation: KRW 30 million
- Data center lease/power: KRW 12 million
- Operations staff: KRW 50 million
- Software licenses: KRW 20 million

Cloud estimate: KRW 54 million (52% savings)

Step-by-Step Roadmap

Phase 1: Current-State Assessment (1–2 months)

# AWS Application Discovery Service
# Collect 30 days of data with an agent
# - CPU/memory utilization
# - Network traffic patterns
# - Service dependency map

Phase 2: Pilot Migration (1 month)

Move one or two low-criticality systems first. The goal is to validate the process.

Phase 3: Wave Migration (3–6 months)

Wave 1: Standalone web servers (no dependencies)
Wave 2: Application servers + DB
Wave 3: Core business systems
Wave 4: Legacy/integrated systems

Database Migration (AWS DMS)

# Oracle → Aurora PostgreSQL
aws dms create-replication-task \
  --replication-task-identifier oracle-to-aurora \
  --source-endpoint-arn arn:aws:... \
  --target-endpoint-arn arn:aws:... \
  --migration-type cdc  # Change Data Capture

Phase 4: Optimization (after 3 months)

• Downsizing: Adjust instance types based on actual usage
• Purchase Reserved Instances (after confirming 1-year patterns)
• Switch to managed services (self-managed DB → RDS)

Failure Patterns

• Big-bang migration: Moving all systems at once → total outage if it fails
• Ignoring network design: VPC CIDR colliding with on-premises IP ranges
• No cost monitoring: Costs 3x higher than expected

# Configure AWS Budgets alarm (notify when 80% of budget is exceeded)
aws budgets create-budget \
  --account-id 123456789 \
  --budget '{"BudgetName":"Monthly","BudgetLimit":{"Amount":"5000000","Unit":"KRW"}}'

Cloud migration is a business change-management project before it is a technology project.

Migration Automation Tools

Manual cutovers cause mistakes and downtime. Use purpose-built tools for each workload.

Korea-Specific Considerations

• Network isolation and CSAP: Public-sector and financial institutions can use only certified regions and services. Confirm this in advance.
• Data sovereignty: Cross-border transfer of personal data requires consent and notice. Prefer Korean regions.
• Circuits and egress: For large initial transfers, dedicated lines (Direct Connect/ExpressRoute) or physical appliances (Snowball) can be faster and cheaper than internet transfer.

Migration Is Ultimately a People Problem

Harder than the technical move is changing the operations organization. Redefine the on-premises ops team's role as cloud operations (FinOps and SRE), and migrate training and access models with them—otherwise you end up with “we migrated, but nobody can operate it.”

Slowdowns Right After Cutover: Cause, Verification, Rollback

Migration problems often surface in the days after cutover rather than on the day itself.

Causes

• App and DB that shared a rack on-prem end up in different AZs or split across on-prem and cloud, increasing round-trip latency
• Long DNS TTLs keep some clients on the old servers
• Instances were sized by CPU cores only and hit disk IOPS or network bandwidth limits

Verification

# round-trip latency from app server to DB
ping -c 20 db.internal
mtr -rwc 50 db.internal
# DNS switch state and remaining TTL
dig +noall +answer app.example.com
# disk wait and IOPS (near EBS limits?)
iostat -x 1 10

In the cloud console also check EBS queue length and burst balance and the instance's network throughput metrics.

Fix

• Move chatty services together in the same wave and place them in the same AZ where possible.
• Lower DNS TTL to 60–300 seconds one to two days before cutover and raise it again once stable.
• Re-select storage by required IOPS (e.g., provisioned IOPS on gp3).

Rollback criteria

• Before cutover, agree on conditions and an owner, such as "roll back if error rate exceeds X% or p95 exceeds Y ms for Z minutes." Rehearse reverse data sync (e.g., a reverse DMS task) in advance too.

FAQ

Q. Can't we just start with lift-and-shift? It works for a fast move, but if you leave systems as-is you will not realize cloud cost benefits. Plan to optimize afterward with Replatform/Refactor from the 6Rs.

Q. Our costs actually went up. Why? Moving on-premises specs as-is (overprovisioning) is expensive. Savings only materialize when you downsize based on actual usage, apply commitment discounts, and switch to managed services.