Configuration Drift and Hidden Dependencies: Avoiding the IT Transformation Trap

The column is a vendor-perspective opinion piece, and Cloudhouse sells application packaging and migration. Its diagnosis is still sound, and some of the evidence behind it can be checked. This article separates the general advice from the outage it cites, and from the Microsoft tooling that makes the "visibility" argument practical.

Two kinds of change, one overloaded team​

Nazir splits the pressure on IT estates into two categories.

• Voluntary change. Organizations feel pushed to adopt new tools, especially AI, and vendor messaging encourages speed. He also says inflation and slower growth push teams toward cheaper options. He gives no figures for either claim.
• Forced change. This covers operating systems reaching end of life, outages and cyber threats. He also names vendor price increases after ownership changes, using VMware as the example, which push companies to find new platforms and reduce vendor dependence.

The trap is that both kinds arrive together. Stacking them makes the estate harder to oversee, and the chance of outages and failures goes up. His central argument is visibility. Estates now span on-premises systems, cloud, servers, end-user computing and networks, and security updates are largely automated. Every extra mix of old and new systems, operating systems and products adds interactions nobody has mapped.

The column offers no study showing a universally safe rate of change, so that part is reasoned argument, not measured fact. It is still a reasonable argument for anyone who has run a migration while an unrelated patch rolled out underneath it.

Configuration drift: the quiet multiplier​

The column defines configuration drift as unrecorded or unauthorized changes that move a system away from its intended baseline. Left unmonitored, drift can stay invisible and add risk to every later change.

HashiCorp's Well-Architected documentation describes the same idea for infrastructure managed with Terraform. Drift is the gap between actual infrastructure and the declared configuration, and it can come from manual changes, cloud provider updates or unauthorized modifications. HashiCorp recommends automated detection, tiered alerting, and a documented remediation process. When drift is found, the team decides whether to restore the declared state or update the configuration to accept a legitimate change.

That last point matters. A deviation is not automatically a villain. It might be an emergency fix, a provider-side change or an attack, and the tooling cannot tell you which.

A Microsoft-flavored example: Entra Tenant Governance​

Microsoft's own tooling shows what drift detection looks like in a Microsoft 365 estate. Microsoft's documentation says configuration management in Microsoft Entra Tenant Governance lets you define configuration baselines, monitor tenants for drift, and generate snapshots of current settings. It adds that it is built on the Microsoft Graph Tenant Configuration Management APIs, which are generally available.

The model is simple:

1. Baseline. A baseline is the JSON representation of the configuration you want to monitor for a given tenant. Per Microsoft's deployment guide, you can author it by hand or generate a starting baseline by using Snapshot APIs to extract the current configuration. You then edit it to the desired state.
2. Monitor. Each monitor references a JSON configuration baseline that specifies the resources to validate. According to the deployment guide, the monitor runs automatically every six hours. Results can take up to six hours to appear after the first run.
3. Results and drifts. A monitoring result contains the execution duration, a status that indicates whether resource evaluation succeeded, and a count of detected drifts. Drift details sit in separate records. In the admin center, a drift record identifies the resource and property that differ from the baseline.
4. Remediation. Sebastian Wild's deep dive notes that the feature detects drift but doesn't remediate automatically, so fixing it is still the administrator's job. He also says the next monitor run marks the drift as fixed once you remediate.

Microsoft's own scenario illustrates the value. In its announcement, a monitor flagged a changed Intune device compliance policy, and the drift report showed it was modified accidentally. Without monitoring, Microsoft says, a team would have to comb through audit logs and guess whether a change was malicious or accidental.

Limits to plan around​

• Permissions. The Unified Tenant Configuration Management service principal must have read permissions for the resource types defined in the baselines.
• Scale limits. Microsoft's guide states each baseline can include up to 200 resource instances, with an overall daily limit of 800 resource instances across all monitors.
• Snapshot retention. Wild reports that snapshot jobs and their snapshots are retained for only seven days, so download anything you need to keep.
• Scope. A baseline only covers what you put in it. A practitioner guide on IT Knowledge Lab makes a fair point: a baseline that tries to enforce every setting across every tenant will probably fail socially before it fails technically.

Drift monitoring tells you what moved. It does not tell you what you forgot to model, which brings us to the outage.

The Railway outage: what it shows and what it doesn't​

Nazir cites a May incident in which Google Cloud suspended Railway's production account without warning. He frames it as Railway being unable to see a technical dependency on Google Cloud. Railway's own incident report gives more detail.

What happened. Railway says Google Cloud placed its production account into a suspended status at 22:20 UTC on May 19, 2026. Railway describes this as an incorrect, automated action that extended to many accounts. Railway says it had received earlier violation notices, but none immediately before the suspension. Railway reported a platform-wide outage lasting roughly until 06:14 UTC on May 20, about eight hours. Its timeline marks the incident as resolved at 07:58 UTC.

Why it cascaded. Railway's edge proxies cache routing tables from a network control plane API hosted in Google Cloud. While the cache held, workloads on Railway Metal and AWS kept serving traffic. When it expired, those workloads began returning 404 errors even though they were still running. Railway says its network was built as a mesh with redundant interconnects between AWS, GCP and its own Metal. It still had a hard dependency for workload discoverability on that one API.

Why recovery took hours. Restoring account access at 22:29 UTC did not bring services back. Railway says persistent disks, compute instances and networking each needed separate recovery. Disks were ready by 23:54 UTC, but networking and edge routing did not return until around 01:30 to 01:38 UTC. Railway also paused deployments so queued work would not swamp build systems. GitHub rate-limited Railway's OAuth and webhook integrations during recovery, which temporarily blocked logins and builds.

TechRadar's June report on the outage adds some figures. It cites more than three million users and about ten million hosted services, APIs and databases. These are TechRadar's numbers, not Railway's. It also says the issue was fully rectified at 06:14 UTC. Railway's own timeline treats that as the move to monitoring, with resolution declared later at 07:58 UTC.

The caveat that matters​

This is a dependency story, not a configuration drift story. Railway's postmortem does not say that unrecorded changes caused the outage. It points to a provider action and an architectural dependency. Drift-detection software would not obviously have prevented it. The honest lesson is broader:

• Map dependencies, including control planes, identity, routing and deployment pipelines, not just compute.
• Redundancy across clouds is not independence if a shared control plane sits underneath.
• Recovery needs rehearsing and sequencing, because restoring one layer does not restore the stack.

Railway has said it is removing the dependency, extending high-availability database shards across AWS and Metal, and moving Google Cloud out of the data plane's hot path. These are stated plans, not confirmed completed work.

The buy, rebuild or package dilemma​

When change cannot be slowed, Nazir says IT teams traditionally either buy new software or rebuild existing apps. Both are costly and slow, and he says this can entrench vendor lock-in when teams lack the engineering capacity to rewrite OS-bound applications.

He then weighs two alternatives.

• AI-built replacements. As agentic coding matures, organizations may build their own substitutes for SaaS tools. He warns this shifts maintenance, security, configuration and support in-house, so it can make change harder to oversee without extra capacity.
• Packaging and migrating existing apps. Packaging an application's or VM's existing OS dependencies lets teams move it into containers and modern desktop infrastructure without rewriting it. The app keeps its behavior but can run on current operating systems and in workspaces such as AWS.

Treat the third option with some caution. The column offers no measured savings, supported migration paths or named Windows versions. Cloudhouse sells this approach, so the pitch deserves independent evaluation. Whether packaging fits depends on the app, its dependencies, the target platform and vendor support.

A practical playbook​

Pulling the column and the supporting evidence together, here is a sensible approach for a Windows or hybrid estate.

1. List your forced changes first. Support expiry, security exposure and contract changes have hard dates. Voluntary projects should fit around them.
2. Limit overlapping high-risk projects. If you cannot test, observe and roll back three migrations at once, run fewer of them at once.
3. Write down "normal." Define baselines for high-impact settings such as Conditional Access and device compliance, and decide who approves exceptions.
4. Triage drift before reverting it. Check whether a deviation is an approved emergency fix or a provider-side change before undoing it automatically.
5. Map hidden dependencies. Ask what fails if a provider, account or control plane disappears.
6. Rehearse recovery. Include the unglamorous parts: restart ordering, rate limits on third-party integrations and queue backlogs.
7. Think hard before building your own replacements. A bespoke tool is a maintenance commitment for you, not a free licence.

Bottom line​

The transformation trap is a real and familiar problem, and Nazir's advice to prefer small, incremental, visible change is hard to argue with. Two cautions apply. The column is a vendor perspective, and the Railway example illustrates hidden dependencies rather than drift. The strongest takeaway is the practical one: you cannot safely change what you cannot see, so find out what normal looks like, and what depends on what, before you start changing it.