Cloud migration looks simple on a vendor slide deck: lift your workloads, enjoy elasticity and cost savings, repeat. The reality is more nuanced. After leading cloud migrations for organisations ranging from 50-person SaaS startups to national government agencies, we have accumulated a clear picture of what works and — more instructively — what repeatedly goes wrong.

Mistake One: Lifting and Shifting Legacy Architecture

Moving a monolithic application to a single cloud VM is not cloud migration — it is hosting migration. You get the cloud bill without the cloud benefits. The workloads that deliver real value in the cloud are those re-architected to be cloud-native: containerised, stateless where possible, using managed services for databases, queuing, and caching rather than running these on EC2.

Mistake Two: Underestimating Data Migration Complexity

Compute migrates in hours. Data migrates in weeks or months, and rarely cleanly. Schema inconsistencies, referential integrity issues, character encoding problems, and sheer volume mean that data migration almost always takes two to three times longer than estimated. Budget accordingly, and invest in data validation tooling before you start.

Mistake Three: Neglecting Cost Architecture

Organisations consistently underestimate their cloud bills. The culprits: over-provisioned instances, data egress fees (which are rarely accounted for upfront), unused resources in development and test environments, and storage costs that grow without governance. Implement a cloud cost management tool from day one — FinOps is not optional.

What the Successful Migrations Have in Common

A clear business outcome driving the migration (not “because cloud”), executive sponsorship with real authority to make architectural decisions, a dedicated migration team rather than a committee, and a realistic multi-phase plan that delivers value incrementally rather than promising everything at once.

SaaS platforms are high-value targets: they hold data for multiple customers, run continuously on public internet endpoints, and are often built by small teams moving fast. The combination creates systematic security risks that attackers know how to exploit. This checklist covers the controls that eliminate the most common vulnerability classes.

Authentication & Access Control

• Multi-factor authentication mandatory for all admin and privileged users
• OAuth 2.0 / OIDC with short-lived access tokens (15 min max), long-lived refresh tokens stored securely
• Role-based access control (RBAC) with deny-by-default — users get no permissions unless explicitly granted
• Separate authentication contexts for users and service-to-service calls; no shared credentials

Data Security

• Encryption at rest for all customer data — use cloud KMS, not application-managed keys
• TLS 1.2+ for all data in transit; enforce HSTS with a minimum 6-month max-age
• Tenant data isolation at the database level — row-level security or separate schemas, not application-layer filters
• Audit logs for all data access and mutations — immutable, stored outside the primary database

Application Security

• Parameterised queries everywhere — no string concatenation in SQL
• Input validation at every API boundary — reject malformed requests before they reach business logic
• Content Security Policy headers to prevent XSS; sanitise all HTML output
• Rate limiting on all authentication endpoints; exponential back-off on failed login attempts
• Dependency scanning in CI — flag known CVEs before they reach production

Operational Security

• Principle of least privilege for all service accounts and IAM roles
• Secrets management via a vault (HashiCorp Vault, AWS Secrets Manager) — no secrets in environment variables or source code
• Automated security scanning in your deployment pipeline
• An incident response plan that has actually been rehearsed