𝗥𝗲𝗻𝗮𝗺𝗶𝗻𝗴 𝗮 𝘀𝗶𝘁𝗲 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗹𝗼𝘀𝗶𝗻𝗴 𝗱𝗮𝘁𝗮
A client asks to rename a site from acme-staging to acme. You change the name in the app. Suddenly, all database backups, screenshots, and thumbnails disappear.
The files still exist on the disk. The new directory is just empty. The data did not follow the name change.
We made this mistake in our original design. We used the site name to decide where to store files.
If you store files in backups/acme-staging/ and then rename the site to acme, the app looks for backups/acme/. It finds an empty folder. The old data stays in the old folder, but the app treats it as stale data from a different site.
Site names change often. Clients fix typos. Teams move staging sites to production. Companies reorganize.
We fixed this by separating the display name from a stable identifier.
Every site now has a unique ID. It looks like site_a1b2c3d4e5f6. This ID never changes.
We now store files using the ID instead of the name. The directory path looks like backups/site_a1b2c3d4e5f6/. Even if you rename the site, the path stays the same. The data stays connected.
Moving existing users to this system was the hard part. We built an idempotent migration. This means the system checks for an ID at startup. If a site lacks an ID, the system assigns one. If it has one, the system leaves it alone.
We also migrated the physical files. If the system finds a folder named after a site, it renames it to the new ID format.
We even fixed the logs. New logs use the ID. Old logs use the site name. The UI combines both so your history looks continuous.
We learned a tough lesson about validation. After the update, we added a rule to check ID formats. The rule was too strict. It rejected some older IDs from our migration. Suddenly, sites disappeared again.
The lesson is simple: audit your data before you add new rules.
Separating what humans see from what the system uses is a classic pattern. Doing it after you launch is expensive and risky. Use immutable IDs from day one to avoid this trap.