A brand migration transfers recognition, access and trust from the old identity to the new one. Inventory domains, URLs, email, applications, legal records, partners and physical assets; map every critical dependency; preserve old routes with direct permanent redirects; communicate continuity; and monitor failures after launch. Keep the old infrastructure long enough to protect users, security and search discovery.
Establish control before changing anything
Confirm owners and recovery access for domain registrars, DNS, hosting, analytics, search tools, email, social accounts, app stores, advertising, repositories and third-party listings. Record renewal dates and multi-factor authentication arrangements without putting credentials in the migration plan.
Then confirm:
- approved legal and trading names;
- relevant trade-mark and company-name advice;
- final domains and URL policy;
- old assets that must be retained;
- launch and rollback owners;
- customer and partner notification duties.
If the name decision remains open, read should you rename your company before a rebrand?.
Create the URL and content map
Export all important existing URLs from sitemaps, analytics, server logs, search tools and the content system. Map each to:
- an equivalent new page;
- a consolidated page with genuinely matching content; or
- a true removal response when no replacement exists.
Include documents, images and other embedded assets. Update internal links and canonicals to point directly to the new URLs. Google advises permanent server-side redirects for permanent moves, direct mapping rather than redirect chains, and avoiding mass redirects of irrelevant pages to the homepage.
Checklist:
- Redirect map reviewed by content and technical owners.
- 301 or 308 redirects tested at scale.
- No loops or unnecessary chains.
- New pages are crawlable and self-canonical.
- Sitemaps contain final canonical URLs.
- Old domains remain controlled and renewed.
- Search Console properties and change-of-address steps are prepared where applicable.
Protect email and account trust
Configure new sender domains and relevant authentication before sending important messages. Test transactional, support, marketing and staff email separately. Preserve old addresses or forwarding where appropriate, watch for impersonation and tell customers how to verify legitimate messages.
Update login domains, password-reset links, OAuth callbacks, API allowlists, webhooks and single sign-on configurations. A visual change is secondary if customers cannot access their account.
Illustrative example
An illustrative team redirects the old homepage but overlooks help articles linked from the product. Customers reach hundreds of errors, and search results continue showing the old support domain.
A complete migration map includes help content and embedded images, sends each old page to its counterpart, updates product links and monitors 404 logs. This example is illustrative, not a report of an actual migration.
Update external and operational records
Review:
- company, tax and regulated records;
- contracts, invoices and bank or payment profiles;
- app stores, marketplaces and integration directories;
- partner, investor and supplier listings;
- paid campaigns and social profiles;
- customer documents and knowledge bases;
- signage, packaging and event materials.
Prioritise items affecting money, identity, access and customer trust. Apply a documented transition schedule to low-risk physical stock rather than treating every item as a launch blocker.
Use the broader rebrand rollout checklist to coordinate people, templates and product experience.
Verify and monitor after the move
Test critical journeys from an external network and across relevant devices. Crawl old and new URL lists. Check forms, search, structured data, analytics, consent, download MIME types and 404 responses. Monitor redirect failures, crawl and indexing reports, branded search, customer questions, email delivery and security alerts.
Google recommends retaining redirects for as long as possible and generally at least a year for site moves; from a user perspective, keeping them longer may be helpful. Update high-value external links where practical even while redirects remain.
Limitations and trade-offs
Running old and new infrastructure together costs money and extends the attack surface, but shutting the old domain too soon can harm users and trust. A single coordinated migration is clearer but concentrates operational risk. Staging reduces the blast radius while prolonging dual-brand complexity.
Technical search guidance cannot replace legal, security or contractual review. Adapt the checklist to the organisation’s systems and regulated obligations.
Frequently asked questions
Should every old URL redirect to the new homepage?
No. Map each old URL to a genuinely equivalent destination. Irrelevant mass redirects confuse users and may be treated as soft 404s.
How long should we keep the old domain?
Keep control long enough to protect users, email, security and search migration. Redirects should generally remain at least a year for search moves, and business risk may justify longer ownership.
Can we change the domain and redesign the site together?
You can, but combining changes makes faults and performance movement harder to diagnose. Separate them when practical; otherwise strengthen staging, URL mapping, testing and monitoring.
Your useful next step
Export the current URL inventory and list every system tied to the existing domain. Assign owners and test criteria, then run a rehearsal on a protected environment. Add the final map to the brand launch plan and do not approve the public switch while access, redirects or email trust remain unverified.