Timeshift snapshot safety versus Update Manager package holds for a small app migration on Linux Mint

A design goal is to migrate a small application on Linux Mint while maintaining continuous availability and system stability. The migration must respect the existing APT-based package management and the Software Manager abstraction for Flatpaks and system packages.

One documented approach is a system-level safety net with Timeshift. Timeshift can create restore points of the root filesystem and allow a full state rollback if the migration fails. A second documented approach is controlled deployment with the Update Manager, which allows specific packages to be selected for update or held, enabling staged dependency changes.

The constraint is data and service continuity. Timeshift snapshots primarily target system files and configurations rather than user-home directory data by default, and a rollback may overwrite configuration changes made to other services since the snapshot was taken. Flatpak updates are decoupled from the system package manager, creating two different update paths for the same application.

With these documented behaviors, the unresolved decision is which approach preserves application data and service continuity for a no-downtime migration.

Does the default Timeshift configuration on current Linux Mint releases include user-home data for application state, or is explicit inclusion required? How does holding a package in Update Manager interact with a concurrently installed Flatpak version of the same application? What is the documented effect on running services when a Timeshift rollback is applied versus a package hold during an active session?