Synology app mover: relocating DSM packages between volumes

Relocating a package instead of reinstalling it

The problem is narrow and concrete. Packages on a Synology NAS live on a storage volume, and DSM points at them through links. When you want the package somewhere else, the obvious route is to reinstall it from Package Center, which means repeating whatever configuration the package needed and accepting that some packages have no clean reinstall path. The documentation offers another route: pick the package and the destination volume, and the script stops the app, moves it, updates the symlinks, then starts the app. The stated use cases are moving packages to an SSD volume, or moving them to a different volume so the original volume can be deleted. Both are the kind of job that looks small until you have a dozen packages on a volume you want to retire. Because the operation goes through a stop, move, relink and start sequence, the package is expected to be running again on the other side rather than merely copied there, and the symlink repair is the step that makes the moved location visible to DSM.

Backup and restore modes on top of the move

Beyond relocation, the project ships backup and restore modes, and a USB drive is one documented backup target. The requirement there is specific and worth repeating: the filesystem of the USB partition should be ext3, ext4 or btrfs. The documentation does not describe what happens with other filesystems on the backup target, so treat a differently formatted drive as unsupported rather than as a case the script can recover from. This mode is a package level operation, not a full volume image. It concerns the packages you point it at, and restoring is the inverse of the same operation, so the pairing between a backup and the package set it covers is something you have to track yourself. The project also links a screenshot of the backup interface in its images directory, which is the fastest way to see what the mode expects before you commit data to it.

Package support is tracked build by build

The most valuable part of the documentation is a compatibility table that lists package center names, the system names used internally, and the result of moving each one. The entries are more informative than a yes or no because they record what broke. Container Manager 24.0.2-1535 to 1543 is marked OK with a note about some issues moving the docker folder, while Container Manager 20.10.23 is marked OK but can have issues with broken containers. The newest listed Container Manager, 24.0.2-1606, is marked No, with a new script version announced for it. AntiVirus Essential is marked OK only from version 4.2.88 of the script onwards, which makes that a floor rather than a nice to have. Most entries are plain OK, including Active Backup for Business, Cloud Sync, Hyper Backup, Hyper Backup Vault, MariaDB 10, Media Server, Jellyfin, Apache HTTP Server 2.4 and the plain Docker package. A few carry caveats, such as Glacier Backup needing its backup task run again afterwards, and Bitdefender for MailPlus, which the table records as OK with the author's own uncertainty attached. The table also warns that you should back up your docker compose files or portainer stacks before starting, since a move that disturbs the docker folder can take those definitions with it.

DSM 7 is the target, DSM 6 is untested

Platform support is stated plainly: the script supports DSM 7 and is not fully tested with DSM 6. That is a hard boundary for anyone still on the older release, and it is the kind of boundary that decides whether you try the tool at all rather than a footnote. The project is a shell script, so it inherits the environment it runs in on the NAS rather than shipping a binary of its own. The compatibility table also distinguishes community and third party packages from Synology's own, listing FFmpeg, Git, Mosquitto and LogAnalysis among the packages that come from outside the official catalog. Community packages are exactly the case where the internal system name matters, because the script matches on that name rather than on the display name, and a mismatch shows up as a package the mover does not recognize.

Two scripts and a config file in the repository root

The repository is small and easy to read. At the top level sit syno_app_mover.sh, which is the script itself, and syno_app_mover.conf, which holds its configuration, alongside CHANGES.txt, README.md, a LICENSE file, the images directory and two markdown files, moving_extras.md and my-other-scripts.md, that point at related work by the same author. The file listing matters for the first use, because the script and its configuration file are what you need to copy onto the NAS, and the documentation gives no package manager command or installer to run.

The script is also published as a Synology package, which the documentation points to as a separate repository, 007revad/Syno_App_Mover. That gives you two routes to the same behavior, one raw and one packaged. Release numbering moves in small steps: v4.2.102 was published on 2026-09-03, and both v4.2.103 and v4.2.104 were published on 2026-10-08. The last push to the repository was on 2026-10-09, and the repository is not archived, so the project is still being worked on rather than frozen. The MIT license covers the code, and the usual terms of that license apply, including keeping the copyright and permission notice in copies of the software.

Where this script is the wrong choice

There are several cases where the tool does not fit. If your Container Manager is version 24.0.2-1606, the compatibility table records the result as No, and moving it by other means is the only option today. If you are on DSM 6, the project does not claim full testing. If your USB backup drive is formatted as something other than ext3, ext4 or btrfs, the documented condition is not met. And if your reason for moving is a corrupted package rather than a volume reshuffle, this is the wrong class of tool, since it relocates and relinks rather than repairs. The alternative to compare against is the packaged version of the same script, 007revad/Syno_App_Mover, which installs through DSM's package mechanism instead of being run from a shell on the NAS. The difference in approach is installation and update handling rather than the move itself, and the choice between them is about whether you would rather have the script managed by DSM or keep control of the files yourself. Neither path removes the manual work of backing up compose files before a move that touches the docker folder.

Editorial conclusion

Synology app mover suits NAS owners who want a package relocated to an SSD volume or want a volume freed without reinstalling everything by hand. It is the wrong tool for the newest Container Manager build, for anyone running DSM 6, or for USB backup targets on a filesystem other than ext3, ext4 or btrfs. Before the first run, back up the docker compose files or portainer stacks, confirm the exact package build appears in the compatibility table with an acceptable result, and check the release notes for the version you intend to copy.

Frequently asked questions

Official sources

1. 007revad/Synology_app_mover on GitHub
2. Issues
3. License: MIT
4. README
5. Releases