CLM Migration Playbook: Move Platforms Without Outages

Moving to a new certificate lifecycle manager is mostly a migration of renewal responsibility: the certificates themselves stay where they are, but every automated renewal, every agent and every CA connection has to be handed from the old platform to the new one without a gap in which nothing renews. Organisations change certificate lifecycle management (CLM) platforms when they outgrow spreadsheet-era tooling, consolidate after a merger, move to a cloud service, or find that the old platform cannot keep up with shorter public certificate lifetimes. This playbook covers the migration itself: what has to move, how to sequence ownership of renewals, private keys, CA and ACME connections, the identities the platform uses, and how to decommission the old platform safely. It is vendor-neutral and based on NIST SP 1800-16, the CA/Browser Forum Baseline Requirements and the ACME RFCs. The lifecycle itself is covered in the Machine Identity, PKI and Certificate Lifecycle Guide, and choosing a platform in the Certificate Lifecycle Management RFP Template.

Key takeaways

Exactly one owner per renewal. At every point in the migration each certificate must be renewed by exactly one platform. Two owners cause duplicate issuance and conflicting deployments; zero owners cause outages.
Inventory is the first deliverable, not a by-product. Export and reconcile the old platform's inventory against fresh discovery before moving anything; the old inventory is usually incomplete.
Do not move private keys you do not have to. Let the new platform renew with fresh key pairs and take over at the next renewal, rather than exporting keys from the old system.
Shorter lifetimes shrink your window. Public TLS certificates issued from 15 March 2026 are capped at 200 days, falling to 100 days in 2027 and 47 days in 2029, so the migration must finish inside fewer renewal cycles.
The CLM platform is a privileged non-human identity. It holds CA credentials, ACME account keys and deployment credentials for many servers; rotate or revoke every one of them when the old platform retires.

What a CLM migration actually moves

Object	Migration approach	Watch for
Certificate inventory and metadata	Export, then reconcile with new discovery scans of networks, cloud accounts, load balancers and CT logs	Owner, application and environment fields that never existed in the old tool
Ownership and notification groups	Map to functional groups, not named people	Expiry alerts routed to staff who have left
Issuance policies and templates	Translate by intent: allowed CAs, key types and sizes, validity, approval rules	Legacy templates still allowing weak keys or long internal validity
Public CA connections	New API or ACME accounts for the new platform; keep the old ones until cutover	Organisation and domain validation data tied to the old account
Internal CA connections	New enrolment credentials or connector for the new platform	Connector service accounts with CA manager rights
ACME accounts and external account binding keys	Create new accounts and new EAB keys; never copy account keys	Old account keys left valid after decommissioning
Deployment automation and agents	Replace per target class: web servers, load balancers, ingress controllers, appliances, cloud services	Hand-built scripts that call the old platform's API
Private keys held by the platform	Prefer re-key at next renewal; export only with a documented reason	Key escrow features that put many keys in one store
Audit history and issuance records	Archive for its retention period	Evidence for audits and incident investigations lost with the old platform

NIST SP 1800-16 Volume B recommends a single central inventory of all TLS server certificates and CA chain certificates, including those on backup systems, recording expiry, issuing CA, key type, install locations, owner and business application. Use that list of fields as the target schema for the new platform, and treat any certificate that cannot be given an owner as a migration blocker. The Certificate Inventory Register Template gives a usable field set.

Handover models for renewal ownership

Model	How it works	Choose it when	Trade-off
Renew-to-migrate	New platform issues a fresh certificate with a new key at each certificate's next renewal and becomes owner from then on	Default for most estates, especially as lifetimes shorten	Migration takes one full renewal cycle; two platforms run in parallel
Wave cutover	Move ownership by application, environment or target class on a scheduled date, renewing early where needed	Large estates with clear application ownership	Early renewals cost issuance volume and change windows
Monitor-first	New platform discovers and alerts only; old platform keeps renewing until each class is automated in the new one	Old platform is stable but the new one lacks some integrations	Longest period with two sources of truth
Big-bang re-issue	Replace every certificate from the new platform in a short window	Suspected compromise of the old platform or its keys, or a forced CA change	High outage risk; needs tested automation for every target

Renew-to-migrate is usually the safest because it avoids moving private keys and uses a change that has to happen anyway. Big-bang re-issue is an incident response move, not a migration plan; if that is the trigger, use the CA Compromise and Mass Certificate Replacement Playbook and the If your certificate lifecycle manager is compromised playbook instead.

Timing against shorter lifetimes

The CA/Browser Forum Baseline Requirements (section 6.3.2, version 2.3.1) set the maximum validity of publicly trusted TLS subscriber certificates at 398 days for certificates issued before 15 March 2026, 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Ballot SC-081v3, which introduced the schedule, also cuts the reuse period for domain validation data to 10 days by 2029. Two practical consequences for a migration:

Renew-to-migrate finishes faster: with 200-day certificates, every public certificate passes through a renewal inside about seven months, so the parallel run is bounded.
Manual steps do not survive: a target class that the new platform cannot renew automatically will become a recurring manual task several times a year. Migrate it to automation, do not carry it over as a ticket. The wider impact is in the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

Private keys, ACME and CA connections

Re-key, do not export: renewing with a new key pair generated on the target host, or in the new platform's protected store, avoids a bulk key export. NIST SP 1800-16 recommends limiting access to plaintext private keys to authorised, trained staff and holding keys for mission-critical systems in a hardware security module. An export of hundreds of keys from one platform to another breaks both principles at once.
If keys must move: for keys in HSMs or pinned deployments, move them wrapped, inside validated modules, with dual control, and log every step. Then plan to re-key them at the next renewal anyway.
New ACME accounts: RFC 8555 identifies an ACME client by its account key pair and lets a CA bind that account to an existing customer record through external account binding (a MAC key and key identifier issued out of band). Give the new platform its own account and EAB credentials; do not copy the old account key. The ACME mechanics are in the ACME and Automated Certificate Management Guide.
Use renewal information where offered: RFC 9773 (ACME Renewal Information, June 2025) lets a CA publish a suggested renewal window per certificate, and lets the client name the certificate it is replacing with the replaces field. Platforms that support it handle CA-driven early renewals, such as a mass revocation, without a ticket queue.
Validation follows the domain, not the platform: confirm the new platform can complete http-01 or dns-01 challenges for every domain. DNS credentials used for dns-01 are powerful; scope them to the validation records where your DNS provider allows it.
Keep two CAs available: NIST SP 1800-16 recommends contracts with at least two public CAs and backup internal CAs. A platform migration is a good moment to prove the new platform can issue from both.

Where identity fits

A CLM platform is one of the most privileged non-human identities in the estate. It authenticates to CAs, DNS providers, cloud accounts, load balancers and servers, and in many designs it can obtain or deploy a trusted certificate for any internal name.

Inventory the platform's own credentials: CA API keys and enrolment certificates, ACME account keys, EAB keys, DNS API tokens, cloud roles, SSH keys and service accounts used by agents and connectors.
Issue new credentials for the new platform: never reuse the old platform's service accounts. Federate cloud access rather than storing static keys, and scope each connector to its target class (NIST SP 800-53 AC-6, least privilege; IA-5, authenticator management).
Separate administration from issuance: the people who change policies and CA connections should not be able to approve their own certificate requests (AC-5, separation of duties).
Revoke everything at decommissioning: disable the old ACME accounts, delete EAB keys, revoke connector certificates, remove DNS tokens and cloud roles, and remove agents from servers.

Hardening the new platform is in Securing the certificate lifecycle manager, and its connector credentials in the Certificate lifecycle manager integration security guide.

The phased playbook

Freeze and inventory: pause new integrations on the old platform. Export its inventory, then run discovery from the new platform across networks, cloud accounts and CT logs, and reconcile. Record per certificate: owner group, application, target class, issuing CA, key type, expiry and current renewal method.
Classify target classes: group certificates by how they are deployed (ACME-capable servers, load balancers, ingress controllers, cloud certificate services, appliances, code or device certificates). Each class needs a tested automation path in the new platform before it moves.
Build policy and connections: recreate issuance policies by intent, connect public and internal CAs with new credentials, and set up owner groups and notification routes.
Pilot one class end to end: issue, deploy, renew and revoke a test certificate in each class, including a renewal on a real low-risk service. Confirm the old platform no longer tries to renew it.
Transfer ownership in waves: for each wave, switch renewal off in the old platform and on in the new platform in the same change, and record the switch in both. Do waves in order of rising criticality.
Run in parallel with expiry monitoring: keep the old platform in read-only or monitor mode, and run independent expiry monitoring that does not depend on either platform until migration ends.
Handle the stragglers: certificates with no owner, appliances without automation and long-lived internal certificates. Assign, automate or schedule each one; do not leave them to the old platform.
Decommission: archive audit history, revoke the old platform's credentials, remove its agents, and sanitise any key stores it held following NIST SP 800-88.

Rollback: until decommissioning, rollback for a wave means switching renewal back on in the old platform for those certificates and off in the new one. Certificates issued by the new platform remain valid, so rollback does not need re-issue. Keep the old platform's CA connections live until the last wave has passed one renewal. Small organisations with a few hundred certificates and one or two CAs can often migrate in a single renew-to-migrate cycle; large estates need waves, owner sign-off per application and a dedicated straggler list.

Detection and measurement

Metric or signal	Why it matters	Target (our recommendation)
Certificates with exactly one renewal owner	Core migration control	100% at every point
Certificates found by discovery but missing from the inventory	Gaps in the old platform's view	Falling to zero before decommissioning
Certificates expiring within 30 days without a scheduled renewal	Early warning of an outage	Zero
Issuance from the old platform's CA accounts after cutover	Old platform or a script still renewing	Zero; alert on any
Duplicate certificates for the same name issued in the same week	Two platforms renewing the same certificate	Zero unexplained
Share of certificates renewed automatically	Readiness for shorter lifetimes	Rising each wave; manual renewals justified in writing

Certificate Transparency logs record every publicly trusted certificate, so monitoring CT for your domains during the migration catches issuance by either platform or by anyone else. See the Certificate Transparency Monitoring Guide for Web Teams. NIST SP 1800-16 notes that expired intermediate CA certificates also cause outages and are hard to diagnose, so include chain certificates in expiry monitoring.

Common failure patterns

Two platforms renewing the same certificate: the new platform deploys a certificate, then the old platform overwrites it with its own renewal, or the reverse, causing flapping and rate limit hits.
Nobody renewing: renewal is switched off in the old platform before the new one has a working deployment path for that target class.
Bulk key export: every private key exported to a file share or migration host "for convenience", creating a single store worth more than either platform.
Forgotten scripts: cron jobs and pipeline steps calling the old platform's API stop working silently at decommissioning.
Orphaned credentials: old ACME accounts, EAB keys, DNS tokens and connector service accounts left valid after the platform is switched off.
Chain and trust store drift: the new platform issues from a different intermediate or internal CA that some clients do not trust. See the Certificate trust stores and root CA management guide.

Framework mapping

Activity	NIST SP 800-53 Rev 5	NIST CSF 2.0
Certificate inventory and ownership	CM-8	ID.AM-02, ID.AM-08
Issuance policy and approved CAs	SC-17	PR.AA-01
Private key generation and protection	SC-12	PR.DS-01
Platform and connector credentials	IA-5, AC-6, AC-5	PR.AA-05
Migration change control	CM-3	PR.PS-01
Issuance logging and retention	AU-2, AU-11	DE.CM-09

Practitioner checklist

Reconcile the old inventory with fresh discovery and CT logs before moving anything.
Give every certificate an owner group, application and target class.
Choose a handover model; default to renew-to-migrate with new key pairs.
Prove automation for each target class in a pilot before its wave.
Switch renewal off in the old platform and on in the new one in the same change.
Run independent expiry monitoring, including intermediates, for the whole migration.
Create new ACME accounts, EAB keys and connector credentials; never copy the old ones.
Keep at least two CAs usable from the new platform.
Revoke all old platform credentials and remove agents at decommissioning.
Archive issuance and audit history for its retention period.

Certificate lifecycle manager migration playbook: move certificates and automation without outages