Cloud Migration Project Staffing for Moves That Already Have a Date
Almost nobody chooses when their migration happens. A lease ends, a renewal quote lands, a version goes out of support. We staff the move as a team with a scope and an end date, because that is the shape the work actually has.
KORE1 staffs cloud migrations as scoped project teams with an end date, not as permanent requisitions, because most migrations are forced by a lease, a renewal quote or an end-of-support date somebody else set. 92% of the engineers we place are still in seat a year later.
Last updated: September 1, 2026
The Requisition Is the Wrong Tool for a Move
A migration has a beginning, a middle and a hard right edge. A headcount req has none of those. It has a title, a band and an assumption that the work continues forever, which is why so many migrations get staffed six months late and then leave three people with nothing obvious to do in month fourteen.
We see the same sequence often enough to set a watch by it. Finance approves two permanent roles against a move that needs seven people for five months. Recruiting starts. The band is set for steady-state platform work rather than for someone who has done four cutovers, so the offers land soft, the good candidates take something else, and by the time two seats are filled the wave plan has slipped a quarter. Nobody did anything wrong. The instrument was wrong.
Buying it as project staffing inverts that. Scope first. You define the scope and the end date first, then we assemble against it, and the team is sized for the peak instead of for the leftovers. Same recruiters, same network. Different contract shape.
Pick the Shape Before You Pick the People
Most migration conversations start with roles. Ours starts one step earlier. The answer to “how do we buy this” changes who we call and what we can honestly promise on timing.
Project team
Several people at once against a defined wave plan. Right when the move is bigger than your platform team can absorb. The date is not yours to move.
Project staffing →Contract
One or two specialists beside your own engineers. Good for a single skill gap, and good for covering a seat while the permanent req is still budget-blocked.
Contract staffing →Direct hire
For what the migration leaves behind. Somebody runs the landing zone in year two, and that is a different person from the one who lands the workloads. Usually very different.
Direct hire staffing →A fair number of clients use two of these on the same programme. Contract for the specialist nobody else has, project for the wave team, then one direct hire at the end to own what shipped. Hiring for the steady state instead? Start with cloud engineer staffing or cloud infrastructure staffing.
Four Migrations. Four Clocks Somebody Else Started.
Migrations rarely begin because a strategy deck said so. They begin because an external date landed on somebody’s desk. Which date you are working against tells us more about the team you need than any target platform does, so it is the first thing we ask about.
Data center exit
Hardest of the four. Everything has to leave, and that includes the dozen applications with no named owner, the reporting box a finance analyst stood up in 2014, and the appliance whose vendor stopped existing in 2019, none of which appear anywhere in the CMDB. Discovery is the job. Skip it and the surprise lands in wave four, by which point the date has stopped being negotiable and the only lever left is money.
Migration lead · Discovery and dependency mapping · Network engineer · Storage and backup · App owners liaison
VMware and Broadcom escape
Since the licensing model changed this has quietly become the single most common reason clients ring us about a move. Renewal lands. The number is a multiple of last year’s, and a roadmap item nobody was going to touch until 2029 turns into a nine-month programme with a board sponsor. Some of it goes to public cloud. Plenty goes to a different hypervisor, and a surprising amount goes back to bare metal for the workloads that never needed virtualizing in the first place.
Virtualization engineer · Cloud architect · Automation and IaC · Licensing and cost analyst
End-of-life forced modernization
Windows Server 2016 leaves extended support on January 12, 2027. Plenty of estates still run hundreds of instances on it, because a deadline published four years out is a deadline that gets deferred four times. Then the cyber insurance renewal asks the question. Or an auditor does. Two quarters left, and now it is a programme.
Systems administrator · Windows and Linux platform engineers · Database migration · Application remediation
Carve-out and separation
A transition services agreement buys the separated business a fixed window on the parent’s systems. The day it ends, access ends. There is rarely a goodwill extension, and every month of overrun tends to carry a fee that somebody in finance is already tracking on a slide. Least forgiving clock of the four. Also the one where a scoped team with a named end date fits the work almost exactly, which is why we see so many of them.
Separation programme lead · Identity and directory · Data extraction · ERP and business systems
Tell us which of those four you are in and we can usually describe the team on the first call. Get it wrong and you buy the wrong people. A carve-out staffed like a lift-and-shift is short an identity engineer, and that surfaces in week six. Too late to be cheap.
Deeper on the individual seats. Cloud architect staffing, network engineer staffing, systems administrator staffing, DevOps engineer staffing and Kubernetes engineer staffing. Leaving a facility rather than a platform? Our data center staffing desk covers the hands on the floor.
We Ask About the Cutover That Got Rolled Back
Plenty of engineers have worked on a migration. Far fewer have owned a window. Both write the same bullet.
So our recruiters pick one move and walk the whole thing. What was in wave one and why, who signed off the go decision, what the rollback criteria actually said, and whether anybody ever had to use them. Someone who stood in that room at two in the morning answers in specifics inside a minute, usually with a slightly bitter aside about a firewall rule or a DNS TTL nobody had checked. The engineer who watched from a distance gives you a clean process summary instead. The difference is audible.
We have been on technology desks since 2005 and our recruiters average 15 years each, which mostly means the first calls go to people we already know rather than to a job board. A fair number we have placed before. On a migration that beats any certification, because what you are buying is judgment under a deadline. Certificates do not panic well.
Three Things That Stall a Migration, None of Them Cloud Skill
Programmes rarely run late because nobody could configure the target. It is one of these three.
Nobody owns the inventory
The CMDB is four years stale. The real dependency map lives in two people’s heads, and one of them is contracting elsewhere now. Budget discovery as work.
The wave plan has no owner
Deciding what moves together, and in what order, is a full role. Not a side duty. Left to a committee it yields a plan that satisfies everyone and survives contact with nothing.
Change control was never scoped
In a regulated estate the paperwork around a cutover routinely takes longer than the cutover. Staff for it and you finish. Do not, and the last month is spent waiting on signatures.
Workload categories and the standard rehost, replatform and refactor framing come from AWS migration guidance, and phase structure from the Microsoft Cloud Adoption Framework. Demand and outlook data for the underlying roles comes from the U.S. Bureau of Labor Statistics for computer network architects.
How We Build a Migration Team
We find the date and who set it
Thirty minutes on the forcing event, the estate, and what has to be true on the last day. Sometimes the date is softer than it looks. We will say so, and the team we propose gets smaller.
We size for the peak, not the average
Migrations are lumpy. Discovery is light, the middle waves are heavy, and the tail needs two people rather than nine. We map roles onto that curve, so you are not paying for a flat team through a curve-shaped programme. It saves real money.
We settle constraints before sourcing
Overnight windows, on-site days, background checks, and whether the rate survives contact with the market. Ask early. Finding any of those in week three turns a six-week build into a five-month one.
We screen on a move that shipped
One real programme, walked end to end, including the wave that went badly. You get a shortlist with technical notes attached. Normally two to three weeks for the first seats.
Running the programme rather than staffing it? An IT project manager is often the first seat we fill. If the move is really an application and data problem, look at ERP data migration staffing or business systems consolidation instead, and if security sign-off is the constraint, our cloud security recruiters cover that side.
Common Questions
What is cloud migration staffing?
Cloud migration staffing means hiring a scoped team for the duration of a move rather than filling permanent roles. The team is sized against a wave plan and an end date, then stands down. Most of ours run four to nine months. That is the awkward length where a permanent req is too slow and one contractor is too small.
How is this different from just hiring cloud engineers?
Different instrument, different people. A cloud engineer hire is about who runs your platform for the next several years. A migration team is about who gets your workloads across a line by a date, and the strongest people at that are often not looking for a permanent seat at all. Some have run twenty cutovers. A quarter of steady-state work would bore them into resigning.
How fast can you stand up a migration team?
First shortlists usually land in two to three weeks, and a full team of five to eight typically staggers in over four to six. Lead roles go first because the wave plan depends on them. If your date is inside eight weeks, say so on the first call. We would rather propose a smaller team that starts Monday than a perfect one that starts in March.
We are leaving VMware because of the renewal cost. Do you staff that specifically?
Yes, and it is now the most common single driver we hear. Those programmes need virtualization depth and cloud fluency in the same room, which is rarer than it sounds, because the people who know vSphere properly often spent the last decade nowhere near a public cloud. So we pair. Hunting a unicorn costs you the date.
Can the same team run a hybrid or partial migration?
Most of what we staff is hybrid anyway. Part cloud, part colo, part on-premises refresh, and almost never the clean all-in picture the original business case described. What matters is that somebody owns the boundary between what moved and what did not, because that seam is where the incidents live for the next two years. So we make it a named role.
What does it cost compared to a permanent hire?
Hourly rates run above a salaried equivalent, and total cost is often lower, because you are paying for five months rather than forever. The comparison people forget is the slip. It dwarfs everything else. A quarter of delay on a data center exit can cost more in extended lease and dual-running than the entire team did. We will walk that arithmetic with you first. It takes ten minutes.
What should we have ready before the first call?
Four things. The forcing date and who set it, a rough count of what has to move, who owns the applications today, and whether change control is heavy or light. That is enough for us to sketch a team. If you only have two of the four, call anyway, because the missing two are usually the conversation worth having.
Tell us the date. We’ll tell you the team.
Give us half an hour on the forcing event and the estate. You leave with a sized team and a realistic build schedule whether or not you run it with us. Most people keep the sizing. Some come back a year later.
Scope a Migration Team →