Data
AI
The Stack Underneath
Hello, we are BRILLIAN’S. Trying to make an effort to put the right people for you to get the best results. Just insight !
Your security team is still going through infrastructure your developers pushed live, what, six weeks ago now? Finance has no idea what's been spent. And someone from the business side keeps asking why the migration is taking this long, as if asking again will change the answer.
It's the same conversation, different company, every time.
The problem isn't the people. It's that everyone started moving before anyone agreed on who owned what. AWS CAF was built to close that gap, not after the migration gets complicated, but before the first workload moves. It connects business and technical decisions into a single cloud migration strategy before large-scale execution begins.
Most teams hand cloud adoption entirely to engineering. AWS CAF pushes back on that. It pulls security, finance, operations, and platform teams in from day one, which sounds obvious until you realise almost nobody actually does it.
In this post: how the six perspectives divide ownership, what the four phases look like in practice, how to build a working cloud transformation roadmap, and where AWS CAF ends and the Well-Architected Framework begins.
Ready to build your AWS cloud migration strategy without the rework? Talk to the Brilworks team.
AWS CAF is not a migration tool. People reach for it like one and then wonder why it doesn't feel like progress. What it actually does is sort out ownership across security, finance, operations, and platform, before anyone starts making architectural decisions that are painful to reverse.
That sequencing matters more than most teams realise until they're already untangling something messy. Without it, things come apart in a specific, predictable way. Security audits infrastructure developers deployed and moved on from weeks earlier. Finance can't reconcile spend because three business units are provisioning independently with no shared cost model. Compliance drifts because ownership was assumed, never assigned. Then comes the rework, unbudgeted, always slower than expected.
We've seen this up close. A mid-sized financial services team started migrating without sorting ownership first. Four months in, two separate teams had each built identity management solutions, neither knowing the other had done it. Their compliance controls hadn't been mapped to the new environment at all. Pulling in CAF at that point meant going back to conversations they should've had in week two, when fixing things was still cheap.
That's what the framework actually prevents. Not slow migration. The kind of drift that turns a four-month project into a six-month rebuild.
What AWS Cloud Adoption Framework helps you do:
AWS CAF is the right framework when your migration involves multiple teams, multiple stakeholders, and more than a handful of workloads. If security, finance, and engineering are all going to touch this project, and they will, CAF gives you the structure to stop them from working at cross purposes.
Specifically, it makes sense when:
You're migrating more than a few workloads and need a repeatable process, not a one-off lift-and-shift. You have stakeholders across business, finance, and technical functions who need to stay aligned over months, not days. Your organisation has compliance or regulatory requirements that need to be mapped to the new environment before anything goes live. You've tried a cloud migration before and it stalled, usually a sign that the alignment work was skipped the first time.
It doesn't make sense when you're a small team moving one or two internal applications with a single owner and no compliance constraints. In that situation, CAF adds process overhead that a straightforward migration checklist handles faster.
The honest version: we've seen teams apply CAF to migrations that didn't need it and spend six weeks in planning that could've been two. We've also seen teams skip it on migrations that absolutely did need it and spend six months fixing what two weeks of alignment would've prevented. The question isn't whether CAF is a good framework. It is. The question is whether your migration is complex enough to justify it, and the answer is almost always yes once more than one team is involved.
Each of the six AWS CAF perspectives assigns clear ownership to a specific stakeholder group. Here's how they break down in practice:
| Perspective | Common Owner | Sample Capabilities | Key Deliverables | Migration Example |
|---|---|---|---|---|
| Business | CFO, COO | Business case development, portfolio management | ROI targets, risk register | Quantifying cost savings before committing to a 200-node migration |
| People | HR, Change Manager | Training programs, workforce planning | Skill gap analysis, reskilling roadmap | Retraining ops staff on CloudWatch before go-live |
| Governance | PMO, Compliance | Cost control, policy enforcement | Tagging standards, budget guardrails | Blocking untagged resource creation via AWS Config rules |
| Platform | Cloud Architect | Landing zone design, networking, IaC | Reference architecture, VPC blueprints | Deploying AWS Control Tower with multi-account structure |
| Security | Security Architect | IAM baseline, threat detection, encryption | SCPs, GuardDuty findings runbook | Enforcing least-privilege roles before migrating PHI workloads |
| Operations | SRE, Service Delivery | Monitoring, incident management, capacity planning | CloudWatch dashboards, incident runbooks | Defining P1 response procedures before production cutover |
These three perspectives determine whether your cloud investment actually pays off, and most teams underestimate at least one of them.
Business stakeholders need concrete numbers from day one. Building a cloud business case that ties migration costs to revenue outcomes is the first real deliverable, not an afterthought. People leaders handle the harder problem: retraining engineers who built careers on on-premises infrastructure. That's not a training programme, it's a change management problem, and the skills gap doesn't close on its own.
Governance is where good intentions either get enforced or quietly ignored. AWS Config rules that reject non-compliant resources automatically, that's governance. A PDF on a SharePoint nobody opens isn't. Solid cloud cost control frameworks belong here too: tagging policies, budget alerts, and chargeback models that keep spending visible before it becomes a problem.
Platform engineers typically start with a landing zone built on AWS Control Tower, establishing account vending, centralized logging through AWS CloudTrail, and a hub-and-spoke network model using Transit Gateway. Get this wrong and every team builds their own version of the same thing.
Security architects then layer on an IAM baseline using Service Control Policies to cap permissions at the organisation level, followed by threat detection through Amazon GuardDuty and Security Hub. Operations closes the loop with CloudWatch dashboards covering latency, error rates, and cost anomalies, plus written incident runbooks. That last part matters more than people think. Your on-call engineer at 2 AM shouldn't be improvising their way through a production outage. If the runbook doesn't exist before the incident, it gets written during one.
The AWS cloud adoption phases give your migration a spine. Without them, you end up with teams moving fast in different directions, which is how you get a modernized data layer sitting on top of processes nobody updated.
CAF structures the journey across four phases. Here's what each one actually involves:
| Phase | Key Inputs | Who's in the Room | What You Produce | Exit Criteria | Watch Out For |
|---|---|---|---|---|---|
| Envision | Business goals, current pain points | C-suite, architects, finance | Business case, success metrics | Executive sign-off | Vague outcomes with no measurable targets |
| Align | Assessment results, capability gaps | All six perspective leads | Transformation roadmap, workstreams | Approved plan with owners | Skipping perspectives that feel "handled" |
| Launch | Roadmap, governance controls | Engineering, security, ops | Pilot workloads in production | Operating model validated at scale | Treating pilots as permanent rather than learning exercises |
| Scale | Pilot learnings, cost data | Platform, finance, product teams | Expanded portfolio, optimized spend | Full portfolio coverage | Scaling broken processes faster than fixing them |
Now take one real initiative: modernizing a customer portal. That single project touches all four transformation domains at once.
| Domain | What Changes |
|---|---|
| Technology | Re-platforming legacy systems to managed AWS services, rebuilding on cloud-native architecture |
| Process | Introducing continuous integration pipelines, updating incident response procedures for distributed systems |
| Organization | Redefining team ownership, upskilling developers on cloud-native patterns |
| Product | Shifting from release cycles to faster feature delivery using cloud scale |
One initiative. Four domains. All moving simultaneously.
How the framework fits together:
Perspectives tell you which voices need to be in the room. Domains tell you what kind of work is happening. Phases tell you where you are in the journey. All three layers work together, not in isolation.
Knowing the theory behind AWS CAF is one thing. Turning it into an actual plan your team can execute is another. Here's how to move from framework concepts to a working cloud transformation roadmap.
Before you build anything, you need an honest picture of where your organisation actually stands, not where you assume it stands. Those are usually different. AWS offers the Migration Evaluator and the AWS CAF Action Plan worksheet to help you score capabilities across all six perspectives before anything moves.
The scoring rubric is straightforward: 1 = absent, 2 = defined, 3 = repeatable, 4 = optimised. Score each capability, then treat anything rated 1 or 2 as a gap that needs addressing before or during migration, not after.
A fintech company we've seen go through this came out with a Platform score of 3. Solid. But Governance sat at 1 and Security at 2. Both became immediate backlog items, the security team got assigned IAM policy ownership, and they hired a cloud governance lead specifically to establish cost controls. Neither of those gaps was obvious before the assessment. Without it, both would've shown up mid-migration, at exactly the wrong moment, with no easy fix in sight.
Assessment findings directly shape your roadmap structure. A practical 90-day starting plan might look like this:
Each workstream needs a named owner from the relevant CAF perspective. The fintech example above assigned the CISO ownership of the security baseline and a platform engineer as the pilot migration lead. Milestones tied to business outcomes, not just deployment tasks, keep executives engaged.
Run two-week sprints against your roadmap. At the end of each sprint, review four metrics: deployment frequency, mean time to detect security incidents, cloud cost variance, and team ticket resolution time.
For pilot workloads, choose applications that are non-critical, relatively self-contained, and owned by a team willing to experiment. The fintech company picked an internal reporting tool. Small enough to recover quickly if something breaks. Representative enough to expose real operational gaps.
After each iteration, feed findings back into the backlog. If monitoring gaps appear during the pilot, that becomes the next sprint's priority, not a future phase item.
| Mistake | Why it happens | Early warning signs | Corrective action |
|---|---|---|---|
| Treating CAF as an IT-only exercise | Tech teams lead the project and business stakeholders stay hands-off | No executive sponsor, finance team unaware of migration scope | Assign perspective owners from HR, finance, and legal on day one. Good looks like: each CAF perspective has a named leader with decision-making authority. |
| Skipping capability assessment | Teams assume they know their gaps, or want to skip to the "real work" | Migration timelines slip within first 60 days, surprises keep surfacing | Run a structured maturity scoring session across all six perspectives before any workload moves. Good looks like: a documented gap list that directly shapes your roadmap. |
| Failing to define owners | Roadmap gets built but no one is accountable for specific workstreams | Tasks sit unactioned, teams debate who handles incidents | Name one owner per capability, not a committee. Good looks like: every workstream has a single person whose performance is tied to its outcome. |
| Moving workloads before controls are ready | Pressure to show progress pushes migrations ahead of governance | Security team auditing infrastructure weeks after it went live | Gate production migrations behind baseline guardrails: IAM policies, logging, cost alerts. Good looks like: a launch checklist that security signs off before any workload goes live. |
| Relying on unsupported ROI claims | Business cases get inflated to secure budget | Executives lose confidence when early numbers don't match projections | Anchor ROI to specific, measurable outcomes tied to real workloads. Good looks like: a business case reviewed by finance with conservative and optimistic scenarios documented. |
Before you start your AWS CAF program
- Executive sponsor identified and briefed on CAF scope
- Perspective owners named across all six areas
- Capability assessment scheduled before roadmap work begins
- Governance guardrails defined and approved by security
- Business case reviewed with finance and tied to measurable outcomes
- Migration phases gated on readiness, not calendar dates
The short answer: AWS CAF prepares your organization for cloud change, while the AWS Well-Architected Framework evaluates whether specific workloads are built correctly. Both matter. They just operate at completely different levels.
| Dimension | AWS CAF | AWS Well-Architected Framework |
|---|---|---|
| Scope | Entire organization | Individual workloads and architectures |
| Primary users | Executives, architects, HR, finance, security leads | Cloud architects, developers, solution owners |
| Timing | Before and during adoption planning | During design, pre-launch, and post-migration reviews |
| Core question | Is your organization ready to adopt cloud? | Is this workload built to AWS best practices? |
| Outputs | Transformation roadmap, capability gap analysis | Review report, risk findings, improvement recommendations |
| How they complement each other | CAF creates the organizational foundation | Well-Architected validates what gets built on top of it |
Think of it this way: CAF tells you whether your teams, governance, and processes are ready to go. The AWS Well-Architected Framework tells you whether the thing you built is actually good once you get there.
When to start with CAF: You're planning a migration, haven't yet defined ownership across teams, or leadership is asking "where do we even begin?"
When to run a Well-Architected review: A specific application is about to go live, recently migrated, or showing performance and cost issues in production.
In a broader migration program: CAF runs first to align stakeholders and close capability gaps. Well-Architected reviews then validate each workload as it lands in AWS. If you're still deciding whether AWS is the right platform entirely, our breakdown of AWS vs Azure covers where each one wins and where it doesn't. Neither replaces the other. Together, they cover both the organizational and technical dimensions of a successful cloud program.
We don't run AWS CAF by the book on every engagement. For smaller migrations, Envision and Align compress into a single working session. For larger ones, we run them properly. The framework is a tool, teams that treat it like a contract usually spend more time managing the framework than running the migration.
What we do use every time is the capability assessment upfront. Before touching a single workload, we score across all six perspectives to find the gaps that will cause problems at month three if nobody addresses them in week two. The perspectives we lean on hardest are Security and Platform, IAM baseline, landing zone design, Service Control Policies, all locked down before anything migrates. We've inherited enough projects where this was skipped to know what it costs to retrofit security onto infrastructure that's already live. It's part of why we pursued AWS partner status — the process forced us to validate our own practices against the same standards we apply to client migrations.
The People perspective is the one clients most often want to skip. We push back on that every time.
If your migration involves multiple teams and compliance requirements, talk to us about AWS consulting and migration services — we'll tell you whether CAF is the right starting point or something lighter gets you there faster.
The AWS Cloud Adoption Framework isn't a checklist you hand to engineering and check off at the quarterly review. It's the operating model that holds strategy, governance, security, and delivery together, and without it, those four things quietly drift apart until someone notices the damage.
Here's what actually matters when you use it: each perspective makes real demands on your organisation, and skipping the ones that feel "already handled" is exactly how teams end up back at square one at month four. Don't rush to Scale while Launch is still shaky. And before you expand workloads broadly, turn your assessment findings into an actual cloud transformation roadmap, not a slide deck, a working plan with owners.
Assess where you stand across all six perspectives. Figure out what the first 90 days need to deliver. We've watched teams skip that window and spend the next six months recovering from it.
Ready to build your cloud transformation roadmap with a team that has done this before? Talk to Brilworks about AWS consulting and migration services.
AWS Cloud Adoption Framework is a structured guide that helps your organization plan and execute cloud migration by addressing both technical and business readiness together. Think of it less as a technical manual and more as an organizational playbook. A retail company using it, for example, would align their finance, HR, and security teams around cloud goals before a single server gets moved.
The six AWS CAF perspectives are Business, People, Governance, Platform, Security, and Operations. Business and People perspectives belong to executives and HR leaders, Governance sits with compliance and PMO teams, and Platform, Security, and Operations fall to your technical staff. Each perspective has a defined owner so nobody ends up guessing who's responsible when decisions need to get made.
The AWS cloud adoption phases are Envision, Align, Launch, and Scale, running in sequence. Envision builds your business case, Align closes capability gaps, Launch proves your model with real workloads, and Scale expands what's working across your full environment. Most organizations underestimate how much preparation Envision and Align require before touching production systems.
AWS Cloud Adoption Framework operates at the organizational level, helping you build the capabilities needed across your entire enterprise for a successful migration. The AWS Well-Architected Framework works at the workload level, reviewing whether a specific application follows AWS best practices. You use both, but at different stages and for different purposes.
A thorough CAF assessment and initial roadmap typically takes four to eight weeks, depending on your organization's size and complexity. Larger enterprises with multiple business units often run longer because stakeholder alignment takes time. Rushing this phase tends to produce a roadmap that looks complete on paper but misses critical gaps discovered only after migration begins.
For most mid-sized organisations, Envision and Align take four to six weeks — that's the capability assessment, gap analysis, and roadmap. Launch adds another four to ten weeks depending on workload complexity. Teams that compress the early phases to save time almost always spend that time back later, usually during a production incident or a compliance review.
Not always. If you're a small team moving one or two internal applications with a single owner and no compliance requirements, a straightforward migration checklist gets you there faster. Where CAF earns its place for SMBs is when compliance is involved or when more than one team is touching the migration — because that's when ownership gaps start costing real money. Size doesn't determine whether CAF is necessary. Complexity does.
You might also like
