diff --git a/docs/faq.md b/docs/faq.md
index bfc5ebda..629fdd96 100644
--- a/docs/faq.md
+++ b/docs/faq.md
@@ -10,6 +10,7 @@
 * [Why does Algo support only a single cipher suite?](#why-does-algo-support-only-a-single-cipher-suite)
 * [Why doesn't Algo support censorship circumvention?](#why-doesnt-algo-support-censorship-circumvention)
 * [I deployed an Algo server. Can you update it with new features?](#i-deployed-an-algo-server-can-you-update-it-with-new-features)
+* [Can I migrate my existing clients to a new Algo server?](#can-i-migrate-my-existing-clients-to-a-new-algo-server)
 * [Where did the name "Algo" come from?](#where-did-the-name-algo-come-from)
 * [Can DNS filtering be disabled?](#can-dns-filtering-be-disabled)
 * [Does Algo support zero logging?](#does-algo-support-zero-logging)
@@ -79,6 +80,12 @@ As a result, once your Algo server has been deployed, it is yours to maintain. I
 
 As an extension of this rationale, most configuration options (other than users) available in `config.cfg` can only be set at the time of initial deployment.
 
+## Can I migrate my existing clients to a new Algo server?
+
+Technically yes, but it's rarely worth the effort. WireGuard clients would need their server endpoint and public key updated. IPsec clients additionally require securely copying the CA certificate and potentially regenerating client certificates. Since your existing server auto-updates its VPN software via unattended-upgrades, there's usually no benefit to migrating—you already have the latest security patches for strongSwan, WireGuard, and dnscrypt-proxy.
+
+If you need features from a newer Algo release, deploy a fresh server and redistribute new client configs. This is simpler and more secure than attempting key migration.
+
 ## Where did the name "Algo" come from?
 
 Algo is short for "Al Gore", the **V**ice **P**resident of **N**etworks everywhere for [inventing the Internet](https://www.youtube.com/watch?v=BnFJ8cHAlco).