Renames, rebrands, and acquisitions: announcing an identity change without losing trust

Rename a product and, strictly speaking, nothing breaks. The binaries are identical. The API returns the same JSON. Every test passes. And yet the day the new name goes live, things start failing all over the world: bookmarks point at a domain that no longer answers, a finance team flags an invoice from a company they’ve never heard of, a password manager refuses to autofill on the “wrong” site, and a user squints at an email from an unfamiliar sender asking them to log in to continue — which is, word for word, what phishing looks like.

A rename is a breaking change to the one interface every user depends on: the name. It deserves the same discipline you’d give an API removal — advance notice, precise scope, a dated timeline, and a permanent entry people can find months later. This guide covers the three flavors of identity change (rename, rebrand, acquisition), what readers actually need to know for each, the surprisingly long list of things that break mechanically, and why the unannounced version doesn’t read as a surprise — it reads as an attack.

The silent rebrand reads as an attack

Users don’t experience an unannounced rebrand as “new logo.” They experience it as a security incident, because every visible symptom of a rebrand is also the signature of one:

  • An email from a sender they’ve never heard of, asking them to log in or update billing.
  • A login page that redirects to a domain they’ve never seen.
  • An OAuth consent screen listing an app they never remember authorizing.
  • A card statement with a charge from an unfamiliar company name.
  • A password manager that suddenly refuses to autofill — which users correctly read as “this is not the site you think it is.”

People are trained — by you, probably, in your own security emails — to treat all of these as red flags. The announcement is what authenticates the change. A dated changelog entry at a URL users already trust, published before anything visible moves, is the difference between “oh right, they renamed” and a support ticket, a chargeback, a spam report, or a revoked OAuth grant. Silent rebrands don’t save you an announcement; they convert it into a thousand suspicious conversations you don’t get to be present for.

Three kinds of identity change, ascending stakes

1. Product rename. Same company, same owner, new product name. The reader’s questions are mechanical: do my URLs, integrations, and package installs still work? This is the mildest form, and the checklist below mostly covers it.

2. Company rebrand. New company name, new domain, new brand. Everything in a product rename, plus the surfaces tied to the company: email sender domains, login and SSO domains, billing descriptors, contracts, support addresses. The blast radius is wider because identity is verified in more places.

3. Acquisition. The product changes owners. Everything above, plus the questions that actually keep users up at night: does the product survive, does the price change, and who has my data now. An acquisition entry that only talks about “exciting news” and logo timelines while skipping those three is not an announcement; it’s a press release wearing one’s clothes.

Each level inherits every question from the previous one. Write for the highest level that applies.

What readers ask, in order

  1. Is this real? Authentication first. The entry lives on your existing changelog, is linked from the old domain, and is dated before the change. That provenance is the proof.
  2. Does anything break? Name the surfaces precisely: web URLs, API hostnames, package names, SSO and OAuth app identities, webhook origins, email senders, billing descriptors. “Everything keeps working” is a fine answer if it’s true — but say it surface by surface, because that’s how readers check it.
  3. What happens to my data, plan, and price? For acquisitions this is the whole ballgame. Answer with dates and commitments, not vibes (more below).
  4. What do I need to do? Usually “nothing” — say so explicitly. Where action is required (repoint an API hostname, allowlist a sender domain), give exact steps and a deadline.
  5. Who do I talk to now? Support address, security contact, and where the legal documents (privacy policy, DPA) now live.

The mechanical breakage checklist

  • Domains and URLs. The old domain 301-redirects to the new one — forever, not for a courtesy year. Links to your docs live in tutorials, Stack Overflow answers, and other people’s READMEs; those pages will never be updated, and every one that breaks is a stranger’s first impression of the new name being “the thing that killed the links.”
  • API hostnames. An API hostname is an API contract, and a redirect is not a migration plan: plenty of HTTP clients don’t follow redirects on POST, and well-behaved ones drop credentials on cross-origin redirects. Treat the old hostname as a deprecated interface — announce it, emit Sunset headers, give it a dated window per your deprecation policy, and keep it fully working until that date.
  • Package names. For npm, PyPI, and friends: publish a transitional package under the old name that depends on the new one, mark it deprecated with a pointer to your entry, and never delete it. Dependents upgrade on their own schedule — people who upgrade on purpose need the trail of breadcrumbs to still be there in two years.
  • OAuth and SSO identities. When the app name on the consent screen changes, users see an app they don’t recognize holding access to their account — and the security-conscious ones revoke it. Announce the new name before it appears, or your most careful users become your first breakage reports.
  • Email senders. A new sender domain needs SPF, DKIM, and DMARC set up and warmed — and users told in advance. One line in the heads-up entry (“from September 2, email comes from @newname.com”) keeps password resets out of spam folders.
  • Billing descriptors. The line on the card statement is the identity surface people scrutinize hardest. Announce the new descriptor or eat the disputes.
  • Support and status. Old support addresses forward indefinitely. If the cutover itself might blip anything, that hour belongs on the status page; the changelog carries the durable record.

Announce before, not after

Feature launches follow the announce-when-usable rule — the announcement lands when the reader can act on it. Identity changes invert it: the announcement must arrive before anything visible changes, because the announcement is what authenticates everything that follows. Three entries, one story:

  1. The heads-up (two to four weeks out): what’s changing, on what date, what breaks, what to do. This is the entry every suspicious email and unfamiliar redirect will be checked against.
  2. Change day: it happened; restate the breakage list and the support paths. This is the permalink your support team pastes for the next six months.
  3. The follow-up: redirects verified, old hostname’s sunset date confirmed, anything that moved since. Close the loop in public.

This is also one of the rare cases where email to your whole list is mandatory, dormant accounts included — dormant users are exactly the ones who’ll come back in eight months, meet a login page they don’t recognize, and have no idea there was ever an announcement.

Don’t reset the history

The tempting rebrand-day move is a clean sweep: new site, new blog, new changelog. Resist the last one. Your changelog’s unbroken history is the strongest evidence that NewName is the same product — same team, same cadence, same accumulated care. It’s the same signal an unbroken decades-long changelog sends about a project’s seriousness, and a rename is the moment you need that signal most. Rename in place: keep every entry, every date, every permalink. A changelog that starts three weeks ago makes a ten-year-old product read like an untested startup — a self-inflicted wound, administered on the one day trust is already wobbling.

Acquisitions: earn the “nothing changes”

“Nothing changes” is the most common sentence in acquisition announcements and the least believed, because everyone has watched it precede a price hike or a shutdown. The fix is not better reassurance; it’s replacing reassurance with commitments that have dates on them: prices frozen until date; product supported until at least date; data stays in region; the privacy policy changes on date, and here’s the diff. Commit to what you can commit to, and say which questions are still open rather than papering over them — “sso pricing is being worked out; decision by October” outperforms silence.

If a sunset is the plan, say so, with an export path and a real window. Users forgive an honest sunset; they never forgive being strung along. And answer the data question explicitly even when the answer is boring — who controls the data now, what changed in the legal documents, how to export or delete. The changelog isn’t the legal document, but it’s where people will look for the link to the ones that are.

An entry template

## OldName is becoming NewName — what changes and when — 2026-08-12

On **2026-09-02**, OldName becomes **NewName**. Same product, same team,
same plans and prices. Here is exactly what changes:

- **Web app:** oldname.com redirects to newname.com permanently.
  Bookmarks and shared links keep working.
- **API:** api.oldname.com keeps working until **2027-03-02** (Sunset
  headers start today). Switch to api.newname.com before then — one
  hostname change, nothing else differs.
- **Email:** from 2026-09-02 we send from @newname.com. Allowlist it
  if your team filters senders.
- **Billing:** card statements read NEWNAME from your next invoice.
- **Nothing to do** for most accounts. If you pin API hostnames or
  filter email senders, the two items above are the only changes.

Questions: support@newname.com (support@oldname.com forwards forever).

Anti-patterns

  • The silent rebrand. Users discover the change as suspected phishing, one support ticket and spam report at a time, and you spend the launch week proving you’re yourself.
  • Unqualified “nothing changes.” If it’s followed by anything changing — and something always changes — the sentence retroactively becomes a lie, and it was already the least-believed sentence in the genre.
  • The history reset. A fresh empty changelog on rebrand day deletes the one artifact that proved continuity.
  • Marketing-blog-only announcement. The blog post scrolls away in a week; the questions arrive for a year. The changelog entry is the durable, linkable answer — the blog post should point at it, not replace it.
  • Breaking old URLs. The redirect budget is forever. Every dead link is a stranger meeting the new name as the thing that broke the old one.
  • Name soup. Six months where the app says NewName, the docs say OldName, and the invoice says something else. Every mismatched surface re-asks the is-this-phishing question. Track the rename like a migration: a checklist of surfaces, each with an owner and a date.

How this works in Wakelog

A Wakelog project’s display name is editable in settings while every permalink, feed URL, badge, and embed keeps working untouched — so you can rename in place and keep the unbroken history that proves continuity. The three-entry sequence above maps onto drafts plus scheduled publishing: write all three up front, schedule the heads-up and the change-day entry (publish_at), and let the announcement tag and your Discord/Slack mirrors carry them to subscribers, whose existing feed URLs keep working through the rename. Honest caveat: the URL slug itself doesn’t change — for most renames that’s fine (it’s a path segment, not your brand), and if the old name in the slug truly must go, the portable changelog.md export re-imports into a fresh project with entries and dates intact, though permalinks and reaction counts don’t carry over.

Keep your history through the rename   Next: announcing breaking changes →

Related guides

Last updated 2026-07-28 · All guides