Configuration drift: what actually changes after project handover

Blog December 2025

Every well-run transformation ends the same way: a signed-off design, rationalised policies, packaged applications, documented baselines and a handover pack. Twelve months later, almost none of it is quite true any more. Nothing dramatic happened. The estate just drifted, and drift is the failure mode nobody budgets for.

Who changes what

Drift is not caused by careless people. It is caused by sensible people solving today's problem with tomorrow's debt, and it comes from three predictable directions.

Helpdesk exceptions. A user cannot print, so their device is moved out of the policy group that is suspected of causing it. A stubborn application fails, so someone grants local admin “just while we investigate”. An antivirus exclusion is added to close a ticket. Each fix is rational in the moment; the investigation that was supposed to follow rarely does, and the exception becomes permanent by default.

Vendor quick fixes. A supplier's support engineer joins a remote session to get their product working and leaves the estate subtly different: a service account with broader rights than the design allowed, a security prompt suppressed, a firewall rule added directly on the server. It fixed the fault, it was never written down, and it now exists only in that engineer's memory.

One-off policies that never leave. A policy is created to work around a driver problem, scoped to a group with “temp” in the name. The driver is fixed in the next update. Years later the policy is still applying, still winning conflicts, and nobody remembers what it was for or dares to remove it. We wrote about this accumulation pattern in Group Policy specifically in an earlier post; modern cloud-managed estates are not immune, they just drift in a tidier console.

Why nobody notices

Every one of those changes is small, local and individually defensible, which is exactly why they escape attention. No single change breaks anything. The estate keeps working, so the working estate is assumed to match the documented one. The documentation is not wrong on day one; it becomes wrong gradually, and there is no moment at which anyone decides to let it happen.

The documentation is not wrong on day one; it becomes wrong gradually, and there is no moment at which anyone decides to let it happen.

Then reality forces a reconciliation. An auditor asks why a set of devices is exempt from disk encryption and nobody can say. An incident responder rebuilds a server from the documented configuration and the application will not start, because production depended on three undocumented changes. A security baseline review finds settings that were hardened at go-live and have quietly relaxed since. In each case the painful part is not the finding itself; it is that the organisation cannot say when the change happened, who made it or why.

What disciplined drift management looks like

The answer is not to freeze the estate. Change is the point of having one. The answer is to make the intended state explicit and every departure from it visible. Four habits do most of the work.

Versioned baselines. The intended configuration must exist as an artefact, not as tribal knowledge: policies, security settings, group memberships and build definitions, captured and version-controlled. When the intent changes, the baseline changes with it, with an author and a reason. If you cannot state what correct looks like, you cannot detect drift, only surprise.

Alerting on change. Compare the live estate against the baseline on a schedule, and treat every difference as one of two things: a change that matches an approved record, or a flag that someone investigates this week. The interval matters. Drift found in days is a conversation; drift found at the annual audit is a project.

Controlled restore. Seeing drift is only useful if reverting it is routine. For each flagged change the decision is explicit: keep it, and fold it into the baseline; or revert it, through the same controlled mechanism that deployed it in the first place. Estates where rollback is frightening stay drifted, because nobody will touch what they do not understand.

Change records with expiry dates. Exceptions are legitimate; immortal exceptions are not. Every exception should carry an owner, a reason and a review date, and the tooling should resurface it when that date arrives. Temporary has to mean something.

Handover should include the discipline, not just the estate

Most of this is a habit problem, not a tooling problem, and the cheapest moment to form the habit is at handover, when the baseline is fresh and the delta is zero. When we hand over a migrated estate, the as-built state our discovery tooling captured during the project becomes the first versioned baseline, and the drift review becomes a standing operational rhythm rather than a forensic exercise years later. A pristine estate is a snapshot. A governed one is a practice.