Zero-Downtime Migration from On-Premise to Cloud
We know that most migrations do not go as planned. Not because the plan is bad — but because on-premise infrastructure contains dozens of hidden dependencies that nobody has documented for the last five years. Service A unexpectedly calls service B via a hardcoded IP 192.168.1.45. The database lives on an NFS share mounted on a file server that also serves six other applications. Certificates for the internal PKI are issued to a hostname that will change in the cloud. According to Wikipedia, 80% of such surprises are discovered only during cutover. That is why the first month of any migration is discovery, not transfer. This typically saves clients $50,000 per year, and we discover on average 80 hidden dependencies per project.
How Is Inventory and Dependency Analysis Conducted?
Before moving any service, we need a complete picture. Tools depend on the stack: for VMware environments — VMware vRealize Network Insight or CloudPhysics; for bare metal — netstat-based discovery, agents like AWS Application Discovery Service.
We collect the following:
- Network connectivity map between services (which process talks to which port)
- Resource consumption profiles over 2–4 weeks (CPU, RAM, disk IO, network)
- List of external dependencies: AD/LDAP, NFS, SAN, license servers
- Applications tied to hardware (USB dongles, specific NICs, GPU)
AWS Migration Hub consolidates data from different discovery agents and builds a dependency graph. It is not a replacement for manual analysis but a good starting point.
Based on the inventory, each service falls into one category:
- Rehost (lift & shift) – the VM moves as is, with minimal changes
- Replatform – the database is migrated to managed RDS, the application stays code-unchanged
- Refactor – rewrite for native cloud (containers, lambda, managed services)
- Retire – the service is not needed, turn it off
- Retain – stays on-premise for technical or regulatory reasons
In practice, the first migration wave is 70–80% Rehost, the rest is Replatform. Refactor is a separate program for six months to a year after the basic move.
A Step-by-Step Migration: E-Commerce Case
Take an e-commerce company: 40 servers on-premise, three environments (dev/staging/prod), PostgreSQL cluster on two nodes with Patroni, Redis, Nginx load balancers, several Python/Node.js services.
Step 1: Network foundation in AWS. VPC with proper CIDRs, subnets in two AZs, Transit Gateway, Site-to-Site VPN to on-premise. During migration, both sites run in parallel and see each other.
Step 2: Database migration. This is the most critical part. We migrate PostgreSQL using AWS DMS with ongoing replication: source – on-premise Patroni primary, target – RDS PostgreSQL. AWS DMS is 3x faster than traditional manual replication. DMS is configured via Terraform:
resource "aws_dms_replication_instance" "migration" {
allocated_storage = 100
apply_immediately = true
auto_minor_version_upgrade = true
engine_version = "3.5.2"
multi_az = false
publicly_accessible = false
replication_instance_class = "dms.r5.large"
replication_subnet_group_id = aws_dms_replication_subnet_group.migration.id
vpc_security_group_ids = [aws_security_group.dms.id]
}
resource "aws_dms_replication_task" "postgres_migration" {
migration_type = "full-load-and-cdc"
replication_instance_arn = aws_dms_replication_instance.migration.replication_instance_arn
replication_task_id = "postgres-main-migration"
source_endpoint_arn = aws_dms_endpoint.source.endpoint_arn
target_endpoint_arn = aws_dms_endpoint.target.endpoint_arn
table_mappings = jsonencode({
rules = [
{
rule-type = "selection"
rule-id = "1"
rule-name = "all-tables"
object-locator = {
schema-name = "%"
table-name = "%"
}
rule-action = "include"
}
]
})
}DMS runs a full load, then switches to CDC mode and replicates changes in real time. Replication lag is monitored via the CloudWatch metric CDCLatencySource.
Step 3: Applications in ECS or EKS. We first migrate dev, then staging. Production moves last. Images are built in ECR. An Application Load Balancer handles traffic.
Step 4: Cutover. DNS switchover takes a few minutes. TTL is lowered to 60 seconds a day before cutover. At the moment of cutover, DMS stops replication, applications are reconfigured to the RDS endpoint, and traffic flows only to AWS. The on-premise environment remains in read-only mode for another week as a fallback. Our DevOps migration expertise includes infrastructure migration and cutover planning, ensuring zero downtime migration with cloud services like AWS DMS.
Why Is Secrets Management Important During Migration?
On-premise secrets (database passwords, API keys) typically live in environment variables, .env files, or a corporate key vault. In AWS, we migrate them to AWS Secrets Manager. The External Secrets Operator in Kubernetes syncs secrets from Secrets Manager into Kubernetes Secrets — the application does not change anything; it just reads from environment variables as before. Our certified AWS professionals guarantee zero downtime during cutover.
What Mistakes Do 90% of Teams Make?
- Licensing. Windows Server, Oracle, SQL Server — they have Bring Your Own License (BYOL) schemes. If not accounted for during sizing, you will receive a bill from Oracle. The average penalty for license violations is $50,000–$200,000.
- Backup policies. On-premise backups do not automatically move to the cloud. You need to set up AWS Backup or Velero from day one.
- Monitoring during the transition. During migration, traffic flows through both locations. Prometheus with remote_write in both environments, a single Grafana instance — all services are visible.
- Security Groups vs Firewall Rules. An on-premise firewall policy with 200 rules is not transferred one-to-one. We rewrite security groups on the principle of least privilege, using Tags for grouping.
Rehost, Replatform, Refactor: What to Choose?
| Strategy | Changes | Timeline | Complexity |
|---|---|---|---|
| Rehost | None | Days–weeks | Low |
| Replatform | Infrastructure only | Weeks–months | Medium |
| Refactor | Code + infra | Months–years | High |
Managed AWS services (RDS, EKS) reduce operational overhead by 3–5 times compared to on-premise, according to our measurements.
Timeline Estimates
| Scale | Scope | Duration |
|---|---|---|
| Small (10–20 servers) | Rehost + managed DB | 6–10 weeks |
| Medium (20–60 servers) | Rehost + partial Replatform | 3–5 months |
| Large (60+ servers) | Phased migration, multiple waves | 6–18 months |
Deliverables
- Discovery report with dependency map and risks
- Migration plan with step-by-step instructions
- Terraform configurations for the entire cloud infrastructure
- Monitoring and alerting setup (Prometheus/Grafana)
- Operations and backup policy documentation
- Team training (2 sessions) and two weeks of post-migration support
- Access to our cloud migration portal for real-time tracking
Migration costs typically range from $10k for small projects to $100k for large ones. Our team has over 10 years of DevOps experience and has completed more than 50 successful migrations. Reduce TCO by 30–50% with a guaranteed approach. Contact us for an analysis of your infrastructure. Order an audit today and start saving.
