Perspectives · Cloud & data engineering · 10 June 2026
What happens the day the consultants leave
A migration is measured a year after handover, by what is still running and who is able to run it. A specific set of artefacts separates a platform your team owns from one it merely hosts.
A cloud or data migration can look finished and still be a liability. The demo runs cleanly, the slides get signed off, the delivery team rolls off, and three months later the platform has not moved an inch. No one in-house can extend it, deployments have stopped because nobody trusts them, and the running costs are climbing for reasons the finance team cannot get answered. The build itself was rarely the problem. What was missing is everything that lets a system outlive the people who built it.
Having spent years on the delivery side of these engagements, including at AWS Professional Services, I know where that divide sits. The difference between the platforms that survive handover and the ones that quietly freeze is not talent, and it is rarely budget. It is a specific set of technical artefacts and disciplines, most of which cost little if they are built in from the first sprint and are nearly impossible to retrofit at the end.
“Done” is a technical definition
The first discipline is refusing the console. If a platform exists because someone clicked it into being, it exists exactly once, and the knowledge of how to recreate it lives in that person’s head. Everything we deliver is defined as infrastructure as code, in Terraform or CDK, with remote state, code review and a pipeline that is the only path to production. The test is blunt: the platform can be stood up in a fresh account from the repository alone, and a change reaches production through a pull request or it does not reach production at all.
Environments follow the same rule. Development, staging and production are promoted through the pipeline from the same definitions, not hand-cloned and left to drift. Idempotency, automated testing, rollback and cost controls are part of what “done” means, not enhancements scheduled for a phase two that never arrives. A platform you cannot deploy repeatably, watch in operation, or scale without alarm is not finished. It is fragile, and it grows more fragile the moment its builders move on.
The artefacts a real handover contains
When we leave, the client holds a specific inventory, and each item exists because its absence is a known failure mode.
Architecture decision records. A reference architecture lifted from a conference slide carries an air of authority and is usually wrong for the problem in front of you, because the original came with constraints and trade-offs that no longer apply. The real design is the set of decisions underneath the diagram: why this pattern, when it would not fit, and what was traded away to use it. We write those down as ADRs at the moment each decision is made. Two years later, they are the difference between an engineer extending the platform with confidence and an engineer afraid to touch it.
Runbooks bound to alarms. Every alarm that can page a human links to a runbook that states what the alarm means, how to confirm it, the remediation steps, and the escalation path with named roles. An alarm that pages a person’s memory is a dependency on that person; an alarm that pages a runbook is an operational capability. During handover we deliberately trigger the major failure modes and have the client team work the runbooks, then fix every step that turned out to be wrong or missing.
Dashboards that answer operator questions. Not vanity metrics: the four questions an operator actually asks. Is it up, is it fast, what is it costing, and what changed. If the answer to any of them requires a query someone has to remember, the dashboard is not done.
A documented access model. Who can do what, expressed in roles rather than individuals, with the joiner-mover-leaver process written down and a break-glass procedure that has been tested, because the first time you use emergency access should not be during an emergency.
Cost allocation from day one. Tagging standards enforced in the pipeline, budgets and anomaly alerts per environment and per workload, and cost attribution granular enough that the question “why did the bill go up” has an answer in minutes. Untagged infrastructure is unaccountable infrastructure, and it is always the part that grows.
Recovery that has been rehearsed. Recovery time and recovery point objectives are stated per workload, the backup and restore paths exist as code, and at least one game day has been run with the client team executing the recovery. A disaster-recovery plan that has never been exercised is a document, not a capability.
Certificates measure the wrong thing
Plenty of organisations track certification counts as a proxy for readiness, and it is a poor one. A certificate confirms that someone answered questions correctly on a particular day. It says nothing about whether they can read a messy requirement, choose an architecture under real constraints, or bring a pipeline back at two in the morning. I hold all thirteen AWS certifications and I will defend their value as a floor, but the workforce that accumulates badges without operating a real platform ends up calling the consultants back, which defeats the point of the exercise. The training we run is therefore built around the client’s own platform, mapped to the roles people actually fill, and assessed on whether they can do the work.
The acceptance test
All of it converges on one gate. Before we step back, the client team performs a full deployment, a rollback and an incident drill without us in the room, working only from the repository, the documentation and the runbooks. Whatever they cannot do, we have not finished. It is a demanding standard, and it is the only one that means anything, because the alternative is discovering the gaps three months later, alone, in production.
We review the result against the AWS Well-Architected Framework before go-live, not as a template the design was copied from but as the checklist the finished decisions have to survive. The handover is not the closing formality of an engagement. Done properly, it is the point of the engagement, and it is the part we design first.
John Nathan leads the cloud and data engineering practice at Responsible AI Solutions and is formerly of AWS Professional Services. The practice · Contact