How should a tech startup roll out a new name without breaking its product, domain and search traffic?

Illustrative situation: a seed-stage team gets its new identity files on a Monday and moves the website to the new domain on Tuesday. The old domain’s renewal lapses to save a fee. Ten days later a partner’s webhook fails because it called an API host under the old domain, password-reset emails land in spam because the new sending domain has no DKIM record, and the Google sign-in screen still shows the old name. Nobody owned those surfaces. The scene is invented. It shows the mistake this guide helps avoid: treating a rename as a website launch, so the surfaces with no owner fail first.

Humbleteam, a digital product design agency, publishes this guide. It starts after the name is cleared; if yours is not, check the name first. It covers the order of work, domain, email, product, stores, developer platforms, customer and contract surfaces, a cutover worksheet and an invented example. Sources and product behavior are described as of November 8, 2026 and can change. This is not legal advice: a lawyer who knows your contracts and jurisdiction decides what your documents need.

What order should the work follow?

Google’s site-move guide says to change one thing at a time, and its Change of Address page says a redesign combined with the move will probably cost traffic. Keep paths and page content the same on the day the domain changes.

Our order:

1. Inventory every place the old name appears and give each one an owner.
2. Start the slow items first: email authentication, OAuth verification, store requests, new package names.
3. Cut over in one planned window: redirects, in-app name, templates, docs.
4. Watch, deprecate and renew. Keep the old domain and redirects.

How do you move the domain without losing search traffic?

Map each old URL to its closest new URL and redirect server-side with a 301 or 308. Avoid chains. Do not send everything to the new home page, which can be treated as a soft 404. Verify every variant of the old and new domains in Search Console, then run the Change of Address tool once the redirects work. You must own both properties with the same Google account, and the tool does not move subdomains below the domain you enter. So www, app and docs each need their own request.

Google’s two pages differ on duration. The site-move guide says to keep redirects as long as possible, generally at least 1 year. The Change of Address page says at least 180 days, and advises paying for the old domain for at least a year so nobody else can buy it. We plan for a year.

How do you switch the email sending domain?

The new From domain needs its own SPF and DKIM records. Google’s sender guidelines add DMARC for anyone sending more than 5,000 messages a day to Gmail, and the From domain must align with the SPF or DKIM domain. Yahoo asks bulk senders for the same records and advises separating marketing from transactional mail by IP or DKIM domain. Both want spam complaints under 0.3%.

For the ramp, Google says to start with low volume to engaged users and increase slowly, and to ramp a changed part of your traffic separately after an infrastructure change. We found no published warm-up schedule. Set your own steps, start with receipts and password resets, and watch Postmaster Tools. Keep the old domain’s mailboxes alive, since customers will reply to old addresses.

Which product surfaces carry the old name?

Search code, templates, databases and third-party dashboards for the old name, not just the interface. Four surfaces need care.

• Transactional templates: receipts, resets and invites often live in an email provider, not in the repo.
• OAuth consent screens: Google says changing an app’s name, logo, redirect URI, homepage link or privacy link means brand verification again, and users do not see the change until it finishes. Submit early, and expect the sign-in screen and your in-app name to disagree for a while.
• API hostnames: partners allowlist hosts and store webhook URLs. Run old and new hosts side by side. The Sunset header in RFC 8594 can mark the old host as likely to stop responding on a date.
• SDK names and docs: keep old doc URLs redirecting and update code samples.

What do app stores and developer platforms allow?

Apple lets you edit an app’s name, 30 characters at most, until you submit it for review, and later with a new version. The bundle ID cannot change after a build is uploaded. The developer name can be set only when you add your first app. Changing the organization name needs a request to Apple, and Apple says it updates the vendor name across all your apps, resets the identifierForVendor and cannot be undone. Once Apple approves a legal-entity change, it can take up to two weeks to appear.

On Google Play you can change the app name later, but package names are permanent. A new developer name shows after Google reviews it.

On GitHub, renaming an organization redirects web links and git remotes. API requests that use the old name return 404, and the old name becomes available to others. npm has no rename. The only way is to publish under a new name, and npm recommends deprecating the old package instead of unpublishing it.

What about invoices, payments, contracts and social handles?

Decide first whether the legal entity changes or only the trading name, because platforms ask for different things. Stripe wants the statement descriptor to reflect your Doing Business As name and says clear descriptors can reduce chargebacks and disputes. Apple shows the legal entity unless you set a registered trade name as the developer name on your first app. For a UK limited company, the name changes only when Companies House registers it, and you may need to tell HMRC. Ask counsel whether order forms, data processing terms and security documents need an amendment or a notice, and ask your accountant which name stays on invoices.

For social profiles, LinkedIn says a Page name change does not change the URL or employees’ work history, and verified Pages must contact LinkedIn. After a URL change, old and new both work until someone requests the old one. We could not read X’s help page, so check each platform’s rules, and reserve new handles before you announce.

When should customers hear about it?

Our rule of thumb, not a standard, uses three groups. People who must act, such as API users, SSO admins and finance contacts, hear first with dates; we suggest four weeks. Everyone else hears on cutover day. A reminder follows when the old host gets an end date.

What does the cutover worksheet look like?

Illustrative worked example: Plumbrae becomes Tavelin

Everything here is invented: the company, product, names and timings. Plumbrae sells a scheduling API, a web app and an iOS app. It becomes Tavelin. Domains below use the reserved .example ending. The legal entity stays unchanged for now.

• Six weeks before: owners named for twelve worksheet rows. Records for mail.tavelin.example are published, and password resets move over first at a small share of volume.
• Five weeks before: the OAuth consent screen goes in for brand verification. Partners get four weeks’ notice of api.tavelin.example, and both hosts will run.
• Four weeks before: the SDK is published as @tavelin/sdk. A final plumbrae release depends on it, then the old package is deprecated.
• Cutover Tuesday: 301 redirects go live, and Change of Address requests go in for the bare domain, www, app and docs. The iOS name changes with a new version. The developer name stays old, because it cannot be edited until an entity change.
• Week three after: verification arrives. Until then the Google screen shows Plumbrae, and the help center says why.
• Month twelve: the team reviews redirect traffic and renews the old domain.

What should you ask a branding agency when scoping?

A branding scope often ends at identity files and the marketing site. That is our reading, not a survey. So ask, for each worksheet row: is it built work, a list handed to your own owners, or outside the engagement? “Outside” is fine. “Nobody” is the gap.

Where do these defaults stop working?

We read Google’s, Apple’s, Stripe’s, GitHub’s, npm’s and LinkedIn’s pages, plus UK company-filing pages. We could not read X’s help page, and we read no Instagram page, no US or EU entity rules and no Bing guidance. Google’s site-move advice covers Google Search only. Review times for Apple, Google Play and OAuth verification are not published, so the estimated lead times, the one-year redirect plan and the four-week notice are our rules of thumb. We tested no product or rollback. A regulated product or an enterprise contract may need longer notice.

What can you produce now?

Five things, in about a week:

1. A surface inventory with one named owner per row.
2. An old-to-new URL map and a redirect test list.
3. DNS records and a ramp plan for the new sending domain.
4. A filled cutover worksheet with dates, rollbacks and checks.
5. Customer notices in three groups with dates, and a scoping question for your agency.

To compare teams for the identity work itself, see our comparison of startup branding agencies.