Active Directory Certificate Services (AD CS) Migration — Move Your Certificate Authority to Windows Server 2025

Because Windows Server 2016 leaves extended support on 12 January 2027 per Microsoft's product lifecycle, and after that date the operating system under your CA receives no security updates unless you buy Extended Security Updates. A CA is one of the highest-value targets in a domain — whoever controls it can issue certificates that authenticate as anyone — so running it unpatched is a different order of risk than an unpatched file server. Microsoft offers ESU for Windows Server 2016 through Azure Arc, metered per core per year to your Azure subscription (enrollment through Azure Arc is a separate short engagement), which buys time at Microsoft's price; it does not change the fact that the CA has to move, and every month on ESU is money spent on delaying a two-week project.

No. The migration keeps the CA name, the CA certificate and its private key, and restores the database with every certificate the CA ever issued or revoked. Certificates already on laptops, phones, servers and smart cards keep chaining to the same CA certificate and keep validating against the CRLs the new host publishes. Templates live in Active Directory, not on the CA, so they are untouched; only the list of which templates the CA publishes is restored. Re-enrollment becomes necessary only if you choose a modernization add-on that renews the CA certificate with a new key — and that is a decision, scheduled deliberately, not a side effect.

Yes, and Microsoft's procedure covers it: the CA's server-name registry value, the CDP and AIA extensions and the permissions on the Active Directory containers are updated to the new host. The catch is in the certificates already issued — they carry CDP and AIA URLs with the old name, so the old name must stay resolvable until they expire, usually through a DNS alias pointing at the new host. Keeping the old host name (by retiring the old computer object and renaming the new server before it joins the domain) avoids that entirely, and we recommend it where nothing else depends on the name. Either path is inside the fixed fee; the plan states which one you chose and why.

Microsoft's role matrix supports both: an in-place upgrade to Windows Server 2025 is supported from Windows Server 2012 R2, 2016, 2019 and 2022, and AD CS is listed as upgradeable in place. We deliver a migration to a new host instead because it leaves the original server intact as a rollback until you sign the decommission list, sheds years of accumulated configuration debt on the old host, lets you move the CA off a domain controller or into a different placement, and validates the whole chain — CRL, AIA, templates, autoenrollment — as part of the work rather than hoping it survived. If you specifically want an in-place upgrade, the Windows Server 2016 to 2025 Upgrade Service covers it — and routes CA role holders to this migration, for the reasons above.

It gets powered on, under your supervision, to publish a CRL whose validity covers the migration window and the schedule you agree for the future; if the root itself moves to a new host, its key and database migrate under the same backup-and-restore procedure as the issuing CAs, on a machine that never joins the domain. Then it is shut down again and the as-built document records when it next has to be turned on. If we find the root's CRL has already expired — more common than anyone admits — that is treated as a live incident and fixed before anything else, because every certificate below it is failing revocation checks already.

They are quoted add-ons, not part of the fixed fee, and the reason is honest: each of them is its own small migration. NDES has a service account, IIS settings, registry values and, in most estates, the Certificate Connector for Microsoft Intune, all of which are rebuilt rather than restored; the Online Responder has its own revocation configuration and signing certificates; the Certificate Enrollment Web and Policy Web Services and CA Web Enrollment bring IIS and authentication settings. They share the same January 2027 deadline if they run on Windows Server 2016, so the inventory captures them and the quote covers them alongside the CA migration.

Yes, as long as the CRL published before cutover covers the window — which is why publishing it is a plan item. While a CA is between hosts nobody can enroll a new certificate or renew one, but every certificate already issued keeps validating because relying parties check the CRL they have cached or can download, not the CA itself. After the restore we publish a fresh CRL from the new host and run the validation pass: an 802.1X authentication through NPS, a VPN connection, an LDAPS bind and a smart-card logon where you use them, each against a certificate chained to the migrated CA.

The health check is a review of the PKI while we already have it apart: signing algorithm and key length per CA, CRL validity and overlap against how often the root is really powered on, Cert Publishers membership of the CA computer accounts, template permissions that let a requester supply their own subject name, and whether a CA runs on a domain controller. Strong certificate mapping is Microsoft's change under KB5014754: domain controllers now require an authentication certificate to be strongly bound to the account — in practice through the SID extension a patched CA adds when it issues the certificate — instead of matched on a subject name that could be spoofed. Enforcement has been on by default since 11 February 2025, and Microsoft removed the compatibility override with the September 2025 update. The report tells you which of your authentication certificates comply; replacing the ones that do not is a re-issuance decision we scope separately.

Usually both, in that order. Microsoft Cloud PKI issues certificates to Intune-managed devices through Intune certificate profiles, and its bring-your-own-CA option chains a cloud-hosted issuing CA to your existing root — so the root has to be healthy and supported first, which is what this migration delivers. Cloud PKI then takes the Wi-Fi and VPN device-certificate workload off the on-premises issuing CA without an NDES server in the path. What it does not cover is everything else your CA does today: smart-card logon, code signing, server and LDAPS certificates, and any device Intune does not manage. It is licensed through the Intune Suite, the standalone Cloud PKI add-on or, following Microsoft's December 2025 packaging change, Microsoft 365 E5; we confirm your entitlement before proposing the add-on, and the fixed fee includes a written recommendation either way.

It works, and plenty of small and mid-size estates were built that way, but it is a poor place for a CA: the CA role cannot be removed from a domain controller without care, the server's lifecycle is now tied to two critical roles at once, and a compromise of either is a compromise of both. The migration is the natural moment to separate them — the CA moves to its own Windows Server 2025 host under this service, and the domain controller's own move, if it needs one, runs through the domain controller and roles migration. The plan sequences the two so the CA is never left on a server that is about to be demoted.

No — and it should not, silently. Changing the signing algorithm or the key length means renewing the CA certificate with a new key, which puts a second chain into circulation: certificates issued before the renewal chain to the old CA certificate, those issued after chain to the new one, and every relying party has to trust both until the old certificates age out. That is a planned change with a rollout, not something to fold into a restore. The health check flags it with a recommendation, and the modernization add-on delivers it, scheduled after the migration has been approved and the old hosts are gone.

$3,950 per project, fixed, quoted in writing before work begins — you pay after you approve delivery. The fee covers a two-tier PKI with one root and up to two issuing CAs, whether or not the host names change. It stops applying as-is when the inventory shows more issuing CAs, multiple forests, NDES, OCSP or an HSM-protected key; those come back as a per-estate quote, again in writing, before any work starts. Add-ons — modernization, Cloud PKI, the enrollment services — are priced alongside and scheduled only after you approve the migration itself.

Issuing CAs can — as Azure virtual machines with line of sight to your domain controllers, which many estates already have through a site-to-site VPN or ExpressRoute — and the root stays offline wherever you keep it. Moving a CA into an Azure virtual machine is a quoted add-on because the placement work (network, name resolution, the CDP and AIA paths that domain and non-domain clients reach) is its own design step, and the physical-server migration to Azure covers the host side. The migration procedure itself is the same.

Installing or removing an enterprise CA needs Enterprise Admins or equivalent rights, plus local administrator on the source and destination hosts and console access to the offline root. We ask for that access time-bound to the maintenance windows and approved by you, use it for the migration steps and nothing else, and hand it back at the end; the as-built document records what was done with it. If your estate already manages privileged access through tiering, we work inside that model rather than around it.

A PKI on supported hosts that behaves exactly as it did before, plus what most estates never had: an as-built document that names every CA, template, publishing location and dependency; a written backup procedure with a tested backup of each new CA; a health-check report with findings and recommendations; a signed decommission list with the rollback expiry date; and a written recommendation on the add-ons, stating what each would change for your relying parties and what it would cost. Your administrators walk through the new hosts and the backup routine at handover, and you approve delivery before the invoice.