Cloud 7 min read

Cloud Migration Anti-Patterns: 7 Mistakes We've Seen (and Helped Fix)

CS
CELESDEV Solutions
Cloud & Platform Practice

Cloud migrations fail in predictable ways. Having assessed and remediated dozens of cloud environments, we catalogue the patterns we encounter most frequently — and the architectural responses that fix them.

Anti-Pattern 1: Lift and Shift Everything

Moving on-premises VMs to cloud VMs without any re-architecture is tempting for speed. The result is cloud infrastructure with none of the cloud benefits: you pay on-demand pricing for always-on instances, miss managed services that would eliminate operational overhead, and inherit all the operational complexity of on-premises with higher costs. The fix: a portfolio classification exercise that categorises workloads as Retire, Retain, Rehost, Replatform, or Refactor before any migration begins.

Anti-Pattern 2: Ignoring Egress Costs

Cloud providers charge for data leaving their network. For data-intensive workloads, egress costs can exceed compute costs. We've seen architectural decisions that were rational in on-premises contexts — centralised logging, replicated databases, cross-region backups — become expensive in cloud contexts where every byte crossing a boundary has a price. Egress cost modelling must be part of architecture reviews.

Anti-Pattern 3: Security Groups as the Only Security Layer

Many migrated environments use security groups (or NSGs) as their sole network security control. This is insufficient. A defence-in-depth model requires: WAF for public-facing workloads, private subnets for compute that has no business being public-facing, VPC endpoints to avoid internet traversal for AWS service calls, and host-based security agents for threat detection. Security groups are the last line of defence, not the only one.

Anti-Patterns 4–7 (Summary)

Key Takeaways
  • Classify every workload before migrating — not everything should be lifted and shifted
  • Model egress costs as part of architecture design, not as a surprise after go-live
  • Establish landing zone baselines before migrating any workloads
  • All cloud infrastructure must be managed as code from day one
Related Articles
Cloud
Azure Landing Zones with Terraform: Subscription Vending at Scale
Read article →
Cloud
AWS Well-Architected Reviews: Turning a Checklist into Actionable Architecture
Read article →
FinOps
FinOps at Scale: Building a Cost-Aware Engineering Culture
Read article →