What Cloud DevOps Services Should Hand Over We have bought Cloud DevOps Services twice. The first engagement built us an excellent platform that three people understood, and two of them worked for the supplier. The second was deliberately slower and left us able to run it ourselves. The difference was written into the contract before anybody started. The deliverable is a capability, not a platform A pipeline, a cluster, and a set of infrastructure definitions are artefacts. They are not the thing you are buying. What you are buying is the ability to change those things safely, without the supplier, for years afterwards. Our first engagement delivered the artefacts and not the ability, and we discovered the gap four months after the team left. Cloud DevOps Services that quote only for building are quoting for the part that is visible. Everything in your accounts, from the first commit The structural rule that makes handover possible. Repositories, cloud accounts, pipelines, state files, secrets, dashboards, and registries all belong to us and always did. The supplier worked inside them. Our first engagement had the pipeline running under the supplier's tooling and their cloud organisation. Recreating it took us eleven weeks and we lost the build history entirely. Pair from day one, not at the end Handover is a practice, not a phase. Our engineers paired on every piece of work, and the proportion of work done by our own people was reported monthly. It started at around a tenth and had to rise. By the midpoint our team was leading and the supplier was reviewing. By the end they were answering occasional questions. That rate was in the contract as a measured deliverable rather than an aspiration, which is the only reason it happened. Standards before tooling The order that prevented most of our disagreements. We agreed how environments are separated, how changes are reviewed, how secrets are handled, what must never be done by hand, and how a rollback works. Then we chose tools that fitted. Our first engagement did this the other way round and we inherited a set of decisions embedded in tooling that nobody had discussed. Infrastructure as code, with no exceptions Nothing is created by hand in any environment. That rule is uncomfortable for about a month and then it becomes the thing everybody relies on. Any environment can be rebuilt, any change is reviewable, and the question of what is actually deployed has a definite answer. We audit for drift weekly. Anything found by hand is either codified or removed, and the number has been close to zero for over a year. Images and machines, not just containers A gap in our first platform. Containerised workloads were well handled and the virtual machines were not. Those were built by a post launch script that took nine minutes and sometimes failed. Our second engagement brought machine image building into the same pipeline, using DevOps Packer , built from tagged commits and patched on a weekly schedule. That removed the most inconsistent part of the estate. Plan for the migration period honestly Most engagements begin during a move. Realistic application migration strategies involve a long middle period where some workloads are modernised, some are lifted as they are, and both run at once. A platform designed only for the end state makes that period harder than it needs to be. Ours supports both deliberately. Virtual machines built from images, containers on the cluster, and one pipeline, one set of standards, and one monitoring view across both. Decide what the platform team owns Ambiguity here produces two teams doing the same work differently. Ours owns the pipeline, the cluster, the image building process, the shared infrastructure modules, and the monitoring platform. Application teams own their services and deploy through templates. Anything unusual goes through a conversation rather than through a ticket. That boundary was agreed in writing during the engagement, and a good Cloud DevOps Services partner will insist on settling it before building anything, because the platform design follows from it. Runbooks written as the work happens Documentation written at the end is written from memory. Every service and every pipeline component has a runbook written when it was built, covering what it does, what normally goes wrong, and what to do about it. Those are one page each, and they are what made it possible for our own engineers to take the on call rota. What we require in the contract ● All artefacts in our accounts from the first commit. ● A reported monthly figure for work done by our own engineers. ● Standards agreed before tools are chosen. ● Nothing created by hand, with weekly drift auditing. ● Machine images and containers in the same pipeline. ● A runbook per component, written during the build. ● A defined exit with notice, handover and overlap. Common questions How long should an engagement run? Ours ran eight months. Long enough to hand over properly, short enough that handover stayed a priority. Can a supplier use its own tooling? Not for anything that stays. Cloud DevOps Services built on a supplier's platform leave you dependent on it after they go. Should the supplier run the platform afterwards? Only if the contract still transfers the capability. Cloud DevOps Services that keep operations indefinitely have built a dependency rather than a platform. What is the clearest warning sign? A proposal with no handover plan and no measured transfer. Delivery looks the same and the outcome is entirely different. What about machine images? Same pipeline, same standards. Ours are built with DevOps Packer from tagged commits and patched weekly, which removed the most inconsistent part of our estate. Who should own the standards? You should. A supplier can draft them and the decisions last far longer than the engagement. What the second engagement left us A platform our own team runs, extends, and is on call for, with no supplier involvement. The technology is not better than what we got the first time. What is different is that our engineers built half of it, the runbooks exist, everything sits in our accounts, and nothing important left when the team did. Cloud DevOps Services are worth buying when that outcome is written into the contract rather than hoped for.