Flow
Checks I'd run on a rename like this
1Anything cut by length
Measure the prefix in code instead of typing a number.
2Entries in other tools' settings
Match old and new names, rename in place.
3Folders on users' machines
Copy the old folder on first run if the new one is missing.
4Stored data
Check the live column rules, count rows per customer, trace one fresh record.
Midway through a product rename, the install flow in my app turned out to be chopping the wrong number of letters off a token. That was the moment I saw the rename was two jobs, not one.
Most of the job was text. The old name was in docs, page copy, logos, package names, comments and scripts, across a few hundred files. I swapped it all out. If a heading shows the wrong name, a person spots it and nothing breaks.
A few spots were different. Something else was already holding the old name: a bit of parsing code, another program's settings, a folder on each user's laptop, and rows in a database. Changing those is moving data, not editing words. I'm going from the commits and the code here. I didn't see these fail live, so the failures are my read of what the code would do.
A prefix that got counted instead of read
The install flow sends the code host a token made of a short name prefix, a colon and a random value. When it comes back, the code cuts the prefix off and checks the random value. It cut by a fixed number of letters. The prefix got longer and the number didn't, so bits of the prefix stayed stuck on and the check could never pass. I fixed the number before the change merged. I'd rather the code measure the prefix itself.
The change cuts off exactly as many characters as the prefix has, so the number can't go stale again.
An install that starts before a deploy and ends after it still carries the old prefix. I haven't tested what happens to it.
A hook living in my agent's config
My command line tool adds a hook to my coding agent's settings. It checked for an existing hook by looking for its own name, and after the rename it only knew the new name. On an older setup it would add a second hook. The agent would then probably call both. Later that day I taught it to accept either name, rename the old hook in place, and remove both on uninstall. I didn't add a test for it.
A settings folder nobody moved
The tool keeps its settings in a folder named after the product. It now looks in a new folder, and nothing copies the old one over, so people upgrading look logged out. The replace also renamed an even older settings file that a one-time migration looks for, so that migration now hunts for a file nobody has.
Keys already sitting on disk
Every telemetry record gets tagged with which customer, team and user it belongs to, under keys that start with the product name. The database turns each key into its own column when a row is saved, and customer views filter on those columns.
I wrote a script to copy the old rows into a new table with renamed keys, then swap the tables and rebuild the views. The catch is that the new table copies the old column rules, and my schema steps skip columns that already exist. Unless the live rules were changed some other way, the copied rows would have empty customer columns, so customers would see no data. The script's own check only looks at the raw keys, never at those columns. Rows written during the copy would also end up in the backup table.
The checks I'd add first: the live column rules, a count of rows per customer before and after, and one fresh record traced all the way into a customer's view.