From administrators to SRE: a staged transition

Many infrastructure departments want to adopt site reliability engineering (SRE) and start in the wrong place: they rename the team, buy a monitoring tool and expect the rest to follow. A few months later the team is doing exactly what it did before, with a different job title in its email signature.

SRE is not a title. It is a way of operating built on three ideas: reliability is measured from the user's point of view, repetitive manual work has a ceiling, and the team spends real time on the engineering that reduces that work. Getting there from a systems administration team is possible, but it works best in stages, without dismantling the operation that keeps the business running today. This article proposes five stages, what each one achieves and how to know when it is time to move to the next.

Why renaming the team is not enough

Google's Site Reliability Workbook, in the chapter "SRE Team Lifecycles", describes three ways to start an SRE team: create one for a new project, build a horizontal team that advises others, or convert an existing operations team. The third is the most common in established organizations, and the same chapter warns about the typical mistake: renaming the team without changing its practices.

The same text argues that you can adopt SRE practices before anyone holds the title, starting with service level objectives. That is the starting point of a healthy transition: practices and measurement change first; roles and structure adjust later, once there is evidence that the practices work.

There is a second reason to go in stages. An administration team in a regulated organization carries commitments that cannot be paused: financial closes, change windows, audits, contracts with service levels. Any transition that requires stopping all that to "rebuild" the model fails before it starts.

Five stages for the transition

Each stage produces something the next one needs. Skipping one usually forces you to go back.

Stage 1. Measure repetitive work

Google's Site Reliability Engineering book, in the chapter "Eliminating Toil", defines toil as operational work that is manual, repetitive, automatable, tactical, without enduring value, and that grows in proportion to the size of the service. Not all operational work is toil: a planning meeting or a design review is not.

For a few weeks, each person logs where their operational time goes, using a simple unit (hours) and agreed categories: restarts, user provisioning, certificate renewals, alert handling, change requests. The Workbook's chapter on toil recommends exactly that: choose an objective unit and measure before, during and after reducing it. The result is a baseline and a list of the main sources of toil. Without it, any later improvement is just an opinion.

Stage 2. SLOs for a few services

Pick two or three services with a clear business owner and available data. For each one, define a service level indicator (SLI) measured close to the user, an objective (SLO) and, above all, an error budget policy signed off by product, development and operations. The Workbook chapter "Implementing SLOs" is clear: without a written policy stating what happens when the budget runs out, the SLO is just one more indicator on a dashboard.

Do not try to cover the whole catalog. A few well-measured services teach more than fifty SLOs nobody reviews. For details on turning those SLOs into useful alerts, see our article on alerting without fatigue using SLOs.

Stage 3. Sustainable on-call and blameless postmortems

With SLOs in place, the alerts that wake someone up become the ones that show users are suffering. The rest move to dashboards or tickets. The chapter "Being On-Call" in the SRE book suggests as a reference that on-call should take no more than 25% of a person's time, and estimates a maximum of two incidents per 12-hour on-call shift, because each well-handled incident, with its analysis and follow-up, takes hours.

In parallel, the blameless postmortem takes root: a written document after each significant incident that looks for contributing causes without blaming individuals or teams, and ends with actions that have an owner and a due date. This is the stage where culture changes most, and the one that depends most on leaders setting the example.

Stage 4. Automate and cap toil

Using the stage 1 baseline, the team picks the heaviest sources of toil and automates or eliminates them. Google proposes keeping toil below 50% of each SRE's time; the rest goes to engineering that reduces future toil or improves services. That cap becomes an explicit commitment with management: if toil stays above it, the team plans how to bring it down, instead of hiring more people to absorb it.

Stage 5. New roles and training

Only now does it make sense to formalize roles. With practices working, you define SRE profiles, the criteria for a service to be operated under this model and the training plan for people coming from systems administration.

Roles and training: the slowest change

An experienced systems administrator knows how the platform really behaves, the recovery procedures and the dependencies that appear on no diagram. That knowledge is the most valuable asset in the transition, and it should not be lost by suddenly demanding a developer profile.

We recommend a competency-based plan, not a list of unrelated courses:

• Programming applied to operations: a scripting language, version control and peer code review.
• Infrastructure as code and configuration management, so that changes are repeatable and auditable.
• Measurement: SLIs, SLOs, error budgets and reading latency and error metrics.
• Incident response: coordination roles, communication and postmortem writing.
• Designing for reliability: capacity, graceful degradation and dependencies.

Combine training with guided practice: pairing operations and development profiles, short rotations through the product team and protected time for automation projects. A training plan without protected time competes with toil and loses.

What stays from ITIL

SRE and service management are not mutually exclusive. A regulated organization still needs defined processes, traceability and controls an auditor can review. What changes is how they are carried out.

• Incident management: logging, classification and communication stay. SRE adds symptom-based alerting and clear roles during response.
• Problem management: blameless postmortems are, in practice, a disciplined way to manage problems. Their actions should live in the same problem record.
• Change management: the error budget gives an objective criterion for deciding the pace of change. Standard, automated and tested changes can follow a pre-approved path; high-risk changes keep their review.
• Service level management: internal SLOs are aligned with contractual service level agreements (SLAs) and are usually stricter, to leave room to react.
• Catalog and CMDB: they remain the reference for which services exist and who owns them, a prerequisite for defining SLOs.

The rule of thumb: keep the control and record-keeping that regulation requires, and replace manual execution with measurable automation.

Stage checklist

The table summarizes what each stage achieves and what evidence you should have before moving to the next. Timelines depend on the size of the team and the number of services.

Stage	What it achieves	Evidence to move on
1. Measure toil	Baseline of operational time and its main sources	Several weeks of logging with agreed categories
2. SLOs for a few services	SLIs, SLOs and a signed error budget policy	At least one budget review cycle with product and development
3. On-call and postmortems	Symptom-based alerts, a rotation with measured load and blameless postmortems	Pages per shift recorded and postmortem actions tracked
4. Automate toil	Measurable reduction in toil against the baseline	Toil consistently below the agreed cap
5. Roles and training	Defined roles, a competency plan and service onboarding criteria	New services that join the model with SLOs and runbooks from day one

Common mistakes

• Starting with the org chart. Reorganizing before measuring creates resistance and does not change day-to-day work.
• SLOs without consequences. If exhausting the error budget changes no decision, the SLO is not governing anything.
• Automating without measuring. Without a baseline you cannot show the savings, and the program loses support at the first budget cut.
• Leaving toil uncapped. If the team absorbs all new operational work with no ceiling, engineering disappears and the model goes back to being administration under another name.
• Neglecting the people who run today's operation. The transition needs their knowledge; a plan that leaves them out loses its main asset.

Before committing to changes in the change or incident processes that auditors review, validate them with Risk and Compliance: the goal is to change how work is done without weakening control.