Skip to content
Français
Conteneurs & Orchestration medium

Migrating from LXD to Incus with lxd-to-incus

15 min de lecture

Read this page in French

incus logo

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-incus procedure.
  • 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.

Releaselxd-to-incus
6.0.6 LTSpresent
7.0.1 LTSpresent
7.1.0present
7.2.0absent
7.4.0absent

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.99 or below: beyond that, lxd-to-incus refuses to migrate.

  • If your pools use ZFS, the zfsutils-linux package has to be installed, a classic with the LXD snap.

  • core.trust_password unset 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:

Fenêtre de terminal
sudo apt install incus-extra
which lxd-to-incus # /usr/bin/lxd-to-incus

Once the prerequisites are met, the migration is one command:

Fenêtre de terminal
sudo lxd-to-incus

The 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 server

The 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):

Fenêtre de terminal
incus list
incus config get webapp user.role
+--------+---------+-----------------------+-----------+
| NAME | STATE | IPV4 | TYPE |
+--------+---------+-----------------------+-----------+
| webapp | RUNNING | 10.181.216.145 (eth0) | CONTAINER |
+--------+---------+-----------------------+-----------+
frontend

The 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 lxd group into incus-admin (sudo usermod -aG incus-admin <user>), otherwise you get permission denied.
  • CLI configuration: copy ~/.config/lxc/ (or ~/snap/lxd/common/config/) over to ~/.config/incus/ to recover your remotes.
  • DNS suffix: the lxdbr0 bridge persists, but the DNS suffix moves from .lxd to .incus. Any hardcoded hostname ending in .lxd in your configurations or scripts has to be audited and fixed.

Key points

  • lxd-to-incus was 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-extra package, not incus: 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_password unset and zfsutils-linux present 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-admin group, the CLI config in ~/.config/incus/, and the .lxd to .incus DNS suffix.

FAQ: common questions about migrating from LXD to Incus

Next steps

Is this site useful to you?

Fewer than 1% of readers support this site.

I maintain more than 700 free guides, with no ads and no tracking. Any support, even a symbolic one, helps cover hosting and keeps these resources free. Thank you for the help.

The form does not show? Open Ko-fi in a new tab.

Subscribe and follow my DevSecOps work on LinkedIn