Migrating an existing certificate to a new server — during a hosting migration, for example — means transferring the certificate, private key, and CA bundle securely, then reconfiguring the new server to use them.
What you need
- The certificate file itself
- The matching private key — without this, the certificate can't be used on the new server at all
- The CA intermediate bundle, if your new server's configuration doesn't already have it cached
Transferring securely
Never transfer a private key over an unencrypted channel — use SCP/SFTP, a secrets manager, or an encrypted archive, rather than email or unencrypted file transfer. If the old server is being decommissioned entirely, securely delete the private key from it afterward rather than leaving a copy on infrastructure you no longer control.
Alternative: just reissue
If you're using a free, automated CA like Let's Encrypt, it's often simpler to just issue a fresh certificate on the new server via ACME rather than migrating the old one — avoiding the private key transfer question entirely, at the cost of the new certificate having a different key pair than the old one.
What to do if the certificate works on the old server but not the new one
A certificate failing only on the new server despite working on the old one typically points to a missing intermediate bundle, an incorrectly copied private key, or a mismatch between the certificate and the new server's configured hostname — checking each of these individually usually isolates the specific gap.
How to minimize downtime during the actual cutover between servers
Lowering your DNS record's TTL well before the planned cutover, then updating DNS to point to the new server only once it's fully tested and ready, minimizes the window during which some visitors might still be routed to the old server during the transition.
What DNS TTL considerations matter before starting a server migration
Lowering your DNS TTL well in advance of a planned migration, giving cached DNS records time to expire everywhere before the actual cutover, minimizes how long any visitor might be routed to the wrong server during the transition based on stale cached DNS.
How to run both old and new servers in parallel during a migration for safer testing
Standing up the new server alongside the still-active old one, accessible via a temporary alternate hostname or direct IP, lets you thoroughly test the new server's configuration before in practice cutting over DNS — a safer approach than making the new server the sole production target before it's been fully verified.
Why keeping the old server available briefly after cutover provides a rollback safety net
Keeping the old server running and accessible for a short period after cutover, rather than immediately decommissioning it, provides a fast rollback option if an unexpected issue surfaces on the new server that wasn't caught during pre-migration testing.
What to do if the new server needs a different certificate format than the old one used
If your new server software expects a different format than what you have (PEM versus PFX, for instance), converting using the techniques covered in our dedicated format conversion guide is a normal, expected part of a cross-platform server migration rather than an indication of any problem.
How to verify the migration succeeded from an external, independent perspective
Testing your migrated certificate from an external SSL scan tool, run from infrastructure entirely independent of your own network, confirms the new server is correctly reachable and properly configured from a genuinely external vantage point rather than only from your own, possibly biased, local testing.
Make server migrations routine, not risky
With the checklist approach covered throughout this guide, certificate migration during a server transition is a routine, well-understood process rather than something to fear — the specific steps (matching format, complete chain, correct hostname) rarely change regardless of which specific platforms are involved.
Loading comments…