The Microsoft Cloud Adoption Framework comprises several pillars that outline how to bring your business to the cloud successfully.
This framework also includes a list of antipatterns, things to avoid when migrating to Azure.
In this article, we’ll cover them so you’ll know what you shouldn't do in Azure.
Reading time 6 minutes Published: 15 October 2025
In total, 16 antipatterns belong to the different pillars of the Cloud Adoption Framework (CAF).
| Methodology | Antipattern |
| Strategy | Inadequate motivation |
| Strategy | Misaligned motivation |
| Plan | Wrong cloud operating model |
| Plan | Wrong service model |
| Plan | Replacement instead of modernisation |
| Ready | Preview services in production |
| Ready | Inaccurate resiliency and availability assumptions |
| Ready | IT as cloud provider |
| Adopt | Lack of guardrails |
| Adopt | Lack of assessments |
| Adopt | Forced architecture |
| Adopt | Single subscription |
| Manage | Neglect of business outcomes |
| Govern | Misaligned shared responsibilities |
| Govern | Inaccurate out-of-the-box security assumptions |
| Govern | Custom compliance or governance frameworks |
| Organise | IT cost centres |
| Organise | Platform development without business approval |
| Organise | Core business function outsourcing |
| Organise | Technical decision makers instead of cloud engineers |
Now let's dive deeper into each:
The first pattern, as laid out by the CAF is called inadequate motivation. Many companies announce a cloud-first or a cloud-only strategy without knowing precisely what it means or how to measure it. When you move all old systems to the cloud, ask yourself; Did you really optimise for the cloud or just move the problem?
How to avoid: Define clear, measurable benefits. Set KPIs and goals tied to business outcomes.
Why move to the cloud? Maybe it’s clear to you, but not everyone understands what a cloud-only strategy implies or why it's being adopted. This creates friction, slows adoption and results in misaligned motivation.
How to avoid: To avoid this antipattern, clearly define and document the reasons for moving to the cloud, and communicate them effectively to stakeholders across the company.
With the wrong cloud operating model, we refer to how a company operates and uses technology in the cloud. There’s a significant shift from traditional IT, where the focus is on owning and managing hardware, to the cloud, where attention is now centred on digital assets and workloads.
How to avoid: Your company needs to prepare for this shift and align the cloud operating model closer to the business.
The next antipattern is choosing the wrong service model, in specifcally, blindly moving to PaaS is the antipattern here, which can feel contradictory to what Microsoft typically suggests.
Moving from an IaaS to a PaaS solution in the cloud may not always be the right choice, especially if your company is not yet ready for this change. Companies often overlook that moving from IaaS to PaaS changes all underlying processes and responsibilities.
How to avoid: Choose the right service model depending on your company's readiness. If you’re not ready yet for PaaS, start with IaaS in the cloud and then transition to PaaS solutions as your business matures.
The last antipattern in the plan pillar is replacement instead of modernisation. Applications based on PaaS and SaaS are generally easier to maintain and usually require minimal management effort. Some companies attempt to modernise outdated, complex architectures by completely replacing them with SaaS or cloud-native solutions. These replacement projects can be large, complex, and costly.
How to avoid: Explore the possibility of replacing your product with a SaaS solution where it makes sense, rather than focusing solely on modernisation.
You shouldn’t use services that are still in preview for production workloads. Microsoft offers different preview stages to show how close a service is to being production-ready. But preview services come with no SLA, no official support, and no finalised pricing.
How to avoid: Use preview services only for testing environments or for evaluating how they work, and not for business-critical systems.
The next antipattern is inaccurate resilience and availability assumptions. A common mistake is treating a single VM SLA as sufficient for a mission-critical workload.
For example: Deploying an entire application on a single IaaS VM assumes 99.9% uptime to cover the business need. What is often overlooked are dependencies such as networking and connectivity. When that VM fails, the application fails, and the SLA only gives you a service credit.
How to avoid: Instead of relying on SLA numbers, you should architect for disaster recovery and resilience.
Here, the IT department takes on responsibility for reference architectures and for providing IaaS and PaaS solutions to the business. This scope is often too broad.
How to avoid: Use frameworks like the Cloud Adoption Framework and the Well-Architected Framework. Set up a Cloud Center of Excellence (CCoE) to define strategy and governance. Push SaaS solutions where possible and implement CI/CD pipelines for IT tooling and code repositories.
The manage pillar only holds one antipattern: neglect of business outcomes. This anti-pattern occurs when technology adoption takes priority over business outcomes.
For example: you might roll out a new CI/CD platform because of its advanced features, only to find later that it did nothing to improve deployment speed or time to market.
How to avoid: Align business and technology goals, ensuring they are measurable. Success should always be tied to clear, tangible outcomes and not just the adoption of new tools.
When moving to the cloud, it’s not always clear who is responsible for what.
For example: One might deploy a virtual machine and assume the cloud provider handles operating system updates. That’s not the case, and it can create security risks.
How to avoid: Know your responsibilities in the cloud by learning the shared responsibility model and create a readiness plan and a RACI table to define responsibilities.
Microsoft provides many security options, but you still need to choose which controls to apply. Just moving to the cloud doesn’t guarantee security.
How to avoid: Implement security guardrails and policies to protect against security breaches and follow Azure’s security best practices. You can also run the Microsoft Cloud Security Benchmark, which is a good first step to assess and improve your current environment.
Some organisations try to create their own compliance standards. This often leads to incompatibilities with cloud environments.
How to avoid: Use established standards such as CIS Controls, NIST, or regional frameworks like BIO in the Netherlands instead. Microsoft’s published security frameworks are widely adopted by governments, banks, and healthcare organisations. If they meet those requirements, they’re almost certainly sufficient for your environment, too.
Many companies treat IT only as a cost rather than recognising the value it delivers.
Example: The board treats IT as a slow, expensive service provider, not realizing that specific business units, like mobility, consume most of the resources IT procures. IT invests in shared assets, but the focus remains on cost rather than the value IT delivers.
How to avoid: Make business units accountable for the cloud resources they use. This creates cost transparency and ties spending directly to business impact. Tags in Azure are a simple way to allocate costs properly.
If IT builds a platform without involving business units, developers may lack access, permissions, or confidence in the solution. This often leads to shadow IT, where teams set up their own Azure subscriptions, leading to higher security risks.
How to avoid: Avoid creating IT silos by involving developers and technical decision-makers (TDMs) early so the platform supports real business needs.
Consulting firms and managed service providers (MSPs) can speed up adoption and offer expertise, but critical design and strategy decisions should stay with your company. Partners can advise, but ownership of decisions must remain internal.
How to avoid: Keep outsourcing in mind as a good cost-cutting strategy but make decisions within your company when they involve critical design areas like governance, risk, compliance and identity.
Decision-makers are important, but without skilled engineers who can deploy infrastructure as code and implement policy-driven governance, adoption stalls. Cloud engineers are essential for properly implementing cloud automation and landing zone concepts.
How to avoid: Build teams with a balanced mix of leadership and hands-on engineering expertise.
Do you need help creating scalable and secure solutions in Azure? Intercept can help. As experienced Azure Expert MSP, we empower business solutions on a large scale and in complex situations on Azure.