An app told me its default storage location is deprecated, and moving it broke the app

What went wrong is a distinction that catches everybody once: the setting points at where the application will look, and changing it does not move anything.

So you now have an application pointed at an empty location, and your data sitting in the old one. Nothing is lost and nothing is linked.

The order that works:

1. Stop the application. Moving data underneath a running application is how you get a half-copied library and a database that references files that are being moved.
2. Move or copy the data to the new location, preserving ownership and permissions. Copy rather than move if you have the space — then a mistake is recoverable.
3. Check ownership at the destination. This is the usual reason it still fails after a correct move: the application runs as a specific user id, and the new location is owned by something else.
4. Point the setting at the new location.
5. Start it and verify before deleting anything from the old location.

Step 5 is not optional. Keep the old copy until you have confirmed the application sees everything.

There is a second thing that catches people with applications that keep a database: the database may store absolute paths.

If it does, moving the files and repointing the setting is not enough — every record still refers to the old path. Some applications handle this, some have a maintenance command to repair paths, and some require the storage location to be a stable mount point precisely so this never arises.

Which is the actual lesson for next time: give the application a mount point that will not change, and move the storage underneath it rather than changing the path the application sees. Then relocating the data is a host-level operation the application never notices.

That is why the deprecation exists in the first place — the old default was almost certainly a location the platform itself controls, and the new arrangement is asking you to own the path.

On how you should have known: honestly, you could not have, and that is a real complaint rather than a gap in your process.

A deprecation that appears only in a settings page is not a notification. The people who find it are the ones who happened to open that page.

What you can do to reduce the surprise:

• Read release notes for the apps you self-host, at least the headings. Most of these changes are announced there first.
• Subscribe to the project's releases on its repository, which sends you the notes without you remembering to look.
• Do not update everything automatically on a machine holding data you care about. Automatic updates are right for security patches and wrong for major versions of an application that owns your library.

And it is worth saying to the platform's maintainers that a settings-page notice is not enough. That kind of feedback is how these become real notifications.

One practical addition: before any of this, know whether you have a backup you have actually restored from.

A move that goes wrong is only a scare if a restore is possible. The number of self-hosted setups where the backup exists and has never been tested is very high, and the moment you discover it is exactly this kind of maintenance.

Testing a restore of one album, one folder, one small thing, is an hour and it changes what every subsequent maintenance job feels like.