The tool I used for lightweight containers on my NAS is abandoned — what replaces it and how do I move?

What changes is the layer you are managing, and it is worth being clear about because the two tools are not the same kind of thing.

The community tool wrapped the init system's own lightweight container mechanism — a thin layer over something already on the box, which is why it was easy to add and easy to abandon.

The replacement is a full system container and virtual machine manager. It manages images, storage pools, networking, snapshots, profiles and limits, with its own command set and its own idea of where things live. That is more capability and a genuinely different tool, not a renamed one.

The practical consequence for migration: there is no in-place conversion. The container's contents move; the container itself does not. What you are moving is the filesystem and the configuration knowledge, and you are recreating the container around it.

One thing worth deciding while you are rebuilding anyway: whether these should be system containers at all.

If an environment exists to run one service, an application container with its data on a dataset is simpler and survives platform changes better — you have just seen what happens when the management layer disappears.

System containers earn their place when you genuinely want a persistent machine you administer: several services, a package manager, state that is not one application's database. Worth sorting your environments into those two piles before recreating all of them the same way.

The path that works, in order:

1. Write down what each environment actually is before touching anything: which packages, which services, which mounts from the host, which ports, which user and group ids. This is the part people skip and then rebuild by trial and error.
2. Copy the data out to a location outside the container — a dataset on the pool. Do this while the old system still runs.
3. Create the new container on the replacement manager from a clean image of the same distribution.
4. Reattach the data as a mount, rather than copying it inside. Keeping data outside the container is what makes the next migration a configuration exercise instead of this one again.
5. Reinstall the services and point them at the mounted data.

The user and group id mapping is the step that bites. A system container may map ids differently from the old tool, so files owned correctly before are owned by nobody afterwards. Check that first, on one small environment, before moving anything you care about.

On timing, and this is the part I would weigh most: do not migrate onto a major platform release on the day it arrives.

The replacement arriving in the next release means the integration is new. New integrations on storage platforms have rough edges, and the people who find them are the ones who upgraded immediately.

What I would do: keep the existing environments running on the version you are on, which still works, and set up one new container on the new release to learn the tool and validate the id mapping. Move the rest when the release has had a point update or two.

The old tool being unmaintained is a reason to plan the move, not a reason to do it this week. Unmaintained is not the same as broken, and it will keep working exactly as well as it did yesterday.