Windows Server 2016 AD CS: Upgrade or Migrate a Certification Authority

A certification authority (CA) is the server whose private key every certificate it issued depends on. Moving one is therefore less about files and more about protecting a key and keeping the trust chain unbroken. This guide covers an Active Directory Certificate Services (AD CS) CA on Windows Server 2016: the two routes Microsoft documents, the exact backup and restore commands, the rollback point, and the mistakes that break certificate validation across the estate. Sources checked 6 November 2026 against Microsoft Learn and Microsoft Lifecycle; they are listed at the end.

Verdict

Verdict: Either.

Microsoft's role matrix supports both an in-place upgrade and a migration for AD CS; migrate when you want a new server, a new name or a clean start, and keep the CA key and backups protected either way.

An in-place upgrade is attractive because the CA keeps its name, key and database. A migration is attractive because the old server stays available as a fallback. The matrix says a CA migration cannot be done without downtime, so plan for a window in which no certificates are issued.

Who this is for and what changes on the end-of-support date

This is for anyone running an enterprise or standalone CA, root or issuing, on Windows Server 2016, including the offline root that is switched on once a year to publish a revocation list.

Microsoft Lifecycle lists Windows Server 2016 under the Fixed Lifecycle Policy. The Lifecycle table shows the extended support end as 1/13/2027 6:59:59 AM, while Microsoft's extended security updates page names 12 January 2027. Plan to finish before 12 January 2027.

Certificates keep validating on the day, because validation depends on the CA certificate and revocation lists, not on the operating system version. What changes is that the server holding the CA private key stops receiving security updates unless you buy Extended Security Updates. On ESU, Microsoft's Azure Arc documentation says Windows Server 2016 reaches end of support on January 12, 2027, and that Extended Security Updates provide Critical and Important security updates for up to three years, through 2030, without new features, customer-requested nonsecurity hotfixes or design change requests. Arc-enabled ESU can be configured in the Azure portal from August 3, 2026, and its billing begins January 13, 2027. Standard and Datacenter editions are supported; physical-core licences need at least 16 cores per machine, and virtual-core licences need at least 8 per VM and use Standard. You must attest to Software Assurance or an equivalent server subscription, or license through SPLA. The pages I read show no price, so get a quote. Microsoft describes ESU generally as a last resort paid option and a temporary bridge, so treat it as a way to finish a migration, not as the plan.

Decision table

Steps, with the rollback point

These steps follow Microsoft's migration guide and assume you keep the CA name. If you rename the CA host, the guide adds registry edits and permission changes on the AIA and CDP containers.

1. Inventory the CA. Record the CA type and name with certutil -cainfo, the templates assigned with certutil -catemplates > catemplates.txt, and the publishing locations with certutil -getreg CA\CRLPublicationURLs and certutil -getreg CA\CACertPublicationURLs. List what the CA issues: web servers, domain controllers, network devices, smart cards, code signing. Check expiry dates for the CA certificate and the next CRL.
2. Check who can do it. For enterprise CAs you need to be in Enterprise Admins or Domain Admins, plus be a CA administrator. Prepare a protected location for backups that the destination server can reach.
3. Publish a long CRL. Microsoft recommends publishing a CRL whose validity extends beyond the planned migration window, especially for a root CA, so validation continues while the CA is down. Record the original publishing period and reset it afterwards. Do not make it excessively long, because clients only download a new CRL when the cached one expires.
4. Back up everything. Microsoft lists the CA database, private key, registry settings, CAPolicy.inf and the template list. Use Backup-CARoleService -Path "D:\CABackup" or certutil -backupdb D:\CABackup and certutil -backupkey D:\CABackup (you set a password for the key file), export the registry with reg export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration D:\CABackup\CertSvc.reg, and copy C:\Windows\CAPolicy.inf if you use one. If an HSM holds the key, follow the vendor's backup procedure. Verify you see the .p12 file and a Database folder with certbkxp.dat, edb*.log and .edb files.
5. Stop issuance. Run net stop certsvc. Microsoft says to do this after the backup so no more certificates are issued.
6. Choose your rollback point. Microsoft says the CA role service should be removed from the source before it is installed on the destination, because both share the same common name and the role's configuration data lives in Active Directory. It also says some administrators leave the role installed so the source can be brought back quickly if migration fails; if you do, disable certsvc and shut the source server down before installing on the destination, and do not remove the role after migration. Rollback point: that disabled, shut-down source plus the backup.
7. Move the server identity (only if the host name stays). Remove the old computer account with Remove-ADComputer, rename the new server with Rename-Computer, and join it with Add-Computer. A standalone CA that is not domain-joined only needs the rename.
8. Install the CA role on the new server. Copy CAPolicy.inf to the Windows folder first. Import the .p12 into the local computer's Personal store, then add the AD CS role choosing the same Enterprise or Standalone and Root or Subordinate type, and Use existing private key. On Server Core use Install-AdcsCertificationAuthority. If an HSM is involved, repair the certificate-to-key link with certutil -repairstore My "{serial}".
9. Restore the database. Stop the service, run Restore-CARoleService -Path "D:\CABackup" -DatabaseOnly -Force (point it at the parent of the Database folder) or certutil -f -restoredb D:\CABackup, and start the service.
10. Restore the settings. Back up the new server's default registry first, review the exported .reg for host names and drive paths, then net stop certsvc, reg import, set DBSessionCount to 64 (hexadecimal), and check the database and log paths. Re-add templates with certutil -setcatemplates +TemplateA,TemplateB from your saved list.
11. Verify extensions and publish. Check the CRL distribution point and authority information access extensions and publishing options still match your design, then publish a fresh CRL with certutil -CRL.
12. Test, then retire. Issue a test certificate from each template that matters, validate a chain from a client with certutil -verify -urlfetch, and keep the source server powered off and untouched for a business cycle before deleting it.

Mistakes that cause outages

• No long CRL. Clients that cannot reach a valid revocation list may reject certificates while the CA is down.
• Installing the new CA before removing the old one. The shared common name means removal later deletes configuration the new CA needs.
• Leaving the backup unprotected. The .p12 holds the CA private key. Anyone who gets it and its password can issue certificates as your CA. Store it encrypted, restrict access, and delete working copies afterwards.
• Forgetting templates. The list is stored in Active Directory, not in the database or registry backup, so record it before you start.
• Restoring the wrong folder. Point the restore at the parent of the Database folder, not the folder itself.
• Copying the whole registry file blindly. Some values are tied to the old host or drive layout; review before import.
• Breaking publishing. If the name changes, grant the new server rights on the AIA and CDP containers and update any CDP or AIA paths and DNS aliases.
• Ignoring the HSM. Keys held in an HSM follow the vendor's backup, not the file steps.

Checklist

• CA type, name, templates and publishing locations recorded
• Long-lived CRL published and original period noted
• Database, key, registry, CAPolicy.inf and template list backed up and verified; key backup stored securely
• Issuance stopped; source disabled and shut down (or role removed, by choice)
• New CA installed with the existing key; database and settings restored
• Templates reassigned; extensions checked; fresh CRL published
• Test certificates issued and chains validated
• Source kept offline for a business cycle; backups stored securely
• Finish before 12 January 2027

Related tools and reading

Check the Windows Server 2016 end-of-support planner for the rest of your roles. Our certificate expiry planner helps you list what the CA's certificates will need next, and the CSR and private key generator works locally in the browser. The full series is in the role-by-role guide.

Sources

Checked 6 November 2026.

• Windows Server 2016 on Microsoft Lifecycle
• Extended Security Updates for SQL Server and Windows Server
• Prepare to deliver Extended Security Updates for Windows Server through Azure Arc (2016 dates, coverage, Software Assurance)
• License provisioning guidelines for Extended Security Updates for Windows Server (editions, core minimums)
• Billing service for Extended Security Updates for Windows Server through Azure Arc (billing start)
• Product Lifecycle FAQ: Extended Security Updates
• Upgrade and migrate roles and features (AD CS: in place yes, migration yes, not downtime-free)
• Migrate a Certification Authority in Windows Server (backups, role removal, restore, registry, templates, CRL)
• Plan your Windows Server upgrade path

General planning information, not a design for your environment. Rehearse the restore in a lab, and treat the key backup as a secret.