
Coming from LXD and moving to Incus? The lxd-to-incus tool migrates the whole install in place: instances, images, profiles, networks and storage. This guide covers the prerequisites, the procedure, the version window in which the tool still exists, and above all the concrete traps reported from the field (LXD version, trust password, DNS suffix change, downtime) that make an unprepared migration fail. For LXD administrators making the switch.
What you will learn
- The prerequisites before launching the migration.
- Which Incus releases still ship the tool.
- The
lxd-to-incusprocedure. - The touch-ups after the switch (groups, CLI config, DNS).
Choose your Incus release first
Before anything else, one point decides the rest: lxd-to-incus was removed from the Incus development branch on 4 June 2026. Checked release by release, it is present in the LTS branches and the early 7.x feature releases, and gone from 7.2 onwards.
| Release | lxd-to-incus |
|---|---|
| 6.0.6 LTS | present |
| 7.0.1 LTS | present |
| 7.1.0 | present |
| 7.2.0 | absent |
| 7.4.0 | absent |
The official Incus migration documentation reflects the same move: it now describes only transfers between Incus servers, incus-migrate for physical or virtual machines, and lxc-to-incus for LXC. There is no LXD path left in it.
Prerequisites
-
Incus installed but NOT initialised: do not run
incus admin init. The tool copies the data and configuration from LXD itself; it only needs the Incus service to be started. -
An LXD version at
5.21.99or below: beyond that,lxd-to-incusrefuses to migrate. -
If your pools use ZFS, the
zfsutils-linuxpackage has to be installed, a classic with the LXD snap. -
core.trust_passwordunset on the LXD side, otherwise the connection fails:Fenêtre de terminal lxc config unset core.trust_password
The procedure
A first trap before you even start: the lxd-to-incus tool is not in the incus package. On the Zabbly repositories it ships in the incus-extra package. Without it, the command returns lxd-to-incus: command not found even though Incus is installed:
sudo apt install incus-extrawhich lxd-to-incus # /usr/bin/lxd-to-incusOnce the prerequisites are met, the migration is one command:
sudo lxd-to-incusThe tool analyses the LXD install, checks compatibility, then copies the data across to Incus. It handles clustered LXD installs as well. At the end, LXD is disabled in favour of Incus. Here is the real output of a migration from LXD 5.0.2 to Incus 7.0.0, with one webapp instance to move:
=> Looking for source server==> Detected: .deb package=> Looking for target server==> Detected: systemd=> Checking server versions==> Source version: 5.0.2==> Target version: 7.0.0=> Validating version compatibility=> Checking that the source server isn't empty=> Checking that the target server is empty=> Validating source server configuration=> Stopping the source server=> Stopping the target server=> Wiping the target server=> Migrating the data=> Migrating database=> Writing database patch=> Starting the target server=> Checking the target server=> Uninstalling the source serverThe tool refuses to migrate if the target is not empty, hence the rule about not initialising Incus beforehand, or if the source is empty. After Uninstalling the source server, the lxd service is inactive and Incus has taken over.
Verification confirms the instance switched over, keeping its IP and its configuration (here the user.role=frontend key set on the LXD side):
incus listincus config get webapp user.role+--------+---------+-----------------------+-----------+| NAME | STATE | IPV4 | TYPE |+--------+---------+-----------------------+-----------+| webapp | RUNNING | 10.181.216.145 (eth0) | CONTAINER |+--------+---------+-----------------------+-----------+
frontendThe instance still runs, with the same address as before the migration: lxd-to-incus took over the disk, the config and the network without recreating them. The default storage pool (a dir driver in this lab) is carried across as is.
After the migration: the touch-ups
Once the switch is done, several things are not migrated automatically and need manual work.
- System groups: re-add the users from the
lxdgroup intoincus-admin(sudo usermod -aG incus-admin <user>), otherwise you getpermission denied. - CLI configuration: copy
~/.config/lxc/(or~/snap/lxd/common/config/) over to~/.config/incus/to recover your remotes. - DNS suffix: the
lxdbr0bridge persists, but the DNS suffix moves from.lxdto.incus. Any hardcoded hostname ending in.lxdin your configurations or scripts has to be audited and fixed.
Key points
lxd-to-incuswas removed from the development branch in June 2026: present up to 7.1 and in the LTS branches, absent from 7.2 onwards.- The tool lives in the
incus-extrapackage, notincus: install it first. - Do not initialise Incus before migrating: the tool handles it, and the target must be empty.
- LXD has to be at version 5.21.99 or below, with
core.trust_passwordunset andzfsutils-linuxpresent for ZFS. - The migration stops everything and is not reversible: export your critical instances first.
- The tool can be silent on failures: check the real state afterwards.
- Manual touch-ups: the
incus-admingroup, the CLI config in~/.config/incus/, and the.lxdto.incusDNS suffix.
FAQ: common questions about migrating from LXD to Incus
The lxd-to-incus tool
sudo lxd-to-incus
It copies in place instances, images, profiles, networks and storage from LXD, including clustered installs.
Two conditions: Incus installed but NOT initialised (no incus admin init), and LXD at version 5.21.99 or below. Back up your critical instances first: the operation stops everything and is not reversible.
Stay on an LTS to migrate
lxd-to-incus was removed from the Incus development branch on 4 June 2026. Presence checked release by release:
| Release | lxd-to-incus |
|---|---|
| 6.0.6 LTS | present |
| 7.0.1 LTS | present |
| 7.1.0 | present |
| 7.2.0 | absent |
| 7.4.0 | absent |
The official migration documentation no longer lists an LXD path either, covering only moves between Incus servers, incus-migrate and lxc-to-incus.
The practical consequence: install an LTS release (7.0 or 6.0) on the target to run the migration. Once the data has moved, nothing stops you upgrading to a newer feature release.
No, Incus must stay untouched
Do not run incus admin init before migrating. The lxd-to-incus tool copies the data and configuration from LXD itself; it only needs the Incus service to be started.
Initialising Incus beforehand stops it starting from a blank state and makes the migration fail, in particular if it cannot remove /var/lib/incus.
Before and after
Before: LXD at 5.21.99 or below, lxc config unset core.trust_password, zfsutils-linux present for ZFS. On the Zabbly repositories the tool ships in the incus-extra package, not incus.
After (manual touch-ups):
- re-add the users to the
incus-admingroup; - copy
~/.config/lxc/to~/.config/incus/; - the DNS suffix moves from
.lxdto.incus: audit any hardcoded hostname.
The tool has also been silent on some failures: check the real state afterwards.
No, back up first
The migration is not easily reversible and stops every instance while it runs. Cases of instance loss on an interrupted migration, for example by unattended-upgrades, have been reported.
Before running lxd-to-incus:
- export your critical instances;
- schedule a real maintenance window.
A backup you did not need beats a migration that failed without one.
Next steps
- Importing a machine (incus-migrate): the path for a machine that is not managed by LXD.
- Terraform provider: take the migrated infrastructure back as code, once the state has settled.
- Ansible connection plugin: configure the inside of the recovered instances without opening a single SSH session.