HomeScenarios › Killing the last dc
GPO-TO-CLOUD MODERNISATION

Killing the last domain controller

Devices in Intune, identities in Entra — and one domain controller still humming in the corner because of drive maps, logon scripts and years of Group Policy nobody fully owns. Retiring it is a translation job, and someone has to carry the risk.

The server that survives every review

It is rarely the important workloads that keep the last DC alive. It is the unglamorous ones: mapped drives, printer deployments, a logon script written by someone who left years ago, and a Group Policy estate that has accreted settings longer than anyone currently on the team has been there. The migration to cloud-native management is mostly done — and the remainder is the part where every setting has to be understood, translated and defended.

If the translation is wrong, users notice on Monday morning. That is why the DC survives: not because anyone wants it, but because nobody wants to own the week it goes badly.

Why the last mile is the hardest

The blocker is rarely conviction. It is the shape of the work. GPOs do not map one-to-one onto Intune:

Doing that by hand means auditing what is actually still needed, sourcing or writing the cloud-native replacement for each item, testing it, and documenting it well enough that the next person can trust it. It is weeks of careful, mundane assembly — precisely the kind of work that keeps losing to whatever is on fire this week. So the DC keeps humming.

What the catalogue already carries

Decolla's approach is not to migrate your GPOs mechanically. It is to make the rebuild cheap. The Library is a curated catalogue of 260+ pre-built, industry-tested build items across 21 sections — the recurring mundane fixes every helpdesk re-solves, and baseline hardening — delivered through Decolla's own mechanisms into your own Microsoft Intune and Autopilot tenant. A conditional engine filters and defaults the catalogue to what you are actually building — platform, chassis, existing estate versus new, locale — so you choose from what is relevant rather than wading through everything.

Before anything runs, you get an itemised written plan. Every item states how it will be delivered and its reversibility class — automatic, reversible, or explicitly flagged irreversible — so the person who owns the risk can read the whole thing and approve it. Deployment then runs unattended in your tenant, and you can roll back per item or the whole build. Rollback covers Decolla's own changes only: it will not unstick a failed Microsoft install, and does not claim to.

What we won't pretend

Straight answers, because you would find the gaps anyway:

Retire it on purpose

The last DC rarely dies of natural causes — it dies of a failed disk, at a date it chooses for you. The alternative is a deliberate retirement: a written plan you have read and approved, pre-built items from the Library that have been tested elsewhere, and a rollback path for everything Decolla changes along the way.

Decolla is in private build at The Cloud Platform, and the early-access waitlist is the only door in right now. If the last DC in your server room is overdue a decommission date of your choosing, join it below.

See it on a real device.

Decolla is in private build — early-access members see a build defined, deployed and rolled back first.

Get early access