Overview
Cloud migration is the process of moving applications, data, and infrastructure from on-premises data centers (or other cloud providers) to cloud platforms like AWS, Azure, or GCP. This isn't just a technical exercise—it's an organizational transformation that affects how engineers work, how applications are deployed, and how infrastructure is managed.
Hiring for cloud migration requires finding engineers who understand both legacy systems and cloud-native approaches. The best candidates have migrated systems before and know the pitfalls: applications that assume local disk access, network architectures that don't translate to cloud, and operations teams unfamiliar with cloud tooling.
The migration itself is temporary, but the skills you build become permanent capabilities. Smart organizations hire for the long-term cloud operations need, not just the migration project. The engineers who migrate your systems should be the ones who operate them afterward—this ensures knowledge transfer and accountability.
What Success Looks Like
Before you start hiring, define what success means for your cloud migration. Vague goals like "move to the cloud" lead to scope creep, budget overruns, and frustrated engineers. Be specific about outcomes.
Measurable Success Indicators
Migration Completion
- All target workloads running in cloud environment
- Legacy infrastructure decommissioned on schedule
- Data migrated with zero loss and validated integrity
- Applications performing at or better than pre-migration baseline
Operational Excellence
- Infrastructure managed as code (Terraform, Pulumi, CloudFormation)
- Automated deployment pipelines for all migrated applications
- Monitoring and alerting coverage for cloud resources
- Disaster recovery and backup procedures documented and tested
Cost Management
- Cloud spend within 15% of projected budget
- Resource utilization optimized (no idle instances)
- Reserved capacity purchased for predictable workloads
- Cost allocation tags enabling departmental chargeback
Team Capability
- Engineering team can deploy and manage cloud resources independently
- Runbooks exist for common operational tasks
- On-call rotation established for cloud infrastructure
- Security and compliance requirements met
Warning Signs During Migration
| Warning Sign | What It Indicates | Immediate Action |
|---|---|---|
| Costs exceeding projections by 30%+ | Architecture issues, rightsizing needed | Cloud cost audit, architect review |
| Multiple failed migration attempts | Inadequate planning, missing dependencies | Pause and reassess approach |
| Engineers avoiding cloud work | Skills gap, inadequate training | Training program, paired work |
| Post-migration performance issues | Lift-and-shift without optimization | Performance profiling, refactoring |
| Security incidents increasing | Misconfigured resources, IAM issues | Security audit, policy review |
| Migration timeline slipping monthly | Scope creep, underestimated complexity | Re-scope, add resources, or extend timeline |
Roles You'll Need
Phase-by-Phase Hiring
Phase 1: Planning and Architecture (Months 1-3)
| Role | Count | Focus | When to Hire |
|---|---|---|---|
| Cloud Architect | 1 | Strategy, architecture design, migration planning | Before migration starts |
| Security Engineer | 1 | Cloud security architecture, compliance | Before migration starts |
Phase 2: Foundation and First Workloads (Months 3-9)
| Role | Count | Focus | When to Hire |
|---|---|---|---|
| Platform/DevOps Engineers | 2-3 | Infrastructure as code, CI/CD, core services | Month 2-3 |
| Cloud Engineers | 2-4 | Workload migration, application adaptation | Month 3-4 |
| Site Reliability Engineer | 1 | Monitoring, observability, reliability | Month 4-5 |
Phase 3: Scale Migration (Months 6-18)
| Role | Count | Focus | When to Hire |
|---|---|---|---|
| Additional Cloud Engineers | 2-4 | Parallel workload migrations | As needed |
| Database Administrator | 1 | Database migrations, data integrity | Month 6-8 |
| Network Engineer | 1 (optional) | Complex networking, hybrid connectivity | If needed |
Phase 4: Optimization and Steady State (Months 12+)
| Role | Count | Focus | When to Hire |
|---|---|---|---|
| FinOps Specialist | 1 (optional) | Cost optimization, reserved capacity | After migration |
| Platform Engineers | Retain 2-3 | Ongoing operations, improvements | Transition from migration |
Key Role Deep Dives
Cloud Architect (Critical First Hire)
This is your most important hire. A good cloud architect prevents costly mistakes, while a poor one creates technical debt that takes years to resolve.
What they do:
- Design target architecture (landing zones, networking, security)
- Define migration strategy for each workload type
- Establish patterns and standards for cloud usage
- Guide build vs. buy decisions
- Create migration runbooks and documentation
What to look for:
- Has architected migrations before (not just operated in cloud)
- Deep expertise in your target cloud platform
- Understands legacy systems, not just cloud-native
- Strong communication—will need to align stakeholders
- Pragmatic—chooses "good enough" over "perfect"
Red flags:
- Only knows one cloud platform (vendor lock-in risk)
- Wants to redesign everything (scope creep)
- Can't explain tradeoffs simply (communication issue)
- No migration experience (theory vs. practice)
Platform/DevOps Engineers (Execution Core)
These engineers build the foundation that all migrated applications run on. Their work determines long-term operational efficiency.
What they do:
- Implement infrastructure as code
- Build CI/CD pipelines for cloud deployments
- Configure networking, security groups, IAM
- Create monitoring and alerting infrastructure
- Automate repetitive migration tasks
What to look for:
- Strong Terraform, Pulumi, or CloudFormation skills
- Experience with containerization (Docker, Kubernetes)
- CI/CD pipeline design and implementation
- Security-conscious approach to infrastructure
- Automation mindset
Cloud/Migration Engineers (Workload Movers)
These engineers handle the actual migration work—moving applications, adapting code, and ensuring things work in the new environment.
What they do:
- Assess applications for migration readiness
- Execute lift-and-shift or refactoring as planned
- Resolve migration issues and blockers
- Validate application behavior post-migration
- Update documentation and runbooks
What to look for:
- Experience with your application technology stack
- Has migrated similar applications before
- Debugging skills for distributed systems
- Patience for tedious migration work
- Good documentation habits
Migration Strategy Options
Understanding migration strategies helps you hire the right mix of skills. Different strategies require different expertise.
The 6 Rs of Cloud Migration
| Strategy | Description | Skill Focus | Best For |
|---|---|---|---|
| Rehost (Lift and Shift) | Move as-is with minimal changes | Infrastructure, operations | Simple apps, quick wins |
| Replatform (Lift, Tinker, Shift) | Minor optimizations during move | Platform, some development | Apps needing cloud services |
| Repurchase | Replace with SaaS alternative | Vendor evaluation, integration | Commodity software |
| Refactor/Rearchitect | Redesign for cloud-native | Application development | Strategic applications |
| Retire | Decommission obsolete apps | Assessment, data archival | Legacy systems with no value |
| Retain | Keep on-premises intentionally | Hybrid architecture | Regulatory, latency needs |
Hiring Implications by Strategy
Lift and Shift Heavy
- Emphasize infrastructure and operations skills
- Need engineers comfortable with legacy systems
- Less application development expertise required
- Faster migration, less transformation
- Hiring profile: DevOps engineers, platform engineers, DBAs
Refactoring Heavy
- Need strong application development skills
- Cloud-native architecture expertise critical
- Longer timeline, more development work
- Hiring profile: Cloud architects, software engineers, platform engineers
Hybrid Approach (Most Common)
- Mix of infrastructure and development skills
- Flexible team that can handle varied work
- Requires good prioritization and architecture guidance
- Hiring profile: Balanced team with architect leadership
Platform-Specific Considerations
AWS Migration
- Largest ecosystem, most tools and services
- Strong candidate pool (most cloud engineers know AWS)
- AWS certifications indicate baseline knowledge
- Key skills: EC2, RDS, S3, VPC, IAM, CloudFormation/CDK
Azure Migration
- Strong enterprise integration (AD, Office 365)
- Good for Microsoft-heavy environments
- Smaller candidate pool than AWS
- Key skills: Azure AD, Virtual Machines, Azure SQL, ARM templates
GCP Migration
- Strong for data/ML workloads, Kubernetes
- Smallest candidate pool
- Often paired with BigQuery, GKE expertise
- Key skills: Compute Engine, Cloud SQL, GKE, Cloud Functions
Build vs. Buy: MSPs vs. In-House
One of the biggest decisions in cloud migration hiring is whether to build an in-house team, use Managed Service Providers (MSPs), or a hybrid approach.
Option 1: In-House Team
Pros:
- Deep organizational knowledge and context
- Long-term capability building
- No dependency on external parties
- Lower ongoing cost after migration
- Full control over priorities and approach
Cons:
- Longer ramp time (hiring + onboarding)
- May lack migration-specific expertise
- Harder to scale up/down with project phases
- Risk if key people leave during migration
- Full cost of benefits, training, management
Best for:
- Organizations with existing cloud skills
- Migrations with 18+ month timelines
- Strategic cloud commitment (not one-off)
- Companies wanting to build internal capability
Option 2: MSP/Consulting Partners
Pros:
- Immediate expertise availability
- Migration-specific experience and patterns
- Can scale quickly for project phases
- Risk shared with partner
- Brings cross-industry best practices
Cons:
- Expensive (often 2-3x internal cost)
- Knowledge walks out when engagement ends
- Less organizational context
- Potential misaligned incentives
- Dependency on external party
Best for:
- Aggressive timelines (under 12 months)
- Organizations without cloud expertise
- One-time migrations without ongoing cloud growth
- Complex, high-risk migrations
Option 3: Hybrid Approach (Recommended for Most)
Model:
- Use MSP for architecture, planning, and initial execution
- Hire internal team in parallel, embedded with MSP
- MSP hands off to internal team as migration progresses
- Internal team owns ongoing operations
Pros:
- Fast start with expertise
- Knowledge transfer built into engagement
- Internal team learns from experienced practitioners
- Flexibility to scale external resources as needed
- Builds long-term capability while executing
Implementation:
- Engage MSP for architecture and first 2-3 workloads
- Hire cloud architect and platform engineers months 2-4
- Internal engineers shadow MSP, gradually take ownership
- MSP transitions to advisory role by month 9-12
- Internal team owns steady-state operations
Cost Comparison (50-workload migration)
| Approach | Year 1 Cost | Year 2 Cost | 3-Year Total | Risk |
|---|---|---|---|---|
| Fully In-House | $1.2-1.8M | $800K-1.2M | $2.8-4.2M | Longer ramp |
| Fully MSP | $2-3M | $1.5-2M | $5-7M | Knowledge loss |
| Hybrid | $1.8-2.5M | $800K-1.2M | $3.4-4.9M | Balanced |
Common Pitfalls
1. Underestimating Migration Complexity
The mistake: You assume migration is mostly infrastructure work and understaff the application-side expertise.
What happens: Lift-and-shift migrations reveal application assumptions (local disk, specific network topology, hardcoded configurations) that require development work to resolve. Timeline slips as you scramble for development resources.
Prevention:
- Assess applications before hiring—understand the work
- Include application developers in migration teams
- Plan for 30%+ contingency time for unexpected issues
- Don't assume "simple" applications are actually simple
2. Hiring Only for Migration, Not Operations
The mistake: You staff up for migration with contractors or temporary hires, then scramble for operations staff when migration ends.
What happens: Knowledge walks out with departing contractors. The team that migrated isn't the team that operates, creating accountability gaps and lost context.
Prevention:
- Hire permanent staff from the beginning
- Ensure migration engineers transition to operations
- If using MSP, mandate knowledge transfer milestones
- Plan operations team structure before migration ends
3. Ignoring Security Until Late
The mistake: Security is treated as a post-migration concern or checkbox exercise.
What happens: You discover compliance issues late, requiring expensive rework. Misconfigured resources create vulnerabilities. Cloud security tools are bolted on rather than designed in.
Prevention:
- Hire security expertise early (Phase 1)
- Include security review in migration processes
- Design IAM and network security from the start
- Automate security scanning in CI/CD pipelines
4. One Cloud Platform Expert Only
The mistake: You hire engineers who only know your target platform, without broader cloud experience.
What happens: Decisions become platform-biased rather than problem-focused. Multi-cloud flexibility is lost. Engineers struggle when platform-specific solutions don't fit.
Prevention:
- Value multi-cloud experience in architects
- Look for engineers who understand concepts, not just one vendor
- Ensure the team can evaluate alternatives objectively
- Avoid vendor lock-in by design
5. Treating Migration as Purely Technical
The mistake: You focus only on technical migration, ignoring organizational change management.
What happens: Developers resist cloud adoption. Operations teams feel threatened. Finance doesn't understand cloud cost models. Migration succeeds technically but fails organizationally.
Prevention:
- Invest in developer training and enablement
- Communicate cloud benefits and changes clearly
- Involve operations early, don't replace them
- Prepare finance for cloud billing models
6. No Clear Migration Ownership
The mistake: Migration is a "shared responsibility" without clear ownership and accountability.
What happens: Decisions stall because nobody can decide. Problems get passed between teams. Timeline slips as coordination overhead grows.
Prevention:
- Assign a single migration lead with authority
- Define clear responsibilities for each team
- Create escalation paths for blockers
- Regular status meetings with decision-making power
7. Scope Creep: Refactoring Everything
The mistake: The team decides to "do it right" and refactor applications during migration.
What happens: What should be a 12-month migration becomes an 18-month modernization project. Budgets and timelines blow up. Original business value is delayed.
Prevention:
- Strict migration scope—move first, optimize later
- Separate migration from modernization projects
- Resist the urge to "fix it while we're here"
- Time-box any in-migration improvements
Timeline: Typical Enterprise Migration
Months 1-3: Planning and Architecture
- Hire cloud architect and security engineer
- Complete application discovery and assessment
- Design target architecture and migration strategy
- Build business case with cost projections
- Begin platform engineer hiring
Months 3-6: Foundation
- Build landing zones and core infrastructure
- Implement CI/CD pipelines
- Establish monitoring and security baseline
- Migrate first 2-3 low-risk workloads
- Complete platform team hiring
Months 6-12: Scale Migration
- Migrate production workloads in waves
- Address issues and refine processes
- Build operational runbooks
- Begin decommissioning legacy infrastructure
- Optional: hire additional migration engineers for parallel work
Months 12-18: Complete and Optimize
- Migrate remaining workloads
- Complete legacy decommissioning
- Optimize cloud costs and performance
- Transition to steady-state operations
- Reduce team size to operational level
Months 18+: Steady State
- Ongoing operations and improvements
- Cost optimization and rightsizing
- Support new development on cloud platform
- Continuous security and compliance