Forty-two percent of cloud migrations fail to meet their original timeline or budget targets, and in regulated industries the failure rate climbs higher. The root cause is rarely technical — it is almost always a failure to treat compliance as a first-class architectural constraint rather than a post-migration checkbox. If you operate in financial services, healthcare, or government, your migration strategy must begin with your regulatory obligations and work backward to infrastructure decisions. Anything else produces rework, audit findings, and executive-level risk exposure.
A compliance-first architecture starts with your landing zone — the foundational multi-account structure that enforces guardrails before any workload arrives. AWS Control Tower provides an opinionated landing zone with pre-configured guardrails mapped to common compliance frameworks. Pair it with AWS Organizations to enforce service control policies (SCPs) that prevent engineers from provisioning resources in non-approved regions, disabling logging, or creating public-facing endpoints without explicit approval. This is not optional hardening — it is the structural foundation that makes everything downstream auditable.
Data residency is the constraint that kills migrations quietly. Before you move a single workload, map every data classification in your estate to its residency requirement. Some regulations (GDPR, certain APRA prudential standards, HIPAA) impose restrictions on where data can be stored and processed. AWS Config rules can continuously evaluate whether resources comply with region restrictions, and AWS CloudTrail provides the immutable audit trail that regulators expect. Build these controls into your landing zone from day one — retrofitting them after migration is an order of magnitude more expensive.
The 6R framework (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) is your decision model for each workload, but regulated industries need a seventh consideration: re-risk. For each application, assess whether migration changes its risk profile. A rehosted application inherits cloud-specific risks (shared responsibility model gaps, IAM misconfiguration) while potentially shedding on-premises risks (physical access, hardware failure). Document these risk transitions explicitly — your auditors will ask.
Phase one is assessment, and it should take exactly four weeks. Spend week one on regulatory mapping: which frameworks apply, which controls are non-negotiable, which have flexibility in implementation. Weeks two and three focus on application discovery and dependency mapping — use AWS Application Discovery Service or a third-party tool, but validate the output manually for your top-20 workloads. Week four produces your migration wave plan, prioritised by business value and regulatory complexity. Do not skip this phase to look faster. The organisations that skip assessment are the ones in the 42% failure statistic.
AI Readiness Checklist
Assess whether your enterprise is ready for production AI — the same framework we use in discovery calls.
Phase two is your pilot migration, spanning eight weeks. Select two to three workloads that represent different migration patterns (one rehost, one replatform) but are not business-critical. The pilot validates your landing zone controls, your CI/CD pipeline for infrastructure, your monitoring stack, and your incident response procedures. Critically, it also validates your compliance evidence collection — can you produce the artifacts your auditors need without manual effort? If the answer is no, fix it now while the blast radius is small.
Phase three is the production migration, running twelve to sixteen weeks depending on estate size. Migrate in waves of five to ten applications, with a compliance gate between each wave. AWS GuardDuty should be active across all accounts from day one of this phase, providing continuous threat detection. Each wave follows the same pattern: pre-migration security review, migration execution, post-migration validation, compliance evidence generation, and formal sign-off. Resist the pressure to accelerate by skipping gates — one compliance finding in production can halt your entire programme.
Phase four is optimisation, and it never ends. Once workloads are running in AWS, shift focus to cost optimisation (right-sizing, reserved capacity, spot for non-critical workloads), operational maturity (runbook automation, chaos engineering within compliance boundaries), and continuous compliance monitoring. AWS Config conformance packs provide ongoing assessment against frameworks like PCI DSS, HIPAA, and NIST 800-53. Set up automated remediation for low-risk drift and alerting for high-risk drift.
The most common pitfall is treating security and compliance teams as approvers rather than collaborators. Embed a security engineer and a compliance analyst in your migration squad from week one. They should be reviewing architecture decisions in real time, not receiving completed designs for rubber-stamping. The second most common pitfall is underestimating the identity and access management (IAM) effort — plan for IAM design to consume 20-30% of your architecture time.
Cost estimation failures sink migrations politically even when they succeed technically. Build your business case with three scenarios: optimistic (everything rehosted, minimal refactoring), realistic (30% of workloads need replatforming, 10% need refactoring), and pessimistic (significant refactoring required for compliance). Present the realistic scenario as your baseline and hold a contingency reserve for the gap to pessimistic. Regulated industries almost always land between realistic and pessimistic due to compliance-driven architectural changes discovered during migration.
Finally, plan your exit before you enter. Regulated industries face concentration risk concerns from auditors and boards. Document your portability strategy — which workloads use cloud-agnostic patterns, which are locked to AWS-specific services, and what the cost and timeline of exit would be. You do not need to avoid AWS-native services (they deliver significant value), but you need to make the lock-in decision consciously and document it for your risk committee. This is not about actually leaving — it is about demonstrating governance maturity to your regulators.
Want to discuss these ideas?
We're always happy to talk shop about cloud, AI, and what it takes to move from pilot to production.