Cloud migration project plans are typically built around infrastructure — which services migrate to which cloud provider, in what order, on what timeline. They budget for consultants, licensing, and tooling. What they rarely budget for, or even explicitly identify, is the skill state of the engineering team that has to execute the plan.
This is a strange omission given that team skill gaps are among the most commonly cited reasons for cloud migration delays. A Gartner analysis from a few years ago found that through 2025, more than 90% of cloud failures would be the customer's fault — and the category breakdown consistently shows skills and process gaps outranking infrastructure choices as the primary culprit. The post-mortems identify it; the project plans don't pre-empt it.
This post is about what a pre-migration skill map looks like and why it should be a standard artifact alongside the architecture diagram and the migration runbook.
What "Cloud Skills" Actually Means (And Why It's Not One Thing)
The phrase "cloud skills" is too vague to be useful for workforce planning. A cloud migration touches at least six distinct capability domains, and the skill gap profile varies significantly across them:
Infrastructure as Code (IaC) authoring. Engineers who have spent their careers managing infrastructure through GUI-based tools or traditional shell scripts need to think differently about state management when Terraform or Pulumi enters the picture. The IaC mental model — declarative rather than imperative, state files as the source of truth — is non-trivial to internalize even for experienced engineers. Proficiency is binary in many cases: either an engineer can write and debug a non-trivial Terraform module, or they can't yet.
Container orchestration. Kubernetes is the de facto standard for containerized workload management in production cloud environments, but the gap between "understands what a pod is" and "can design and operate a multi-cluster environment with proper resource quotas, network policies, and GitOps workflows" is large. For a migration that involves refactoring monolithic applications into microservices, the orchestration skill gap is often the longest path on the critical timeline.
Cloud-native data services. Managed databases, object storage, streaming services, and data warehouse products work differently from on-premise equivalents in ways that affect schema design, access patterns, cost optimization, and failure handling. Engineers who know PostgreSQL deeply may have real gaps in designing for DynamoDB or BigQuery — and those gaps surface in production, not in planning.
Security and IAM configuration. Cloud identity and access management is a specialized domain that most development engineers don't own in on-premise environments. In cloud, every service communicates via IAM roles and policies. Misconfiguration is both common and consequential. A migration that doesn't include explicit security skill coverage risks producing a working system with a non-compliant security posture — which then requires expensive remediation post-launch.
Cost observability and optimization. Cloud bills are variable in a way that on-premise costs are not. Engineers who have never operated in a consumption-billing environment consistently underprice architectures in ways that show up as budget overruns at scale. Understanding cost allocation tags, reserved instance strategy, and rightsizing practices is a skill set distinct from architectural competence.
CI/CD and deployment automation. Modern cloud deployments are expected to run through automated pipelines with infrastructure testing, security scanning, and rollback automation. Engineers who are accustomed to deploying via manual processes or simple scripts need to reskill on pipeline tooling, testing strategy, and deployment pattern concepts (blue-green, canary, etc.) before they can be productive contributors to a modern cloud environment.
Building the Skill Map: A Pre-Migration Exercise
The pre-migration skill map is a table with two axes: the capability domains required by the migration, and the engineers on the team. For each cell, you need a current proficiency estimate and a target proficiency for the role the engineer will play in the migration.
The proficiency scale doesn't need to be elaborate — a 1–4 scale with defined behavioral anchors works well. Level 1: awareness (can describe what the technology does). Level 2: guided use (can use with documentation and occasional help). Level 3: independent use (can work productively without guidance). Level 4: can lead others and design for scale.
For a standard migration, the minimum viable skill map covers:
- Which engineers are on the migration team
- Their current proficiency level in each of the six domains above (assessed, not assumed)
- The minimum proficiency required for their specific role in the migration
- The gap (target minus current) for each person-domain pair
- Whether the gap is closable within the migration timeline through training, or whether it requires an external hire or contractor
The last point is the critical output. A gap of 1–2 levels in a domain that's adjacent to existing skills is typically closable in 4–8 weeks with focused learning and project application. A gap of 3 levels in a domain with no adjacency (a data engineer who needs to become an IAM security specialist by next quarter) is not closable in that timeframe — and recognizing that early prevents the project from allocating that responsibility to someone who can't execute it.
A Concrete Case: 280-Person Healthcare Technology Company
A growing healthcare technology company had committed to migrating their core patient data platform from co-located data centers to AWS within 18 months. The engineering team had 22 backend and infrastructure engineers. The migration architecture required deep competency in six AWS-specific services: ECS (for container orchestration), RDS Multi-AZ with read replicas, S3 with lifecycle policies, SQS/SNS for event-driven patterns, Secrets Manager for credential rotation, and CloudFormation for IaC.
Before mapping, project leadership assumed the team was "mostly ready — they're experienced engineers." After a structured proficiency assessment against those six service areas, the actual picture was different: 14 engineers had genuine proficiency (level 3+) in ECS and S3. Only 3 had working-level familiarity with Secrets Manager. Nobody had production experience with CloudFormation at the complexity the migration required. One engineer had done significant CloudFormation work at a previous job — he became the IaC lead and ran an internal workshop for the eight engineers who needed level-2 CloudFormation proficiency to participate.
The mapping also surfaced a hard constraint: the security and IAM scope of the migration — which touched HIPAA-relevant data flows — required a compliance-aware cloud security skill set that nobody on the team had. That gap was not closable in 18 months through internal reskilling for someone starting at level 1. They hired a specialized contractor for a 6-month engagement to own IAM design and document the patterns the team could then maintain themselves.
Without the skill map, that security gap would have been discovered 12 months in when audit findings came back from compliance review — a much more expensive correction.
Where the Skill Map Connects to Reskilling Path Assignment
The pre-migration skill map isn't just a diagnostic. It's the input for targeted path assignment. Once you know which engineers have which gaps, you can route each person to a learning path that's appropriately leveled for their starting point — not a generic "AWS certification" program that puts the level-2 engineer through material they already know while the level-1 engineer drowns in concepts they have no context for.
This is where skill adjacency matters practically. The engineer who knows Linux systems administration deeply will pick up Kubernetes pod scheduling faster than the engineer whose background is purely application development — their mental models for process management and networking overlap meaningfully. Assigning them the same Kubernetes learning path produces different outcomes. The systems engineer probably needs the advanced track. The application developer needs the foundational track and more hands-on lab time before the intermediate concepts make sense.
We're not claiming that every organization needs a full workforce analytics platform to build this map. For a migration team of 20–25 engineers, a structured spreadsheet assessment process takes one or two days to run and produces genuinely actionable output. The value of tooling is when you're doing this across hundreds of engineers across multiple concurrent migrations — the manual approach doesn't scale, the pattern-matching across skill profiles becomes non-trivial, and the path routing logic benefits from something more systematic than a spreadsheet lookup.
What a Skill Map Does Not Solve
To be clear about scope: the pre-migration skill map addresses the capability gap problem. It does not address organizational design problems (who owns cloud architecture decisions), process maturity problems (whether the team has the discipline to enforce IaC standards consistently), or culture problems (whether senior engineers will block knowledge transfer to junior team members to protect their positions).
These non-skill factors also derail cloud migrations, and they're worth naming because they can masquerade as skill problems in post-mortems. If the team has the technical skills but is operating in a culture where knowledge silos are protected, training more engineers won't fix the delivery problem. But that's a different diagnostic conversation — one that the skill map helps distinguish from the capability gap problem by showing where skills actually exist and where they don't.
The practical implication: run the skill map before the migration plan is finalized. The gaps you find should directly influence the project timeline, team composition, and reskilling investment budget. Finding them after the project kicks off means you're managing them as risks instead of resolving them as preconditions — which is more expensive, more stressful, and more likely to produce the migration delays and cost overruns that end up attributed to "execution problems" rather than the planning gap they actually were.
