To migrate a WireGuard server, prepare the new host without changing every client, move one device first, verify its actual path, and prove that you can return it to the old host. Keep endpoint changes, server identity changes, and retirement as separate decisions so a failed cutover has a recoverable boundary.

Key Takeaways:

Preserve a working console and the last trusted configuration on both hosts.

Move one client before the fleet; DNS changes do not force every client to re-resolve.

A tested rollback here is your acceptance requirement, not an author test claim.

What must you record before you migrate a WireGuard server?

This guide uses Ubuntu 24.04 LTS and native wg-quick@wg0, with one current server and one replacement. It was prepared from official documentation without a complete author end-to-end test. All verification outcomes below are expectations for your authorized environment. The self-hosting operations overview explains the broader ownership boundary.

You need sudo access, verified console access independent of the tunnel on both hosts, a maintenance window, protected backups, and a client you may temporarily disconnect. Do not use a production subnet you cannot administer or a shared host whose services you are not allowed to stop. This procedure does not authorize experiments on other people's endpoints.

Record old and new public endpoints and UDP ports, server public keys, tunnel addresses, client keys and AllowedIPs, internet or private-network destinations, DNS ownership, firewall ownership, and the server's outbound interface. Include IPv6 support, routing policy, client resolver behavior, and the old provider's resource inventory. Use an access-controlled record; neither private keys nor complete client profiles belong in a public ticket.

Before paying for overlapping hosts, compare continued VPS ownership with a managed exit service. If you still need control of your own keys or private routes, proceed with migration; changing that decision later does not cancel the old resources automatically.

Step 1: Prepare a WireGuard VPS migration boundary

Write the rollback trigger before changing traffic: for example, loss of administration, the canary failing its required application request, unexpected DNS routing, or an unapproved IPv6 path. Define a maximum observation window that fits your maintenance schedule and a named person who can operate both consoles. Do not substitute a universal wait time for this decision.

Back up the old server's reviewed configuration and revocation ledger in a protected location with unique names. Record its boot enablement and active state, plus the existing forwarding and firewall rules. A configuration file alone does not contain provider firewall policy, IP forwarding settings, or billing state.

Reconcile device identities before copying them. Use the peer inventory and revocation procedure to ensure that a backup does not contain a device removed later. Freeze peer edits during the cutover, or keep a single dated ledger that both hosts must consume before accepting traffic.

On the replacement, install the distribution WireGuard tools through your approved package process and recreate only the required path. Keep management access restricted, allow the intended UDP port, configure forwarding only if this host is a gateway, and scope return-routing or NAT to the intended tunnel range and outbound interface. Ubuntu's default-gateway guide documents those separate components. Do not copy another host's interface name or flush its firewall.［2］

Step 2: Choose whether server identity moves or rotates

Choice	Client change	Operational condition
New server identity	Update server public key and Endpoint on each migrated client	Old and new hosts can coexist with clearly separated identities
Preserve trusted identity	Keep server public key; change Endpoint	Transfer secrets securely and ensure only the intended host is active
Suspected server-key compromise	Rotate identity and any affected shared secrets	Never restore the compromised key as a rollback shortcut

Prefer a fresh server identity for the one-client parallel cutover described next. Generate its key pair on the new host with a restrictive umask, retain its private key there, and distribute only the public key. WireGuard authenticates peers through their keys; an address change does not itself create a new identity.［1］

If you deliberately preserve the old identity, transfer its private material only through an authenticated administrative channel with verified host keys and root-only destination permissions. Stop the old tunnel before starting the clone; this variant has a service interruption and cannot use the parallel two-identity canary unchanged. Reusing one identity on reachable hosts without clear ownership can make endpoint learning and diagnosis ambiguous.

Use the same tunnel subnet on independent servers only when their networks are genuinely isolated and each client activates one selected profile. Do not bridge both copies into the same routed domain. If you change the subnet, review every client address, route, ACL and DNS dependency rather than treating it as an Endpoint-only move.

Step 3: Build the new path without changing the fleet

Install the server configuration under /etc/wireguard/wg0.conf with root ownership and mode 0600. Carry only approved peer entries and replay all revocations. Leave SaveConfig absent or false for a file-managed setup; its shutdown behavior can overwrite edits. Keep DNS and hook dependencies appropriate to this host.［3］［4］

For the fresh-identity branch, start the replacement while leaving the old server available:

sudo systemctl start wg-quick@wg0
sudo systemctl is-active wg-quick@wg0
sudo wg show wg0 public-key
sudo wg show wg0 listen-port
sudo wg show wg0 peers

These commands run on the new host. Compare the public key and port against the migration record rather than inferring success from active. Do not display showconf or a dump that includes secret fields. Confirm the required tunnel address and the provider's inbound UDP rule through the relevant control plane.

If startup fails, stop here; leave clients on the old host and follow the boot and service checks. Establish the new host's own baseline before trying a fleet change.

Step 4: Perform a WireGuard endpoint migration on one client

Save the canary's last trusted profile locally and label the destination host on each profile. Update the canary's server public key for the fresh-identity branch, its Endpoint host and port, and a preshared key only if that pair uses one. Preserve the client private key unless you are intentionally rotating that device as a separate change.

Activate only one of the two profiles at a time. Otherwise overlapping client routes can invalidate the comparison. Generate traffic to an authorized tunnel service, then inspect the new server's handshake and counter changes for that exact client. Seeing a web page from the client's normal connection is not proof of tunnel use.

A domain Endpoint is resolved according to the client's implementation and lifecycle; changing its DNS record does not guarantee that a running tunnel immediately changes destination. Record the client and version, current resolved endpoint, and the documented reconnect or reactivation action needed to resolve again. Check Endpoint address and roaming behavior when planning that action. Do not keep cycling unrelated services to chase DNS caching.［1］［4］

Where possible, initially use the replacement's explicit endpoint in this authorized canary profile, then separately test the intended domain. If you use a DNS cutover, save the old record and TTL beforehand; rollback still requires confirming the client's actual endpoint, not merely restoring the record in a dashboard.

Step 5: What proves that the new path is usable?

Use an unchanged old-host client as a control while checking the canary. Record timestamps, profile identity, destination, expected result, and the host that observed the handshake. Do not record secret configuration values.

Check method	Expected observation	Failure action
Canary contacts a permitted tunnel address	New host sees fresh handshake and the service responds	Inspect identity, UDP path and application policy
Required internet application uses the full tunnel	Its selected traffic exits through the new host	Investigate routes, forwarding and NAT
Client resolves a required name	Intended resolver and response are used	Inspect client DNS hooks and resolver policy
IPv6 and a deliberate tunnel disconnect are checked	Behavior matches the declared routed, blocked or direct policy	Stop acceptance if traffic takes an unapproved path
Old-host control repeats its request	Original path remains available	Restore the independent rollback path first

For an internet-exit deployment, check the canary's current public IP from the browser that is meant to use the tunnel. A split tunnel may correctly leave that browser on its ordinary exit; document that expectation rather than declaring migration failure. An IPv4 observation does not prove DNS routing, IPv6 behavior, UDP support, or failure protection.

If the interface handshakes but application traffic fails, use the routing and forwarding diagnosis. Keep repairs limited to the failing layer. Do not rotate keys, change DNS and replace firewall rules simultaneously; that removes the evidence needed for rollback.

Step 6: Prove rollback, then retire the old server

Before moving the remaining devices, deliberately return the canary to its saved, still-trusted old profile within the authorized window. Deactivate the new profile, restore the old server key and Endpoint together, and apply the client's documented reactivation procedure. Confirm a new handshake on the old host and repeat its required application, DNS, IPv6 and disconnect checks. If the old identity is compromised, this is not a safe rollback option; build a trusted recovery path instead.

Move the canary forward again only after that recovery succeeds. If you chose identity preservation, rollback means stopping the replacement first, restoring the old host's current reviewed configuration and revocation ledger, then starting the old instance; never run both clones during recovery. Reverse only migration-specific firewall or DNS changes, and independently verify console access.

Migrate remaining devices in small groups, keeping a per-device record of the selected server key and actual endpoint. Observe the new path for your pre-agreed window and representative client reconnects. A lack of old-host traffic is supporting evidence, not proof that a sleeping device has migrated. Contact the responsible owners before declaring the fleet complete.

Enable the replacement at boot only once its configuration is accepted, then test an authorized reboot with console access. Keep the old rollback resources until the acceptance window closes. For retirement, stop and disable the old tunnel, revoke old-only credentials, remove migration-only firewall entries, and handle backups under your retention policy. Delete obsolete provider instances, disks, reserved addresses and snapshots through their own lifecycle controls; verify cancellation separately from powering off.

Summary

Freeze identities, routes and revocations before copying configuration.
Prove one client's new path and old-path recovery before fleet changes.
Retire infrastructure only after acceptance and resource-accounting checks.

FAQ

Must the server public key change during migration?

It changes when you choose a new server identity. A trusted preserved identity can retain its public key, but secret transfer and exclusive host ownership become essential.

Will a lower DNS TTL immediately move clients?

A lower TTL affects resolver caching, not every WireGuard client's running endpoint. Verify the actual destination and use the client's documented re-resolution behavior.

Can both servers use the same identity during a canary?

This guide uses distinct identities for parallel operation. For an intentional identity-preserving move, stop the old tunnel before starting the replacement.

Does a fresh handshake prove internet access works?

A handshake proves peer communication, not forwarding or resolver policy. Test the application path and the intended IP, DNS and IPv6 behavior separately.

Can the same client key appear on both hosts?

It may be provisioned on two isolated hosts during a controlled migration. Keep distinct server identities, one active client profile, and synchronized revocation records.

When can I delete the old virtual machine?

Wait until devices, rollback and the observation window meet your written acceptance criteria. Then check associated disks, addresses and snapshots separately for continuing charges.

What makes the rollback tested?

You actually return an authorized canary to the trusted old path and verify required behavior. This article provides the procedure without claiming the author performed that experiment.

Sources:

WireGuard — Quick Start — https://www.wireguard.com/quickstart/
Ubuntu — Using the VPN as the default gateway — https://ubuntu.com/server/docs/how-to/wireguard-vpn/vpn-as-the-default-gateway/
Ubuntu — Common tasks in WireGuard VPN — https://ubuntu.com/server/docs/how-to/wireguard-vpn/common-tasks/
Ubuntu Noble — wg-quick(8) — https://manpages.ubuntu.com/manpages/noble/man8/wg-quick.8.html

Sources checked 11 October 2026.

Related Articles:

Migrate a WireGuard Server With a Tested Rollback