Your Guide To PKI Migration

Most PKI migrations do not fail because of cryptography. They fail because someone forgot a dependent application, skipped a rollback plan, or ran out of time before a root certificate expired mid-migration. CyberArk’s 2025 State of Machine Identity Security Report found that over 70% of organizations had at least one certificate-related outage in the past year, and the CA/Browser Forum’s certificate lifetime reductions are about to make that problem worse for anyone still running migrations on manual processes.

This guide walks through what a PKI migration actually involves, how to prepare for one, which of the four common migration strategies fits your situation, the pitfalls that derail most projects, and how automation changes the math.

Key Takeaways

• PKI migration moves certificate authorities, keys, and certificates to a new environment while preserving the chain of trust; a broken root or intermediate certificate during migration can take down every application that depends on it.
• As of March 15, 2026, publicly trusted TLS certificates are capped at 200 days under CA/Browser Forum Ballot SC-081v3, dropping to 100 days in 2027 and 47 days in 2029, which makes manual migration processes untenable for public-facing certificates.
• There are four migration strategies: lift-and-shift, rehosting, infrastructure upgrade, and system redesign. Each trades off speed against how much of the legacy environment you actually fix.
• A complete certificate and CA inventory, a documented rollback plan, and phased execution are the three controls that most reliably prevent migration outages.
• Organizations run an average of 9 different PKI and CA solutions, with 37% running more than 10, according to Keyfactor’s State of Machine Identity report, which is why inventory work is usually the longest phase of any migration.

Public key infrastructure secures and authenticates traffic between clients and servers, most visibly through SSL/TLS. When a client connects to a server, it checks the server’s certificate against a trusted certificate authority (CA) before encrypting anything. That trust relationship is exactly what a PKI migration puts at risk if it is handled carelessly: move or reissue a CA without preserving the chain of trust, and every certificate under it can stop validating at once.

That is why PKI migrations get planned in phases rather than executed as a single cutover, and why the inventory phase below is worth the time it takes.

What PKI Migration Involves

A PKI migration moves four categories of components: certificate authorities, registration authorities, digital certificates, and the keys that back them, along with every system configured to trust or depend on them.

The Core Components You’re Migrating

Certificate Authority (CA): The trust anchor of the PKI. A CA issues digital certificates, maintains certificate revocation lists (CRLs), and vouches for the identity of every entity holding a certificate under it. Every device or application that trusts the CA transitively trusts everything the CA signs, which is why CA migration carries the highest risk of any step.

Registration Authority (RA): The intermediary that receives and vets certificate signing requests (CSRs) before forwarding approved requests to the CA. RAs are usually kept separate from the CA for security and access-control reasons, and this is where most organizations enforce business rules about who can request what type of certificate.

Digital Certificates: Signed documents that bind a public key to an identity, whether that is a Fully Qualified Domain Name (FQDN), an IP address, a user, or a device. The certificate’s subject field is what applications actually check during authentication, so subject and Subject Alternative Name (SAN) values have to migrate cleanly or validation breaks.

Hardware Security Module (HSM): HSMs generate and store the private keys behind every CA and, often, high-value end-entity certificates, inside tamper-resistant hardware. A PKI is only as trustworthy as the key protection underneath it, which makes HSM migration (moving key material between vendors or hardware generations) one of the more sensitive sub-projects inside a larger PKI migration.

Directory Services: Central repositories, such as Active Directory Certificate Services (AD CS), that store identity and access information and often issue certificates directly to domain-joined devices and users. AD CS has been a Windows Server role since 2008 and remains the most common private CA in enterprise environments, which is why so many PKI migrations are really AD CS migrations.

The Four Migration Phases

Whether you’re running a certificate lifecycle management (CLM) platform or managing everything by hand, every PKI migration works through the same four phases:

1. Build the inventory. Catalog every certificate, CA, and key in the current environment.
2. Transfer the trust material. Move certificates, CAs, and key material to the new infrastructure.
3. Reconfigure dependent systems. Point every application, server, and service at the new PKI.
4. Test and monitor. Validate the new setup and watch it under real traffic before decommissioning the old one.

A CLM platform like CertSecure Manager shortens phase one significantly, since an accurate, continuously updated inventory already exists rather than needing to be built from scratch. Without one, inventory work alone can consume weeks, and any certificate missed at this stage becomes an outage risk later.

Elements to Consider Before You Migrate

Current Inventory

You cannot migrate what you have not counted. A complete inventory covers three certificate tiers plus everything that depends on them:

• Root certificates are the PKI’s fundamental trust anchors. If a root certificate expires or is mishandled mid-migration, the entire trust chain beneath it breaks.
• Intermediate certificates sit between the root and end-entity certificates, delegating trust downward.
• End-entity certificates are issued to the users, servers, applications, and devices that actually rely on them for authentication and encryption. These are the certificates most likely to cause a visible outage if they expire or are revoked during migration.

Dependent systems matter just as much as the certificates themselves. Network Device Enrollment Service (NDES) and mobile device management platforms like Intune often issue device certificates in bulk, and each of those integration points has to be identified and reconfigured, not just the certificates themselves. A missed dependency is the single most common cause of a post-migration outage.

Compatibility and Standards

The new PKI environment has to work with what you already have running, not just with what you’re planning to run next year. Some legacy applications still don’t support elliptic curve cryptography (ECC) or newer key lengths, and forcing an upgrade without checking compatibility first can quietly break authentication for systems nobody remembered were still using the old CA.

Test every dependency against the new environment before cutover, not after. A compatibility failure discovered during testing is a delay; the same failure discovered in production is an outage.

Automation and Scalability

Manually tracking hundreds or thousands of certificates was never sustainable, and it is becoming less so every year. Keyfactor’s State of Machine Identity research found that organizations run an average of nine different PKI and certificate authority solutions, with 37% running more than ten, which is exactly the kind of sprawl that makes manual certificate tracking unworkable during a migration.

Three automation components matter most during and after a migration:

• Proactive alerts that notify certificate owners before expiration, not after.
• Renewal triggers that kick off automatically as expiration approaches, rather than depending on someone remembering a spreadsheet.
• API integration that lets a CLM platform push renewed certificates directly into dependent systems without manual redeployment.

This matters more now than it did even two years ago. Under CA/Browser Forum Ballot SC-081v3, publicly trusted TLS certificate validity dropped to a 200-day maximum as of March 15, 2026, is scheduled to fall to 100 days in March 2027, and will reach 47 days by March 2029. A migration plan built around annual renewal cycles is already out of date; anything you migrate to should assume renewal every few months, not once a year.

Preparing for PKI Migration

A migration plan needs clear ownership of each of these areas before work starts, not after the first outage forces the question.

• Inventory of certificates and CAs. List every root, intermediate, and end-entity certificate, along with location, owner, and expiry date.
• Policy documentation. Record every issuance, revocation, and renewal policy currently enforced, so the new environment can replicate them rather than silently loosening controls.
• Trust relationships and dependencies. Identify every system, application, and service that authenticates or encrypts using the current PKI.
• Risk analysis. Assess where the migration is most likely to cause service disruption, and rank those risks by business impact.
• Rollback planning. Document exactly how to restore the old certificates and configurations if the migration fails partway through. This is the control most often skipped, and the one most often needed.
• Backup and redundancy. Back up certificates, keys, and configurations before, during, and after migration, and avoid single points of failure in the new architecture.

The Four PKI Migration Strategies

Which strategy fits depends on how outdated the current PKI is, what the business actually needs from the move, and how much disruption is acceptable. The table below compares all four; the sections after it go into the detail for each.

Strategy	What Changes	Best For	Relative Complexity
Lift-and-Shift	Location only; PKI is replicated as-is	A modern, stable PKI that just needs to move (e.g., to the cloud)	Lowest
Rehosting	Location plus targeted improvements (scalability, security, performance)	A functional PKI that needs modernization without a full policy rewrite	Low to Moderate
Infrastructure Upgrade	Underlying platform, while keeping existing keys and certificates	Outdated technology with a still-valid certificate inventory	Moderate to High
System Redesign	Everything: new CA hierarchy, new keys, new certificates for every endpoint	A PKI that is compromised, obsolete, or non-compliant with current standards	Highest

1. Lift-and-Shift

The existing PKI moves to a new environment, such as a new data center or cloud platform, with minimal changes to its structure or policies. This works well when the current PKI is modern and stable but sitting in the wrong place. It does not work for migrating legacy infrastructure, since it carries every existing flaw straight into the new environment.

Benefits: minimal disruption to ongoing operations; the fastest of the four strategies.

2. Rehosting

Rehosting relocates the PKI while also making targeted improvements, such as moving to a cloud-based solution, upgrading server hardware, or hardening security controls. Use this when the current PKI works but needs better scalability, security, or performance, and you want to keep the existing policy structure largely intact.

Benefits: improves scalability, security, or performance without a full policy rewrite; minimal disruption to existing structure.

3. Infrastructure Upgrade

This strategy replaces the underlying PKI platform while retaining existing cryptographic objects, meaning the keys and certificates already issued stay valid and usable. It fits organizations where the technology is outdated but the certificate inventory itself is still sound, and it’s the strategy most often used when moving from an antiquated platform to a current, compliant one.

Trade-off: requires real compatibility testing between the legacy and new infrastructure, making it more involved than a straight transfer.

4. System Redesign

A full redesign starts from new cryptographic keys and ends with a new CA hierarchy; every endpoint gets a fresh trust anchor, new keys, and new certificates. This is the right call when the current PKI is compromised, badly outdated, or fundamentally out of step with current standards, and no amount of patching will fix it.

Trade-off: the most complex, costly, and time-consuming of the four strategies, and the one most dependent on careful planning to avoid extended downtime.

Decision Tree: Which PKI Migration Strategy Should You Use?

• If your current PKI is modern, stable, and just needs to move locations: use Lift-and-Shift.
• If your PKI works but needs better scalability, security, or performance without a full policy rewrite: use Rehosting.
• If your platform is outdated but your certificate inventory is still valid and compliant: use an Infrastructure Upgrade.
• If your PKI is compromised, badly outdated, or non-compliant with current standards: use a full System Redesign.

Selection Criteria: Choosing Your PKI Migration Strategy

Weigh these criteria alongside the decision tree above before committing to a strategy:

• Current PKI health: is it modern and stable, or outdated and non-compliant?
• Certificate inventory validity: are existing keys and certificates still trustworthy, or do they need reissuing?
• Downtime tolerance: how much disruption can the business accept during cutover?
• Dependent system count: how many applications, devices, and services trust the current PKI?
• Compliance requirements: does the target environment need to meet standards the current one doesn’t?
• Available skilled resources: can your team execute a full redesign, or is a lighter-touch strategy more realistic given staffing?

Pros and Cons of Each PKI Migration Strategy

Strategy	Pros	Cons
Lift-and-Shift	Fastest option; minimal disruption to ongoing operations	Carries every existing flaw of the legacy PKI into the new environment
Rehosting	Improves scalability, security, or performance without a full policy rewrite	Still requires targeted infrastructure and security work beyond a straight transfer
Infrastructure Upgrade	Keeps existing keys and certificates valid, avoiding a full reissuance	Requires real compatibility testing between legacy and new infrastructure
System Redesign	Fixes a compromised, outdated, or non-compliant PKI at the root	Most complex, costly, and time-consuming of the four strategies; highest risk of extended downtime

Common Pitfalls in PKI Migration

Underestimating the Scope

PKI migrations touch every system that trusts the PKI, not just the certificates themselves. Organizations that plan only for moving certificates, without accounting for key management systems, directory service integrations, VPNs, and internal applications, consistently run into outages caused by dependencies nobody mapped ahead of time.

Data Loss and Unplanned Downtime

Skipping backups before migration risks losing certificates, keys, and logs if something goes wrong mid-process. Skipping adequate testing risks downtime that disrupts business operations. And skipping compatibility checks against existing hardware security modules (HSMs) and applications risks both at once.

Security Gaps During and After Migration

Misconfigurations and forgotten settings are a common source of new vulnerabilities introduced by migration itself, not by the systems being migrated. Certificates that go unrenewed during the process, or key rollovers that get deferred until “after the migration settles down,” weaken the security posture at exactly the moment it needs to be strongest.

Chain-of-Trust Breaks

Corrupted certificate, key, or CRL data during transfer can cascade into broken services well beyond the PKI itself. Any disruption to the chain of trust during migration can invalidate downstream certificates, which is exactly the outage scenario that a rollback plan exists to prevent.

Best Practices for PKI Migration

1. Audit and plan first. Run a full audit of the existing PKI, document every dependency, and build a detailed migration plan before touching production.
2. Migrate in phases. Phased migration reduces blast radius and gives the team time to catch and fix problems before they compound.
3. Test in a non-production environment. Simulate the migration in a test environment first to surface compatibility and configuration issues before they hit production.
4. Back up before every phase. Regularly back up certificates, keys, and configurations, and keep a recovery plan ready in case any phase fails.

Our Take: Where Migrations Actually Go Wrong

In our advisory engagements, the migrations that run into trouble almost never fail on cryptography. They fail on inventory. Teams that skip a proper certificate and dependency audit consistently discover, mid-migration, an application or device they forgot existed, and that discovery usually happens during a production outage rather than during planning.

The second most common failure point is rollback planning, or the lack of it. Organizations plan the forward path carefully and treat the rollback plan as an afterthought, right up until they need it at 2 a.m. with a broken chain of trust and no clean way back. Given that certificate lifetimes are compressing under the CA/Browser Forum’s 200-day cap (heading to 47 days by 2029), the number of renewal events during any given migration is only going up, which makes both of these gaps more expensive to leave unaddressed than they were even a year or two ago.

How Encryption Consulting Can Help

Encryption Consulting designs and migrates PKI infrastructures aligned to each organization’s specific security and compliance requirements, backed by hands-on PKI advisory and services experience across every migration strategy above.

For organizations that want to reduce PKI migration risk directly, CertSecure Manager, EC’s certificate lifecycle management platform, now on version 3.3, includes:

• One-click public CA migration that moves certificates between public certificate authorities without re-running enrollment from scratch.
• Expanded discovery across AWS, IIS Central Certificate Store, containers, and vaults, closing the inventory blind spots that cause missed-certificate outages during migration.
• Certificate trust chain visualization, so administrators can view and download the full chain relationship directly in the UI, which shortens investigation time if a chain-of-trust issue surfaces mid-migration.
• Bulk revocation and bulk ownership transfer, reducing manual effort when certificate ownership changes as part of an organizational or infrastructure move.
• End-to-end renewal automation that keeps pace with the CA/Browser Forum’s shrinking validity windows, so no certificate expires mid-migration for lack of a manual renewal step.

With PKI-as-a-Service, organizations can also hand off the operational burden of running the target environment entirely, rather than migrating onto infrastructure they then have to staff and maintain themselves.

Frequently Asked Questions

What is PKI migration?
PKI migration is the process of moving a public key infrastructure’s certificate authorities, keys, and certificates from one environment to another, such as an on-premises data center to the cloud, while preserving the chain of trust that existing certificates depend on.

How long does a PKI migration take?
Timelines vary widely with scope. A lift-and-shift of a well-documented PKI can take weeks; a full system redesign across a large, poorly inventoried enterprise environment can take many months, with inventory and dependency mapping typically consuming the largest share of that time.

What is the biggest risk during a PKI migration?
Breaking the chain of trust, usually by mishandling a root or intermediate certificate, or by missing a dependent system during inventory. Either one can cause certificates across the environment to stop validating at once.

Which PKI migration strategy should I use?
Use lift-and-shift if the current PKI is modern and just needs relocating, rehosting if it needs targeted improvements, an infrastructure upgrade if the platform is outdated but the certificate inventory is still valid, and a full system redesign if the PKI is compromised or non-compliant with current standards.

Do I need a certificate lifecycle management (CLM) solution to migrate a PKI?
No, but it changes the effort involved substantially. Without a CLM platform, teams have to build a certificate and CA inventory from scratch by hand. A CLM solution maintains that inventory continuously, which removes the largest and riskiest manual step in the process.

How does the CA/Browser Forum’s shorter certificate validity affect PKI migration?
As of March 15, 2026, publicly trusted TLS certificates are capped at 200 days under Ballot SC-081v3, falling to 100 days in 2027 and 47 days in 2029. Migrations that assume annual renewal cycles are already outdated. Any PKI migration plan for public-facing certificates now needs automated renewal built in, not added later.

Can I migrate a PKI without downtime?
Zero downtime is achievable for most migrations with careful phasing, redundancy during the transition, and a tested rollback plan, but it requires more planning time upfront than a single-cutover approach. Rushed migrations are far more likely to cause the outages a phased approach is designed to avoid.

What’s the difference between rehosting and an infrastructure upgrade?
Rehosting relocates the PKI and makes targeted improvements while keeping most existing policies intact. An infrastructure upgrade replaces the underlying platform entirely but preserves existing keys and certificates. Rehosting is the lighter-touch option; an infrastructure upgrade is a bigger technology change with a smaller policy change.

What happens if a root certificate expires during migration?
Every certificate issued under that root stops validating, causing a simultaneous, organization-wide outage across every application and service that depends on the chain. This is why root certificate handling gets the most scrutiny in migration planning, and why rollback plans exist specifically to reverse this scenario quickly.

How does AD CS factor into PKI migration?
Active Directory Certificate Services (AD CS) is the most common private CA in enterprise environments, so many PKI migrations are effectively AD CS migrations. Because AD CS issues certificates directly to domain-joined devices and users, migrating it requires careful coordination with Active Directory itself, not just the certificate store.

Conclusion

PKI migration is complex, but the complexity is manageable with the right preparation: a complete inventory, a strategy matched to the actual state of the current environment, a tested rollback plan, and automation covering renewals so shrinking certificate lifetimes don’t turn every migration into a race against expiration dates.

A successful migration does more than move infrastructure. It resolves the compliance gaps and technical debt that made the migration necessary in the first place, and it leaves the organization better positioned for the certificate lifetimes and cryptographic standards coming next.