Yes — your saved Wi-Fi profiles will survive a clean reinstall. Copy the netplan definitions from /etc/netplan (plus any NetworkManager keyfiles from /etc/NetworkManager/system-connections) onto the new system at the same paths, make sure ownership and permissions are correct, then run sudo netplan apply so the imported definitions become known to NetworkManager.
Where your saved networks actually live
Ubuntu keeps network configuration in two layers, and knowing which holds what makes the migration obvious:
/etc/netplan/*.yaml— the declarative source files. Awifis:block withrenderer: NetworkManageris turned into live connection profiles each time netplan applies./etc/NetworkManager/system-connections/*.nmconnection— keyfiles written by NetworkManager itself, typically for networks you joined through the desktop applet. SSIDs, passwords and every per-connection setting live here./run/NetworkManager/system-connections/— runtime profiles generated by netplan. This directory is rebuilt on every apply, so treat it as read-only.
An install with "quite a few" saved networks may have entries in both persistent locations, so plan to back up both directories.
Back up the old system, then restore onto Kubuntu
On the 24.04 side
Do this from the old install (or a live USB with its disk mounted) before reformatting anything. The -a flag preserves ownership and permissions, which matter later:
sudo mkdir -p /mnt/usb/netplan /mnt/usb/nm
sudo cp -a /etc/netplan/. /mnt/usb/netplan/
sudo cp -a /etc/NetworkManager/system-connections/. /mnt/usb/nm/For a single-file record you can also run sudo netplan get and save the merged output. Keep the backup private — these files contain pre-shared keys in plain text.
On the fresh 26.04 side
Once Kubuntu is installed and booting, copy the files back, normalise permissions, and apply:
sudo cp -a /mnt/usb/netplan/. /etc/netplan/
sudo cp -a /mnt/usb/nm/. /etc/NetworkManager/system-connections/
sudo chown -R root:root /etc/netplan /etc/NetworkManager/system-connections
sudo chmod 600 /etc/netplan/*.yaml /etc/NetworkManager/system-connections/*
sudo netplan applyA fresh desktop install ships with its own small YAML file in /etc/netplan that simply sets renderer: NetworkManager. Leave it in place unless it conflicts with something you imported; your old files can sit alongside it. Then verify:
nmcli connection showEvery migrated SSID should appear in the list, and profiles marked autoconnect will join known networks without prompting.
When migrated profiles don't show up
- Permissions. Netplan complains about world-readable YAML files, and NetworkManager quietly ignores keyfiles that aren't root-owned with mode 600. The
chown/chmodstep above prevents both. - Renderer mismatch. YAML without
renderer: NetworkManageris handed to systemd-networkd instead, and those Wi-Fi networks never reach the desktop. Check each imported file. - Hardware binding. Profiles can be pinned to a MAC address or interface name. That's harmless on the same machine, but if you later move them to different hardware, delete the binding so the profile attaches to the new adapter.
- Duplicates. The same SSID defined both as YAML and as a keyfile produces two competing profiles. Keep one and delete the other.
- Apply errors.
sudo netplan --debug applynames the exact file and line that failed.
YAML or keyfiles: pick one route per network
Both restore paths work, but they trade off differently. Restoring the .yaml files and running netplan apply keeps everything in netplan's declarative format — tidy, centralised and easy to review — but its NetworkManager backend covers only common settings, so less usual options (some 802.1X parameters, for instance) may not round-trip. Restoring the .nmconnection keyfiles instead preserves every setting NetworkManager ever stored and needs no netplan involvement at all: sudo nmcli connection reload is enough. The drawback is that keyfile profiles are invisible to netplan, and describing the same network in both formats creates the duplicate-profile problem above. For ordinary home and office WPA networks either route is fine; for enterprise setups with certificates, prefer the keyfiles and make sure any certificate paths they reference still exist on the new system.
Make future reinstalls painless
Once the new install behaves, archive both directories to external storage so the next reinstall is a five-minute job:
sudo tar -czf wifi-backup.tar.gz -C / etc/netplan etc/NetworkManager/system-connectionsThe archive contains live passwords, so store it encrypted rather than on a bare USB stick.
Frequently Asked Questions
Are the saved passwords stored in plain text?
Yes. Pre-shared keys sit in clear text in both formats; root ownership and mode 600 are the only protection. Treat every copy of these directories as a secret.
I copied the YAML files over but nothing changed — why?
Netplan generates the NetworkManager profiles only when applied. Run sudo netplan apply, confirm each file sets renderer: NetworkManager, and check for parse or permission errors with sudo netplan --debug apply.
Can I skip netplan entirely and use only the old keyfiles?
Yes. Copy the .nmconnection files into /etc/NetworkManager/system-connections with root-only permissions and run sudo nmcli connection reload. This classic method works independently of netplan.
Why does one network appear twice after migration?
Because it exists in both a YAML file and a keyfile. Delete whichever definition you don't intend to maintain, then re-run netplan apply or nmcli connection reload.
Does this transfer VPN and wired profiles too?
Yes — VPN, DSL and Ethernet connections live in the same directories and migrate with the same copy-and-apply procedure.