Hire cloud computing specialists for the work you actually need done

Start with the estate, not the target

Before any specialist can help, someone has to know what exists. An inventory of workloads, owners, dependencies and current spend is the most valuable document you can bring to a first call. It does not need to be polished. A spreadsheet with the main systems, who owns each one and what talks to what is enough to have a useful conversation. The temptation is to open with a target architecture.

That usually produces a proposal for a rebuild, because the specialist can only design against what they can see. If the inventory is missing, part of the engagement becomes discovery, which is legitimate work but should be scoped as such rather than hidden inside a migration estimate.

Spend belongs in the same document. Current cost per workload, even roughly, changes which options are worth discussing. A specialist who sees the numbers can tell you whether the problem is architecture, sizing or simple waste, and those three have very different fixes.

The brief that gets a useful shortlist

A brief that produces a good shortlist has four parts. The environment, meaning which provider and what runs there. The outcome, meaning what should be true when the work ends.

The constraint, meaning the date, the budget band or the team capacity that cannot move. And the boundary, meaning what the specialist is not being asked to touch. The boundary matters more than people expect. Cloud work attracts scope growth because everything is connected.

If the brief says the application code is out of scope, the specialist can still flag what they find without being responsible for rewriting it. That keeps the engagement honest on both sides. Write the closing deliverable too.

If your team must be able to run the environment unaided, say so, because that changes how the work is sequenced and documented. If ongoing cover is expected, say that as well, since it is a different engagement shape. Finally, name the person on your side who can make decisions. A specialist blocked on approvals loses more time than one blocked on technical problems.

Migration and modernisation are different projects

Moving a workload to the cloud and rewriting it to use managed services are separate pieces of work with separate risks. Combining them without a plan is where timelines slip. A migration keeps behaviour the same and changes the hosting.

A modernisation changes behaviour and should be judged on whether it reduces operational load. If both are needed, sequence them deliberately. Migrate first where the workload is stable, then modernise with a working baseline to compare against. Doing both at once removes the reference point that tells you whether the new design is actually better.

The brief should name which of the two it is asking for. Ambiguity here is common, and it usually surfaces late, when a migration estimate quietly turns into a rewrite. A specialist who is told the difference will price and plan accordingly, and will say plainly if the workload is a poor candidate for either. The brief should also name who decides, what must be true before a shortlist, and what would make you stop.

What to ask before you sign

Ask what the specialist will produce and who reads it. Documentation written for an auditor is not the same as documentation written for the engineer who is on call next month.

Ask how progress will be reviewed and how often. Weekly written updates are more useful than a status call, because they leave a record. Ask what happens if the work runs past the estimate.

A specialist who has done this before will have a view on the most likely cause of slippage in your environment, and naming it early is a good sign rather than a bad one. Ask about access. Who gets what permission, for how long, and how it is removed at the end.

This is a security question and a practical one, since lingering access is a common loose end after an engagement closes. Ask for the rollback plan, particularly for migrations. A cutover without a tested reversal is a hope rather than a plan.

Cost, security and the questions buyers forget

Cloud spend is decided mostly in architecture. A cost review after the build can trim, but it cannot redesign. If cost is a concern, raise it before the design is fixed, and ask the specialist to explain what the workload actually needs rather than what is available.

Security is largely an access question. Identity and permissions decide most of your exposure, and they are set while the architecture is drawn. A separate review afterwards is still worth doing as an independent check, but it works better as confirmation than as rescue.

Buyers often forget to ask about the team left behind. Who on your side will operate this, and do they have the time and the skills. If the answer is unclear, the handover needs to include training, not just documents.

Another common gap is the exit. Ask what happens when the engagement ends, what access is removed and what remains open. A clean exit is part of the deliverable, not an afterthought.

Choosing between hourly, part-time and dedicated

Hourly suits a review, an audit or a second opinion on a design. The work has a defined end and the output is a document or a conversation.

It is a poor fit for anything that requires sustained context, because the specialist spends the first hour relearning the environment. Part-time suits a defined build alongside your team. The specialist has enough continuity to hold the design in their head while your engineers keep operating the rest.

It works when your team has capacity but not the specific depth. Dedicated suits a longer programme where the work is continuous and the decisions compound.

It costs more in total but less per unit of progress, because context is never rebuilt. Match the shape to the work rather than to the budget alone. A migration squeezed into hourly slots usually takes longer overall than the same work done in a defined block, because the cutover cannot be paused halfway.

Conclusion

A cloud engagement goes well when the brief is specific and the exit is planned from the start. Name the environment, the outcome, the constraint and the boundary. Agree what your team will be able to do unaided, and make that the closing deliverable. Everything else, including which specialist you need, follows from those four lines.