A company rebrand usually means updating the website, sales materials, product names, visual identity, and anything else customers see. A documentation rebrand is part of that work too, and it’s worth planning before it starts.
At first, it can look like a fairly straightforward update: change the company name, replace the logo, and rename the product where necessary. But if you have a large knowledge base, this is also one of the few moments when you’re going to touch a significant amount of your documentation at once.
Don’t waste that opportunity by carefully rebranding content that shouldn’t even be there. If you’re already investing the time to update your documentation, this is a good point to decide what should survive the rebrand, what needs fixing, and what shouldn’t be carried into the new version at all.
Don’t migrate everything in a documentation rebrand
The easiest approach is to take the existing documentation and update it as-is. That’s also how you end up with exactly the same knowledge base under a new brand.
The same duplicate articles are still there. The same information is still difficult to find. The same articles are trying to cover three different user tasks. The logo was updated in 40 screenshots, but nobody had time to check whether the screenshots themselves were still accurate.
Before you start rewriting anything, look at what you actually have. Some content will only need a light update, some will need to be rewritten, some should be merged with other content, and some should probably disappear completely. There’s no reason to spend time rebranding an article that no longer helps anyone.
Check the documentation against the product
A rebrand is often treated as a content exercise, but documentation exists to explain the product, so the product is where you need to start.
Take the existing procedures and compare them with how the product works today. Does the workflow still match? Are the options still in the same place in the user interface? Does the terminology match what users see? Are there features in the product that never made it into the documentation? Are there documented features that no longer exist?
Old branding is usually not the only thing that has accumulated over time. Products change continuously, but documentation doesn’t always keep up. Use the rebrand review to find where the documentation and the product have drifted apart.
Question the screenshots too
Rebranding often means replacing screenshots because logos, colors, navigation, or product names have changed. Before recreating every screenshot, ask whether it still needs to exist.
Every screenshot creates maintenance work. The UI changes, and eventually that image needs to be updated again. Screenshots are useful when they help someone understand something that would otherwise be difficult to explain. They’re less useful when they simply repeat what the text already says.
While you’re going through the images, keep the ones that genuinely help and remove the ones that are only there because they’ve always been there.
Decide what each piece of content is there to do
One reason knowledge bases become difficult to maintain is that articles are added without much thought about how they fit into the documentation as a whole. Over time, the purpose of individual articles becomes less clear.
A single article might contain a procedure, some background information, troubleshooting advice, and a list of settings. Another might partly repeat the same procedure, while a third explains the same feature from a different angle.
A rebrand gives you a reason to look at those pieces again. For each article, ask what job it is supposed to do. Is it helping someone complete a task, explaining a concept, providing reference information, or helping them solve a problem? If you can’t answer that clearly, the article probably needs more than just a new product name.
Fix the structure before you rewrite the content
This is where rebranding projects can get expensive. If you start rewriting first, you make decisions article by article: where should this information go, should this section stay here, does this need its own article, should this title change?
You end up making hundreds of small decisions without a system behind them. Then you reach the next article and make a slightly different decision.
Define the structure first. Decide the rules once, before you touch the content, then apply them consistently while you work through the documentation. You’re not just updating individual pages but rebuilding the system they belong to.
Hand over a knowledge base your team can maintain
The rebrand will eventually be finished. Your documentation won’t be. New features will be released, existing workflows will change, new articles will be added, and someone will need to decide where they belong. If the only outcome of the project is a rebranded set of articles, you’ll eventually end up in the same situation again.
A better outcome is a knowledge base your team knows how to maintain. The aim is to remove the need to reinvent the structure every time someone writes something new.
That means documenting the rules a maintainable knowledge base depends on:
- What belongs in the knowledge base and what doesn’t
- Which article type to use for a given piece of content
- How articles should be scoped
- How articles should be named
- Where each type of information belongs
- Which terminology to use
- When content should be updated, merged, or removed
Same project, better outcome
That’s the decision point. You could update the logo, change the names, replace the screenshots, and move on.
Or you could use the same project to remove years of accumulated documentation debt. That takes more thought at the beginning, but you avoid ending up with the old knowledge base under a new brand. You get something cleaner, easier to maintain, easier to navigate, and better prepared for whatever comes next.
If you’re already going to touch most of your documentation, don’t spend that effort preserving problems you could remove instead.
At WrittenSide, I help SaaS and product teams audit, restructure, rewrite, and migrate technical documentation. If a rebrand is forcing you to rethink your knowledge base, I can help you decide what to keep, what to change, and how to build the new structure before the rewriting starts.
Don’t want to make these decisions yourself?
A documentation audit gives you the answers before you start: what’s worth keeping, what needs rewriting, and what should disappear.