Consulting engagements go wrong in a predictable way: the client decides on the destination before anyone inspects the vehicle. NoOps \u2014 running IT with so much of the operational work bought and automated that no dedicated ops team is needed \u2014 attracts exactly that mistake, because the destination sounds cheap and the inspection feels optional. It is not optional. This article lays out the audit we run before any NoOps-shaped engagement proceeds, in five steps, with the specific thresholds and roadmaps that turn a hunch into an evidence-based decision.<\/p>\n
The failure mode this audit exists to prevent has a name in the industry: disbanding the operations function on migration day and calling the result NoOps. Announcements are not architectures. An audit establishes three facts before any commitment is made \u2014 what operational work actually exists, who owns each piece of it today, and what would happen to each piece under a buy-and-automate model. For terminology and history, we point clients to the NoOps page at xOps School<\/a> and move straight to measurement; the reference material is settled, the client’s situation is not. One more framing note before the steps: NoOps displaces work, it does not erase it, so every step below is about tracing where work would land and whether the landing is survivable.<\/p>\n Everything starts with an inventory, and it must be an inventory of duties rather than job titles. For each service, record: recurring tasks with their monthly hours, pages received with their severity, certificates and credentials touched, quotas consumed, and any hand-patched glue nobody has documented. Two registers matter most. The duty register captures every recurring task with its cost in hours; the ownership register captures the named human answerable for each one. Client teams routinely discover tasks that appear on no roster at all \u2014 scripts only one departed employee understood, manual failovers performed from memory, spreadsheets that quietly run payroll-adjacent processes. You cannot decide what to outsource or automate until the register is honest, and the register is never honest on the first pass. Budget two workshops, not one, and put the person who actually performs each duty in the room rather than the person who manages that person \u2014 titles flatter, hands remember.<\/p>\n The maturity framework useful here runs across five levels. At the bottom sits Level 0, where the claim is the entire implementation \u2014 leadership has declared operations abolished and nothing else has changed. Higher levels demonstrate, in order: automation covering the routine work, ownership assigned for everything the registers surfaced, rehearsed failure response, and finally Level 4, which the framework describes as low-ops by design \u2014 the state where the architecture itself minimises operational surface and the evidence is auditable. Most organisations that believe they are candidates for NoOps score a 1. That is not an insult; it is a starting coordinate. What matters is the direction of travel and the honesty of the scoring. We ask teams to bring evidence for every level they claim: the automation repository, the ownership records, the drill reports. Slides do not count as evidence at any level.<\/p>\n The model fits some workloads and fights others, and the pattern is consistent across published case work. Strong fit looks like this:<\/p>\n Poor fit has an equally clear signature: high sustained load, where reserved capacity beats on-demand pricing and procurement discipline becomes a core competency; exotic hardware or latency requirements that managed platforms cannot honour; and any service whose fate is entangled with a provider old enough to retire. Score each workload separately. A portfolio often contains both kinds, and the correct answer is per-service adoption rather than a blanket policy \u2014 which is precisely the nuance a blanket “we’re going NoOps” announcement destroys.<\/p>\n This is the step skip-prone organisations regret, because the four tests below are cheap to run in an audit and brutally expensive to run for the first time during an outage. Four tests, run in order. First, dependency arithmetic: a service can never exceed the combined availability of its critical dependencies’ intersection, so multiply the SLAs in your critical path and check the product against your actual obligations \u2014 if the maths cannot support the promise, no service model will. Second, quota headroom: compute 1 minus peak-over-quota for every constrained resource; a headroom figure near zero means the next traffic spike is an outage with a date on it. Third, runtime currency: verify that every runtime in the path sits at least 180 days away from its deprecation date, because forced migrations on a vendor’s schedule are the most expensive kind. Fourth, restore readiness: confirm your restore capability has been proven within the last 90 days, not merely documented. Each test produces either a pass, a number, or a date \u2014 anything vaguer goes back to the drawing board.<\/p>\n The audit earns its cost when it converts into a sequenced plan. The pattern that works:<\/p>\n Ninety days is enough to know whether NoOps is an operating model for you or a vocabulary item. Teams that reach day 90 with clean registers, full ownership and a rehearsed failure behind them proceed with confidence; teams still arguing about the register have learned something cheaper than a migration would have taught them. Either way, the organisation ends the quarter knowing where its operational work lives, who answers for it, and what it would cost to move \u2014 three facts most enterprises cannot state in week zero, whatever their slide decks claim.<\/p>\n A credible audit sometimes concludes against NoOps, and that conclusion has value far exceeding its cost. The standing reasons: sustained heavy load where reserved economics win, specialised hardware or timing needs, and provider-retirement risk sitting on an existential dependency. There is also the human reason the registers expose \u2014 an organisation where operational knowledge lives in two people’s heads is not ready to redistribute that knowledge to a contract. For the financial side of the follow-through, this cloud economics handbook for technical teams<\/a> covers the cost modelling the exit estimates require. If the audit points instead toward a hybrid path, the role of consulting in cloud migration<\/a> maps the middle ground, and integrating security into pipelines<\/a> handles the controls that must move with the work.<\/p>\n The summary we give every client: NoOps is a direction with a evidence trail, not a switch, and the audit is how you find out whether the direction pays in your specific case. Five steps, ninety days, and a decision you can defend to the board in numbers rather than adjectives.<\/p>\n","protected":false},"excerpt":{"rendered":" A five-step NoOps readiness audit: duty registers, maturity scoring, workload fit, failure and exit tests, and a 30\/60\/90 plan built on evidence.<\/p>\n","protected":false},"author":8,"featured_media":8130,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[30],"tags":[],"class_list":["post-8129","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops-consulting"],"yoast_head":"\nStep One: Register the Work You Already Do<\/h2>\n
Step Two: Score Your NoOps Maturity Level<\/h2>\n
Step Three: Check NoOps Fit Against the Workload<\/h2>\n
\n
Step Four: Test the Failure and Exit Paths<\/h2>\n
Step Five: Turn the Findings Into a 30\/60\/90 Roadmap<\/h2>\n
\n
When the Audit Says No<\/h2>\n