Migrate to cloud without the outage that makes you regret it.

Most cloud migrations fail not in the migration itself but in the discovery phase — the moment you learn what you did not know about your existing infrastructure.

On-premises servers that have been running for years accumulate undocumented dependencies: applications that write directly to filesystem paths that do not exist in the new environment, databases that were never properly sized and require specific PostgreSQL parameters, services that communicate over hardcoded IP addresses that change in the cloud, cron jobs that depend on the system timezone. A cloud migration without a thorough dependency mapping phase will encounter these surprises in production during cutover. PROPELOO treats cloud migration as a discovery-first engineering project: map every dependency, validate every assumption in a non-production migration, measure performance equivalence against baseline, and only switch production traffic after every validation passes.

The cloud migration stack.

System Layers

• Assessment Layer: Workload inventory, dependency mapping, migration strategy selection, risk assessment
• Migration Layer: Containerisation, IaC definition, data migration tools, environment parity validation
• Cutover Layer: Traffic migration strategy, DNS cutover, rollback plan, communication plan
• Validation Layer: Performance baseline, functional test suite, monitoring equivalence
• Optimisation Layer: Right-sizing, managed service adoption, cost optimisation post-migration

Core Technical Capabilities

• Migration Assessment

  Workload discovery via agent-based (AWS Application Discovery Service) or agent-less methods, dependency mapping, application portfolio prioritisation (6Rs classification) and total migration effort estimate.

• 6Rs Migration Strategy

  Rehost (lift-and-shift) for time-sensitive migrations, Replatform for managed service adoption, Refactor/Re-architect for modernisation, Retire for decommission, Retain for applications that stay on-premises, Repurchase for SaaS replacement.

• Containerisation

  Dockerising applications that run on bare metal or VM — Dockerfile creation, base image selection, secret injection patterns, health check implementation and build pipeline integration.

• Data Migration

  Database migration via AWS DMS or pgloader, schema conversion, data validation checksums, CDC (Change Data Capture) for minimal-downtime database migrations, and post-migration reconciliation.

• Zero-downtime Cutover

  DNS TTL reduction strategy, blue-green cutover with instant rollback capability, traffic shifting with weighted DNS, health check validation before traffic switch and rollback trigger criteria.

• Infrastructure as Code

  All migrated infrastructure defined in Terraform from day one — VPC, compute, databases, load balancers, IAM. No manual console configuration in the new environment.

How we think about cloud migration.

A cloud migration is not a one-time event. It is a change management project with a technical execution plan. The plan is what prevents the outage.

• Dependency mapping precedes migration planning

  You cannot migrate what you do not understand. Before committing to a migration timeline, map every application dependency: which services talk to which, over what protocols and ports, what external services are called, what filesystem paths are written to, and what cron jobs exist and when they run. Surprises discovered in the dependency map are cheap. Surprises discovered during cutover are expensive.

  Axiom:

• Migrate non-production first and validate thoroughly

  The production migration should be the third or fourth time you run the migration playbook — once for staging, once for pre-production, once with a time pressure simulation. Each run finds issues. By the time production migration runs, the playbook is tested, the team is practised and the unexpected scenarios have already been handled.

  Axiom:

• Performance equivalence is a go/no-go criterion

  A migrated application that responds 40% slower in the cloud than on-premises is not a successful migration. Define performance baselines before migration (p50, p95, p99 API latency, database query times, throughput). Validate equivalence in the new environment before cutover. A performance regression discovered after cutover is a rollback event.

  Axiom:

• Rollback plan must be tested

  A rollback plan that exists only in a document and has never been executed is a plan you cannot rely on under pressure. Practice the rollback in non-production. Ensure DNS can be reverted in under 5 minutes. Confirm the old environment can accept production traffic after traffic was switched away. Untested rollback plans fail when they are needed most.

  Axiom:

The cloud migration decisions.

• Lift-and-shift vs modernise during migration?

  Impact: Hybrid is usually correct. Lift-and-shift to cloud first (reduces risk, establishes cloud presence), then modernise iteratively from a stable cloud baseline. Attempting full re-architecture during migration combines two high-risk projects.

  • Lift-and-shift (Rehost) — fastest, lowest risk, misses cloud optimisation benefits
  • Replatform — minimal changes to take advantage of managed services
  • Refactor/re-architect — maximum cloud benefit, highest risk and time
  • Hybrid — lift-and-shift first, modernise iteratively post-migration

• Cutover strategy?

  Impact: Blue-green for applications that cannot tolerate downtime. Maintenance window for internal applications where a scheduled window is acceptable. Strangler fig for large applications where incremental migration reduces risk.

  • Big bang (all at once) — highest risk, fastest completion
  • Blue-green — parallel environments, instant rollback, double infrastructure cost temporarily
  • Strangler fig (incremental) — route traffic gradually, lowest risk, longest timeline
  • Maintenance window — scheduled downtime, simple, downtime required

• Database migration strategy?

  Impact: DMS for minimal-downtime migrations with continuous replication and cutover when replication lag is zero. Backup and restore for applications that can tolerate a maintenance window. Schema changes required? Custom migration script.

  • DMS (AWS Database Migration Service) — managed, continuous replication
  • pgloader — fast for PostgreSQL migrations
  • Backup and restore — simplest, requires downtime
  • Custom ETL — for schema transformations

• Containerise or not?

  Impact: Containerise applications that can be containerised without significant rework. Keep legacy applications on VMs if containerisation adds significant migration risk. Do not containerise and migrate simultaneously — sequence them.

  • Containerise all applications — consistent deployment, cloud-portable
  • VMs (EC2) for legacy applications — closest to current environment, less optimised
  • PaaS (Elastic Beanstalk/App Service) — managed, limited control
  • Serverless (Lambda) — for eligible workloads, cold start risk

• Migration team structure?

  Impact: Hybrid is consistently best — internal engineers bring application knowledge, external cloud engineers bring migration methodology. Knowledge transfer from external to internal during migration is a bonus.

  • Internal team only — highest context, may lack cloud expertise
  • External migration specialist — cloud expertise, less application context
  • Hybrid (internal + external) — context + expertise, best outcomes
  • Full outsource — fastest start, lowest context transfer

• Post-migration cost management?

  Impact: Accept initial higher cost (on-demand instances, slight over-provisioning) during the first 30-60 days post-migration. Use real usage data from CloudWatch Compute Optimizer recommendations before right-sizing and purchasing Reserved Instances.

  • Accept initial higher cost, optimise later — pragmatic
  • Right-size during migration — adds migration complexity
  • Reserved Instances immediately — locks in savings before usage pattern is known
  • Spot instances immediately — cost savings with reliability risk before validation

What PROPELOO migrates.

• Data Centre to AWS

  Full DC exit — workload assessment, containerisation, Terraform IaC, zero-downtime cutover and post-migration optimisation.

• On-premises to GCP

  Legacy application migration to Google Cloud — VM migration with Migrate to Containers, Cloud SQL database migration and GKE containerisation.

• Database Migration

  Oracle/MySQL to PostgreSQL on RDS or Aurora — schema conversion, data validation, DMS continuous replication and zero-downtime cutover.

• Single-cloud to Multi-cloud

  Adding GCP workloads alongside AWS — networking, identity federation, consistent IaC and cost attribution across clouds.

• Heroku/PaaS Exit

  Migrate from Heroku, Render or DigitalOcean to AWS/GCP — containerise Dynos, migrate Postgres, replicate add-on functionality with cloud-native services.

• Office 365 to AWS Managed Services

  Email and directory to AWS WorkMail and Directory Service — SSO federation, email migration and collaboration tool replacement.

The migration toolchain.

• Assessment

  Stack: AWS Application Discovery Service, AWS Migration Hub, Cloudamize, Manual dependency mapping

• Data Migration

  Stack: AWS DMS, pgloader, Percona XtraBackup, AWS Schema Conversion Tool

• Server Migration

  Stack: AWS Server Migration Service, VM Import/Export, Migrate to Containers (GCP), Manual containerisation

• IaC

  Stack: Terraform, Pulumi, AWS CDK, Terragrunt

• Validation

  Stack: k6 (load testing), Custom functional test suite, Checksum validation scripts, Performance baseline comparison

• Cut-over

  Stack: Route53 weighted routing, AWS Global Accelerator, DNS TTL management, Blue-green switch scripts

Cloud migration must not reduce security posture.

• IAM from day one

  New cloud environment starts with least-privilege IAM — no AdministratorAccess for application workloads, IRSA for Kubernetes pods, service accounts per application.

• Secrets migration

  Secrets in configuration files or environment variables migrate to AWS Secrets Manager or Azure Key Vault. This is a mandatory improvement, not optional.

• Network security equivalence

  On-premises firewall rules documented and translated to security groups and network ACLs. Verify all required ports are open and all unnecessary ports are closed.

• Data encryption in transit

  All data in transit must be encrypted in the cloud environment. Applications communicating over HTTP in the data centre must be upgraded to HTTPS in cloud.

• Compliance validation

  For regulated workloads (PCI, HIPAA, SOC2): verify that cloud service configurations meet compliance requirements before migrating regulated data.

• Penetration test post-migration

  New cloud environment creates new attack surface. A targeted penetration test of the migrated environment (within 90 days of go-live) identifies misconfigurations introduced during migration.

From assessment to stable cloud.

1. 01. Discovery & Assessment

   Workload inventory, dependency mapping, 6Rs classification, risk assessment and migration timeline.

2. 02. Cloud Foundation

   VPC, IAM, security baseline, Terraform scaffold and CI/CD pipeline in target cloud.

3. 03. Non-production Migration

   Migrate staging/dev environment, validate functionality and performance baseline.

4. 04. Production Dry Run

   Practice production migration playbook in non-production with timing and rollback test.

5. 05. Data Migration

   Database migration with DMS replication running, validate data consistency.

6. 06. Production Cutover

   Execute tested cutover playbook, monitor validation criteria, confirm rollback is available.

7. 07. Post-migration Optimisation

   Right-sizing, Reserved Instance purchasing, cost attribution and decommission old environment.

Cloud Migration Engagements

Enterprise workloads migrated to cloud with zero data loss and minimal downtime.

• Monolith-to-Microservices Migration on AWS

  Challenge: Legacy Java monolith on bare metal — single point of failure, 4-hour deployment cycles, no horizontal scaling capability.

  Architecture: Strangler fig pattern: new microservices in ECS Fargate running in parallel with monolith. AWS DMS for continuous database replication to Aurora. Route 53 weighted routing for traffic cut-over control. Blue/green deployments via ECS service updates.

  Outcome: Migration completed in 14 weeks with zero data loss. Deployment time reduced from 4 hours to 8 minutes. Infrastructure cost reduced 35% through right-sizing and reserved instances.

• Oracle to PostgreSQL Migration — Financial Services

  Challenge: Oracle licensing costs consuming $800K/year. Business required migration to PostgreSQL without disrupting 24/7 trading operations.

  Architecture: AWS SCT for schema conversion with manual PL/SQL to PL/pgSQL rewrite for 340 stored procedures. DMS continuous replication for live cutover. Parallel run validation comparing query results between Oracle and PostgreSQL for 30 days before cut-over.

  Outcome: Eliminated $800K/year Oracle licensing. 48-hour maintenance window for final cut-over. 340 stored procedures migrated with functional equivalence validated.

• Hybrid Cloud for Regulated Workloads

  Challenge: Financial regulator required specific data residency rules — customer PII must stay on-premises while compute-intensive workloads move to cloud.

  Architecture: AWS Direct Connect for 10Gbps private connectivity. GCP Anthos for consistent Kubernetes management across on-prem and cloud clusters. HashiCorp Vault for secrets management across environments. Istio service mesh for encrypted service-to-service communication.

  Outcome: Full regulatory compliance with data residency requirements. 60% of compute moved to cloud yielding $1.2M/year infrastructure savings. Zero security incidents post-migration.

Frequently Asked Questions