Side-by-Side vs In-Place ADCS Upgrade: Which Approach Should You Choose?

Windows Server 2012 and 2012 R2 lose their final Extended Security Update on October 13, 2026. By now, most organizations running AD CS on that platform have accepted they need to move, the open question is which of the two fundamentally different paths to take: upgrade the existing server in place, or migrate the CA role to new hardware side by side. Get this decision wrong and you either take on unnecessary risk for a routine move, or burn weeks over-engineering a migration a simple upgrade would have handled.

This is the third piece in our ADCS migration series, alongside the complete migration and modernization guide and the 2012 R2-to-2022/2025 version-specific checklist. This post is the decision framework itself: a direct comparison across the six factors that actually determine which path is right for your environment.

TL;DR: Key Takeaways

In-place upgrade preserves everything automatically, but gives you one shot to get it right: The CA role, private key, database, and configuration travel with the OS upgrade, so there’s less manual work, but also no partial rollback if something breaks mid-upgrade.
Side-by-side migration trades more manual steps for a safety net: You do more work up front (exporting keys, restoring databases, redirecting publishing points), but the old server stays intact as a fallback until you’re confident the new one is healthy.
CA identity preservation is possible with both paths, but only automatic with in-place: Side-by-side migration requires you to deliberately export and restore the same private key and Common Name; skip that step and you’ve built a new hierarchy without meaning to.
OS compatibility limits which path is even available: Microsoft’s supported in-place upgrade paths cap how many versions you can jump in one step; a 2012 R2-to-2022 or 2025 jump may require an intermediate hop or rule in-place out entirely.
Testing requirements differ in kind, not just degree: In-place upgrade testing focuses on validating the upgrade completed cleanly; side-by-side testing focuses on validating the new environment matches the old one across every dependency.

The Decision at a Glance

Factor	In-Place Upgrade	Side-by-Side Migration
Risk profile	Concentrated in a single event; failure affects your only CA	Distributed across more steps; each step is individually recoverable
Downtime	One maintenance window per OS version hop	Can approach zero downtime with parallel run
Rollback	VM snapshot or full backup restore only	Old server stays live as an immediate fallback
CA identity preservation	Automatic, no action required	Requires deliberate key and name export/restore
OS compatibility	Constrained by Microsoft’s supported upgrade paths	Any target OS, since you’re building fresh
Testing focus	Validating the upgrade completed without corruption	Validating full parity between old and new environments
Best fit	Healthy CA, current-ish OS, one or two versions behind	End-of-life OS, aging hardware, HSM re-platform, multi-hop jump

The rest of this post walks through each factor in depth.

Risk

The two paths fail in different ways, and understanding the failure mode matters more than which one sounds safer on paper.

In-place upgrade risk is concentrated: You are modifying your only CA in place. If the OS upgrade process hits a driver conflict, an incompatible third-party agent, or an interrupted installation, you can end up with a CA in an inconsistent state, mid-upgrade, with no second server to fail over to. The risk is low in absolute terms on healthy, well-patched source systems, but it is binary: the upgrade either completes cleanly or it doesn’t, and there’s limited middle ground.

Side-by-side migration risk is distributed but broader in scope: You introduce more discrete steps: database backup and restore, private key export and import, registry configuration replication, CDP/AIA redirection, and dependent-system repointing. Each step is individually lower-risk and independently testable, but there are more places for something to go quietly wrong, particularly around AIA/CDP continuity, which doesn’t fail loudly; it fails weeks or months later when a certificate issued before cutover can no longer chain or check revocation.

Neither path is categorically safer. In-place upgrade concentrates risk into a single, well-understood event; side-by-side migration spreads risk across more steps, each recoverable, but with more surface area for a step to be missed.

Downtime

In-place upgrade downtime is a single, bounded maintenance window per OS version hop. The CA is offline for the duration of the Windows Server Setup process, which on modern hardware typically runs 30 to 90 minutes per hop, plus validation time afterward. If your jump requires multiple hops (say, 2012 R2 to 2016 to 2019 to reach a supported intermediate point), you’re scheduling multiple windows, each with its own validation checkpoint.

Side-by-side migration downtime depends entirely on how you sequence the cutover: If you build and validate the new CA fully before redirecting any traffic to it, actual service interruption can be reduced to the time it takes to update DNS, GPO, or NDES/CES endpoint references, often measured in minutes, not hours. Some organizations run the old and new CA in parallel for a defined validation window with zero enrollment downtime at all, cutting over only once confidence is established. The tradeoff is elapsed project time: side-by-side migrations typically take longer end to end, even though the actual service interruption can be shorter.

If your organization has strict change-window constraints, side-by-side generally gives you more control over exactly when and how long the interruption is. If you can absorb a single bounded window, in-place is simpler to schedule.

Rollback

This is where the two paths diverge most sharply.

In-place upgrade rollback depends entirely on pre-upgrade backups: There is no "leave the old version running" option, because it’s the same server. Your rollback mechanism is a VM snapshot taken immediately before the upgrade, or a full server backup and restore. If you’re on physical hardware without snapshot capability, rollback means a full bare-metal restore, which takes meaningfully longer and carries its own risk of an incomplete or corrupted backup.

Side-by-side migration rollback is structurally simpler: The old server exists, intact, on its original hardware, for as long as you choose to keep it powered on. If validation on the new server turns up a problem, you re-point dependents back to the old CA and you’re back to a known-good state within minutes, no restore process required. This is the single biggest practical advantage of side-by-side migration, and it’s the main reason we recommend it for any migration involving meaningful uncertainty, an unfamiliar OS jump distance, an HSM re-platform, or a CA that hasn’t been touched in years.

Whichever path you choose, define your rollback trigger criteria before you start, not during a live incident. Decide in advance what conditions constitute "roll back" versus "push through and fix forward."

CA Identity Preservation

A CA’s identity, meaning its Common Name and private key, is what every certificate it has ever issued trusts. Preserving that identity correctly is what makes a migration a migration rather than a fresh start that orphans your existing certificate population.

In-place upgrade preserves CA identity automatically: Since the OS is upgraded underneath the existing CA role, the private key, database, and Common Name never move. There is no export or import step, and no opportunity to accidentally generate a new key. This is arguably the strongest guarantee either path offers for identity continuity.

Side-by-side migration preserves CA identity only if you deliberately engineer it to: During role installation on the new server, you must select "Use existing private key" and reference the exported key and certificate from the old CA, rather than letting the installation wizard generate a new key pair. Skip this step, intentionally or by accident, and you’ve built a new, unrelated hierarchy: every certificate issued by the old CA will fail to chain to the new one, and every endpoint needs re-enrollment. This is the single most consequential decision point in a side-by-side migration, and it’s worth a dedicated verification step (confirming the new CA’s thumbprint matches the old CA’s exactly) before you consider the migration complete.

If CA identity continuity is your top priority and you have any doubt about executing the key export/import correctly, that alone is a reason to lean toward in-place upgrade, or to bring in PKI expertise to execute the side-by-side key migration.

OS Compatibility

This factor can eliminate one path from consideration entirely before risk or downtime even become relevant.

According to Microsoft Learn’s official guidance, Windows Server 2025 extended in-place upgrade flexibility so that nonclustered systems can jump directly from Windows Server 2012 R2, 2016, 2019, or 2022 straight to 2025 in a single upgrade. For earlier targets, Windows Server 2022 and older, Microsoft generally supports a maximum two-version jump, meaning a 2012 R2 CA targeting 2019 or 2022 typically needs an intermediate hop rather than a single leap. Always confirm the exact supported source-to-target path against Microsoft’s current documentation before scheduling anything; an unsupported jump fails outright during setup rather than degrading gracefully.

Practical implication: if your target is Windows Server 2025, in-place upgrade is viable directly from 2012 R2 on nonclustered systems, at least from a Microsoft-support perspective. If your target is 2022 or earlier, you’re likely looking at a multi-hop in-place upgrade, which stacks multiple maintenance windows and multiple points of potential failure. At that point, side-by-side migration to fresh 2022 or 2025 hardware often becomes the more practical option purely on elapsed-time and risk-concentration grounds, independent of anything else.

Hardware age matters here too. In-place upgrade keeps you on your existing hardware; if that hardware is itself approaching end of life or lacks resources for the newer OS, side-by-side migration to new hardware solves two problems (OS and hardware refresh) in one project instead of deferring the hardware question to a second effort later.

Testing Requirements

The two paths require genuinely different validation approaches, not just more or less of the same checklist.

In-place upgrade testing centers on confirming the upgrade completed without corruption: After each hop: confirm Certificate Services starts automatically and stays running, issue a test certificate from a low-risk template and verify it validates end to end, confirm the CA certificate and private key are intact with certutil -verify -urlfetch, and check that CRL publication resumed on schedule. Because the underlying role, database, and configuration didn’t move, you’re primarily testing that nothing broke during the OS transition itself, not that dependent systems still work, since those relationships never should have changed.

Side-by-side migration testing centers on validating full parity between the old and new environments across every dependency your pre-migration audit identified. That means: testing enrollment for a representative certificate from each template family, confirming AIA and CDP resolve correctly from multiple network segments, verifying NDES/SCEP, RADIUS/NPS, and any MDM-driven enrollment still issue certificates correctly, confirming domain controllers in every site build a valid chain to the new CA, and checking that autoenrollment via Group Policy completes a full refresh cycle without error. Because more moved, more needs independent verification, and unlike in-place upgrade, you have the luxury of running this validation against the new server while the old one is still live and handling production traffic.

In both cases, test with your actual client fleet’s capabilities, not just a modern management workstation. Windows Server 2022 and 2025 disable TLS 1.0 and 1.1 by default; a legacy client or scripted enrollment tool that only negotiates older TLS versions will fail against either a freshly upgraded or freshly migrated host unless you’ve deliberately tested and, where genuinely necessary, re-enabled compatibility.

Which One Should You Choose?

A few scenario-based rules of thumb, drawn from the factors above:

Choose in-place upgrade if: your CA is on reasonably current, healthy hardware; your target OS is reachable in a single supported hop (or you’re comfortable scheduling a short multi-hop sequence); you have a reliable snapshot or backup mechanism tested and ready; and CA identity continuity is your top priority with no appetite for a manual key export/import step.
Choose side-by-side migration if: your source OS is already end of life or requires a multi-hop upgrade path to reach your target; your hardware needs refreshing anyway; you’re also re-platforming your HSM or changing key storage providers; you want the old server available as an immediate rollback option; or you have strict change-window constraints that favor a parallel-run cutover over a single bounded maintenance window.
Choose side-by-side migration and rebuild the hierarchy (rather than preserving CA identity) if: your existing hierarchy has accumulated years of template sprawl, a weak key size, or a CP/CPS that no longer reflects reality, and you’re willing to run a re-enrollment campaign to get a genuinely clean start.

If you’re still unsure after weighing these, the safer default for a 2012 R2 source environment is side-by-side migration, specifically because of the rollback advantage: an OS that old carries enough accumulated configuration and hardware age risk that having the old server available as an immediate fallback is worth the additional upfront migration effort.

How Encryption Consulting Can Help

Choosing between these two paths is a five-minute conversation once you know your environment; executing either one correctly, especially preserving CA identity during a side-by-side migration or validating a multi-hop in-place upgrade, is where most internal teams run into trouble, usually because it’s a project they run once every several years rather than something they do regularly.

Encryption Consulting’s PKI Services team helps organizations make this decision and execute it correctly:

Environment assessment against the six factors above, so the in-place vs. side-by-side decision is based on your actual CA hierarchy, hardware age, and OS jump distance, not a generic rule of thumb.
Side-by-side migration execution, including the CA private key export/import that determines whether identity is preserved correctly, with a verified thumbprint match before the migration is considered complete.
In-place upgrade planning and validation, including confirming your exact supported upgrade path and building a tested rollback mechanism before the first maintenance window.
Full dependency testing across templates, AIA/CDP, NDES/SCEP, RADIUS/NPS, and domain controller chain validation, so nothing silently breaks after cutover.
Documented rollback runbooks with defined go/no-go criteria, so a decision to proceed or revert is made with evidence in hand, not under pressure.

If you want a second opinion on which path fits your environment, or want PKI specialists to execute either path end to end, our PKI Services team can scope and run your ADCS upgrade or migration.

Conclusion

In-place upgrade and side-by-side migration are not a better-option-versus-worse-option choice; they’re two different risk and effort tradeoffs that fit different environments. In-place upgrade gives you automatic identity preservation and a simpler process, at the cost of concentrated risk and limited rollback options. Side-by-side migration gives you a genuine rollback safety net and freedom from OS-jump constraints, at the cost of more manual steps and a deliberate identity-preservation process that has to be executed correctly. Weigh the six factors above against your specific environment, decide before you schedule anything, and pair whichever path you choose with the detailed execution steps in our complete ADCS migration and modernization guide.

Not sure which path fits your environment? Talk to our PKI Services team about scoping your ADCS upgrade or migration. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

Is side-by-side migration always safer than an in-place upgrade? Not categorically. In-place upgrade concentrates risk into a single, well-understood event with automatic CA identity preservation, while side-by-side migration spreads risk across more steps that are individually recoverable but require more manual verification, particularly around AIA/CDP continuity and CA identity preservation. Side-by-side does offer a stronger rollback option, which is why it’s often the safer default for older or less certain environments.

Can I do an in-place upgrade directly from Windows Server 2012 R2 to 2025? According to Microsoft Learn, Windows Server 2025 supports direct in-place upgrades from 2012 R2, 2016, 2019, or 2022 on nonclustered systems. Confirm your exact source-to-target path against current Microsoft documentation before scheduling, since supported paths have changed across releases and earlier targets like 2022 typically cap at a two-version jump.

Does an in-place upgrade preserve my CA’s private key automatically? Yes. Since the OS upgrades underneath the existing CA role rather than replacing the server, the private key, database, and Common Name never move, so identity preservation is automatic with no export or import step required.

What is the biggest risk in a side-by-side ADCS migration? The two biggest risks are accidentally generating a new CA key during role installation instead of importing the existing one (which breaks the chain for every previously issued certificate), and failing to maintain AIA/CDP continuity for certificates issued before the cutover, which causes chain-building or revocation failures that can surface weeks or months later.

How much downtime should I plan for each approach? In-place upgrade typically requires a single bounded maintenance window of 30 to 90 minutes per OS version hop, plus validation time. Side-by-side migration can approach zero downtime if you build and validate the new CA fully before cutover, though the total elapsed project time is usually longer than an in-place upgrade.