Skip to main content

Introduction to the Microsoft Cloud Adoption Framework

Microsoft offers a "movement guide" for both porting existing to and starting brand new systems in Azure. There are 8 methodologies in their guide. Each has its own section in the module.

Strategy

This is a weird methodology because you can just summarize it as "have a plan before just moving stuff to the cloud willy-nilly" but Microsoft also gives guidance on how to actually plan your plan. This is where you develop your high level ideas for what services you want, who will help set them up, and what existing things will be retired.

They have five steps that you go through when figuring out how to get [x] resource into or how to add [y] to Azure, and you repeat those five steps every time you move or add something to Azure. The steps are:

  • Assess your current plan to move to Azure
  • Define why you're moving to Azure
  • Define who on your team will do what when enacting the plan
  • Prepare your organization for moving any given resource to Azure, or making a new resource in Azure
  • Inform your strategy; this is a strangely named point for "hammer out the finer details for implementing security layers, how your teams will maintain the resources, etc."

Plan

Planning is different from strategy in that your strategy is high-level ideas and your plan is concrete steps. Microsoft advises the following categories for planning:

  • Prepare for your organization
    • Prepare your organization by determining what kind of org your client/business is (startup, midsize, corporate, etc.) and use an appropriate planning framework
    • Choose a management model that fits your client/business
    • Write down the tangible responsibilities for your client/business's governance, security, and management in Azure
    • Document which teams and individuals will be in charge of which tangible responsibilties
  • Prepare your people
    • Assess who needs to be ramped up on Azure/cloud skills
    • Structure training regardless of skill level
    • Establish continuous learning via courses or pair/mob work
  • Discover existing workload inventory
    • This is the nitty-gritty of figuring out what needs to either be migrated or created on Azure and moving any existing data, if applicable
    • Move the things that are easiest to move and reintegrate first, then move up in complexity and volume
  • Assess your workloads for cloud migration
    • Anything that's offline will need to be moved. Use this category for doing migration tests and figuring out dependencies between your existing resources & data.
    • This is a prime time for analyzing and refactoring code that will move to Azure either as a Function, a Container, an App Service, and/or a WebJob
    • Create and maintain a list of risks for the various resource migrations/creations; what could go wrong? What data might be at risk? How do we mitigate it?
  • Estimate total cost
    • This is the business-interested part: how much is all this shit gonna cost? Use the Pricing Calculator that Microsoft offers on the Azure site to figure out what running your services might run you per month, annually, etc.

Ready

This is the green light "methodology" where you're actually in Azure setting stuff up. You're not really spinning up resources at this point but you're in Azure setting things up like resource groups and roles.

Microsoft offers an "Azure Setup Guide" for the nitty gritty work, but this module/methodology has some bulletpoints for things to do or keep in mind:

  • Define a cloud operating model
    • This should be done already in "Plan" but you may need to alter your plan even here
  • Implement landing zones
  • Develop necessary skills
    • This should also be done already in "Plan" but now's as good a time as any
  • Avoid antipatterns
    • Microsoft made this section fluffy but it boils down to "if you didn't do your homework on researching Azure offerings and planning the move, it'll hurt the effort and it'll suck"

Migrate

This is the moment of truth where you're spinning up resources, migrating existing on-premises resources, and tweaking your resources so that they leverage Azure features and connectivity.

Keep your list of risks on hand because this is where the fun and pain begins. People will have to use the resources that're being moved and spun up, and they'll run into issues with permissions and usage at minimum.

Record all blockers and issues so that other teams run into fewer roadblocks and other spin ups are smoother.

Modernize

This comes later as everything you've wanted to set up for either your client or business for this round is up and running.

Now that your resources have a somewhat clean slate, this is a great time to revisit how your resources are used and accessed. There may be optimizations and new workflows you can leverage with things like Azure CLI.

There's a lot of plan-yapping in this section but it's all good info about good ways to structure modernization efforts once you have resources on the cloud.

Cloud-native

This module is about changing your mindset for the resources you've moved or created to "cloud first" thinking. Now that you're serverless with some kind of resource, can you leverage other Azure/cloud resources to expand your client's/business's offerings?

Govern

Now that you're getting resources moved to Azure and making new resources in Azure, you need to adjust your mindset for "environment" control. Everything was either on-premises or very limited in Azure, but now everything is in Azure and you need to adjust to how to control everything.

The long & short is that you'd want to select members for a "cloud architecture" team that manage the vision of how your client/company deploy and work with Azure services; tracking risks, establishing rules, and so on.

There's a proper documentation section for governing here.

Manage

This really isn't a great module/methodology page because there's so much nitty-gritty about how you manage and protect your resources while enabling your developers to make and use new ones.

The management documentation feels more appropriate to read.

Secure

Same problem as the manage methodology: you're better off reading the security methodology documentation versus the summary.

Back to top