Free · No email gate · Copy into your tracker

SaaS rebrand checklist.

Fifty surfaces the old brand lives on, grouped the way the work is actually done: the equity audit before day one, the product, the marketing site and its SEO, sales collateral, email and support, app stores, launch day in order, and the 30 days after. This is the migration plan we ship inside a SaaS rebrand engagement, published in full. Each item is written so it can become a row with an owner and a date.

If you are still deciding whether a rebrand is warranted, start with the SaaS rebrand guide; if you are choosing who does it, the rebrand RFP template is the companion to this page. For how other companies handled the same migration, six SaaS rebrands that worked reads their own announcements.

Before day one — the equity audit

A rebrand fails in the inventory, not in the design. Everything below is done before a pixel moves.

  • 01 Inventory every surface the current brand lives on. Marketing site, product UI, mobile apps, sales, social, paid creative, support, partners, legal. This list is the checklist; the rest of the page is the starting inventory.
  • 02 Pull every URL that received organic traffic in the last 90 days. Search Console and analytics, exported. This is the redirect map’s source of truth — not the sitemap, which forgets the old blog post that still ranks.
  • 03 Find every copy of the old logo file. Repository, CDN, email templates, app stores, partner folders, the founder’s Google Drive. Search the codebase for the file names and the brand hex codes; both will be hard-coded somewhere.
  • 04 Decide what stays: the name, the mark, the colour, or none. Write it down with the reason. Equity that customers recognise is the only thing a rebrand cannot rebuild.
  • 05 Talk to customers and sales before the visual work starts. What do customers call you, what do they recognise, what do they confuse you with. Five conversations beat a survey.
  • 06 Give engineering the new tokens first, then freeze old-brand feature work. Colour, type scale, spacing, radius, motion as variables. A feature shipped in the old language two weeks before launch gets redone twice.
  • 07 Assign one owner and one date to every surface on this list. A rebrand with a shared spreadsheet and no owners launches in three waves, and the second wave is the one customers notice.

Product UI

The surfaces users see every day, in the order they meet them.

  • 08 Replace the design tokens, not the screens. If the identity was handed over as variables, the product changes in one pull request. If it was a PDF, this is where the timeline doubles.
  • 09 App icon, favicon, PWA manifest icons, touch icons. Every size, light and dark, and the `mask-icon` colour that lives in the HTML head — the one that stays purple two years after the brand turned blue.
  • 10 Login, sign-up, onboarding, empty states, error states. The first-run screens are the ones a new customer photographs. They also tend to be the oldest code.
  • 11 Emails the product sends. Verification, password reset, invoices, notifications, digests. Transactional templates live in a different system from marketing email and are missed on almost every rebrand.
  • 12 Dark mode and light mode, both checked against the new palette. A palette chosen for the marketing page produces a second, unofficial brand inside the app. Check contrast in both modes before launch, not after the first support ticket.
  • 13 Screenshots inside the product — help panels, tooltips, tours. The old interface will keep appearing in your own onboarding until someone retakes them.
  • 14 Component library and design-system documentation. Whatever engineering pulls components from has to be the new brand, or the next feature reintroduces the old one.
  • 15 An in-product notice: what changed, in one sentence, with a link. Without it, the first thing support hears on launch day is “did we get phished?”

Marketing site and SEO

Where a rebrand costs traffic if it is done in the wrong order.

  • 16 A one-to-one redirect map for every URL from item 02. Same page, new URL, one 301. Never redirect a ranking page to the homepage; that is a soft 404 to Google.
  • 17 Titles, meta descriptions, and every OG image regenerated. Then re-scrape the links you have shared: LinkedIn, Slack and iMessage cache the old card for weeks unless you force a refresh.
  • 18 Structured data: organisation name, logo URL, social profiles. The logo Google shows next to your name in search comes from here, and it updates on Google’s schedule, not yours.
  • 19 Sitemap resubmitted, Search Console property checked, old domain kept if the name changed. If the domain changes, keep the old one redirecting for as long as you own it. Years, not months.
  • 20 Old-brand images inside blog posts, case studies, and docs. Every screenshot with the old interface, every diagram with the old colour. Retake the ones on pages that rank; leave the rest for the 30 days after.
  • 21 Analytics, tag manager and consent tooling still firing after the cutover. A rebrand that ships with a new site template often ships without the tag. You find out at the next monthly report.
  • 22 Brand search: your own name as a query. Search it on launch day and every week for a month. Old thumbnails, old titles and the previous logo in the knowledge panel are all normal and all temporary — but only if the sources above were changed.

Sales and partner collateral

The surfaces a buyer sees when nobody from your team is in the room.

  • 23 Sales deck master and the one-pager. Then archive every old copy sales has saved locally. The old deck will be sent to a prospect in month two if it still exists.
  • 24 Proposal, contract and invoice templates. Including the billing portal and the receipts your payment provider sends — most providers have a branding setting nobody has opened since setup.
  • 25 Case-study PDFs and the pages that host them. The document a buyer forwards internally is the one you least control. Version it.
  • 26 Partner and co-branding assets, sent with a switch date. Partners will use whatever they have. Send the new files, the date, and a one-line note about what to retire.
  • 27 Your logo in other people’s directories and marketplaces. Review sites, integration marketplaces, app directories, conference sponsor pages. Each one has a form and a queue; start these first because they finish last.

Email, support and legal

Low-glamour surfaces with the highest volume.

  • 28 Marketing email templates and the automated sequences already scheduled. A sequence written six months ago will keep sending the old logo on schedule.
  • 29 Email signatures for the whole team. Distribute one file and a date; do not rely on each person updating their own.
  • 30 Help centre, support macros and the screenshots inside them. Support content is the largest body of old screenshots you own. Prioritise the ten most-viewed articles.
  • 31 Status page, changelog, community and docs sites. Each is usually a separate product with its own logo upload and colour setting.
  • 32 Legal name and brand references in terms, privacy policy, and data-processing agreements. If the name changed, counsel decides what needs a formal notice. If only the mark changed, nothing here moves — confirm that in writing.
  • 33 Company name and logo in the tools your team uses in front of customers. Video calls, scheduling links, e-signature, the customer portal. Each shows a logo you set once.

App stores and third-party surfaces

Surfaces with a review queue — start them before the launch date, not on it.

  • 34 App Store and Google Play: icon, screenshots, name, description. Reviews take days. Submit ahead with a scheduled release, or the mobile app launches the old brand a week after the website.
  • 35 Browser extensions, desktop app installers, and their store listings. The installer icon on a customer’s dock is the last thing that changes on its own.
  • 36 OAuth consent screens and app listings inside other platforms. The logo shown when a user connects your app to their Google, Slack or GitHub account is uploaded separately, and it goes through verification.
  • 37 Social profiles: avatar, banner, bio, pinned post. All of them on the same morning. A half-switched set of profiles reads as a hack, not a rebrand.
  • 38 Design-community and portfolio profiles. Dribbble, Behance, review platforms, the founder’s personal profiles. These rank for your name and carry the old mark longest.

Launch day, in order

The sequence matters more than the date. This is the one we run.

  • 39 48 hours before: customers and support get the one-paragraph note. What is changing, why, what is not changing (their data, their login, their pricing). Support has the FAQ before the first ticket.
  • 40 Redirects live first, then the site. Publish the redirect map before the new pages so no URL is ever unreachable, even for a minute.
  • 41 Product tokens flipped, in-product notice on. Same hour as the site. A customer who sees the new site and the old app assumes one of them is fake.
  • 42 Mobile releases approved in advance go live; store listings switch. This is why item 34 started a week earlier.
  • 43 Email signatures, social profiles, announcement post, customer email — in that order, same morning. The announcement links to the post; the post links to the product; nothing links to a page that still shows the old brand.
  • 44 Watch three numbers for the rest of the day: 404s, support tickets, crawl errors. A spike in any of the three points at one missed item on this list. Fix it the same day.

The 30 days after

The rebrand is finished when the old brand stops appearing, not when the new one launches.

  • 45 Weekly: the 404 log and Search Console coverage. Every 404 with traffic is a URL missing from item 16. Add the redirect; do not wait for the ranking to fall.
  • 46 Weekly: search your own name and re-scrape stale link previews. Old cards linger on the platforms that cache them; each has a debugger or a re-scrape tool.
  • 47 Retake the remaining old-brand screenshots, most-viewed pages first. Help articles, docs, the long tail of blog posts.
  • 48 Retire old assets from the CDN, the repository and shared drives after 30 days. Not before: something will still reference them. After: they will be reused if they exist.
  • 49 Write the migration journal into the brand book. What was missed, what took longest, which partner never switched. The next rebrand, or the next hire, starts from it.
  • 50 Read the traffic at day 30 against the 90-day baseline from item 02. A rebrand done in this order costs no organic traffic. If it did, the redirect map is where to look first.

Frequently asked

How long does a SaaS rebrand rollout take?

The visual system is the fast part. Migrating every surface — product tokens, app stores with their review queues, partner assets, email templates, the redirect map — is what sets the timeline: two weeks for the launch phase inside a seven-week engagement, then 30 days of cleanup while old link previews, search thumbnails and partner pages catch up. Surfaces with a review queue (app stores, OAuth consent screens, marketplaces) are started a week before launch so they finish on the day.

What is the biggest risk in a SaaS rebrand?

Losing organic traffic on the cutover. A rebrand that changes URLs without a one-to-one redirect map for every page that received traffic in the last 90 days loses rankings for a quarter. The redirect map is built from Search Console and analytics exports before design starts, published before the new pages, and checked against the 404 log weekly for 30 days.

Do we need to change the domain when we rebrand?

Only if the name changes, and even then the old domain keeps redirecting for as long as you own it — years, not months. A new mark, palette or type system on the same name needs no domain change and no legal notice; confirm that with counsel in writing so the legal surfaces on the list can be closed in one line.

Who owns the rebrand checklist?

One person per surface, one date per surface, and one person for the whole list. In our engagements the migration plan is a deliverable: the studio fills the list in, engineering owns the product and store surfaces, marketing owns the site and social, sales owns collateral, and the founder owns the customer note. A shared spreadsheet with no owners launches in three waves, and customers notice the second one.

Want the migration run for you?

A SaaS rebrand at Funky Rabbit ships this list filled in — every surface with an owner and a date — as one of the deliverables, and we are in the room on launch day. Published pricing, fixed scope. Or send a URL for a free 15-minute audit first.

Start your project