Staffing a Cloud and DevOps Surge Without Wrecking Your Team

The migration date is on a slide finance has already seen. The old platform goes dark and the new one has to take the traffic. Your platform team is on the pager while they build the replacement. In the steering meeting a director says, "Just bring in five contractors."

Five fits on a slide. It's a bad plan. Nobody has named the workstreams or an owner. We've watched that produce contractors who can't log in and can't say what done means.

When the surge hire fails

What we see starts at arrival. Laptop in a queue, cloud role still with security, repo locked because the approver is in the cutover meetings. Nobody owns what "finished" means before the date. The date stays put.

The req fails beside it. "Senior AWS" or "Azure DevOps," and then it stops. You need the landing zone up, with pipelines that change alongside it. Security still has to sign the network path. Hire the logo and you get a clean interview that misses the work. Put the work in the req, as we laid out in How to Write an IT Job Requisition That Actually Attracts People.

All seniors, and the time disappears into design debate while modules sit open. All juniors, and it stalls when your accounts don't match the cert-course diagram. Put cutover scar tissue in the room with people who will close the dull tickets.

Incumbents who feel replaced stop explaining. The scheduled job that never reached Git. The identity exception a partner still needs. You can't staff past that silence.

Staff the work, then the seats

Size the surge to the work, not to a headcount that sounded decisive. Staff the streams in front of you.

Platform and infrastructure-as-code is what the migration hangs from: modules and remote state for the landing zone. CI/CD is where contract DevOps engineers for a migration either move the date or sit through status. That is the promotion path, secrets included, on the pipeline that breaks when another team adds a service.

Cloud networking arrives with a security review. Surge staffing for AWS or Azure falls apart on a logo resume. Name the cloud and the task: a landing-zone rebuild, or a network change security is already pushing back on. If you run both clouds, say which one this surge is for. A slipped date won't get the security review waived.

SRE and observability is the person who can call the new platform healthy and can refuse. You want that judgment from someone who has carried a pager on a bad deploy. Next to them, a hands-on lead who reads the Terraform and can name the internal person blocking the work.

That spread is DevOps staff augmentation. You hire cloud engineers on contract for those streams, on the cloud you run. Two pipeline people and one network engineer can be right, or the reverse when the network is the risk.

Sequence the starts or you pay people to wait. No account, or no environment, and those engineers sit. We made the same sequencing point in building a data and AI team.

Hands under your tech lead is staff augmentation. A firm that owns the migration as its project is outsourcing. Blend them and the date still slips. Staff Augmentation or Project Outsourcing? A Decision Framework is the split.

Pair them with your own people

Name one internal owner per contractor. They review the pull requests and they will tell you if the person is helping. "The platform team" can't do that.

The owner doesn't have to write the line. They do have to review identity changes and anything aimed at production. Skip it and you inherit a directory nobody on staff will open.

Give contractors the module moves and the pipeline cleanup, and have them cover the cutover window. Keep an incumbent on the design of the platform they'll run after the contractors leave. Seniors left with only the legacy pager stop sharing.

Before the new people start, say what ends at the date and what stays with your team. If a strong contractor can convert, say so. Silence sounds like a replacement plan.

A 30/60/90 that starts before anyone logs in

Day one ready means access exists before the start date. Laptop imaged, SSO working, repos open, cloud accounts and roles provisioned. A note on which environments they may change, plus the channel and the queue the team actually uses. Leave it until they arrive and the surge starts as waiting.

Treat 30/60/90 as outputs for this program.

First 30. One merge the owner has reviewed. A landing-zone module or a pipeline fix that held in the next environment. Written scope for the rest, including what they won't touch.

By 60. Their stream is moving under their names. Runbooks are started. Each blocker has an internal name on it. Your side has disagreed with a design, which means the review is real.

By 90. The stream is done, or your team can run it without them. ADRs hold the decisions. A recorded walkthrough covers what the repo leaves out. You know who you might ask to stay.

On a network cutover, use the middle mark for a signed design and a booked window, and put the flip after the 90.

Make the knowledge stay

A runbook left for the end doesn't get written.

Write them while the work is open, for anything they operated. ADRs too: why the accounts are split this way, and why one system stayed. Note the identity risk you accepted and the constraint you refused. Record a walkthrough your own engineer can follow alone.

Flip who shadows whom. Early, your people show the contractors how this place behaves. For the last few weeks, contractors shadow the incumbents rather than the other way around. Your engineer runs the change. The contractor answers. If your engineer can't run it, nothing was handed off.

Some should stay. Contract-to-hire keeps the person who already knows the landing zone, once you've seen the work. See Contract, Contract-to-Hire, or Direct Hire? How to Pick the Right Model.

How OKAYA helps

OKAYA has spent about 20 years staffing IT roles for US employers. We search an ATS of 2.5M+ profiles for cloud and DevOps contractors once a scope is written down.

Write the workstreams on one page before anyone approves a req. If you want that page staffed, start with talent acquisition or contact us.