Rethinking legacy websites after a redesign
It's college move-in season. Families are helping their students pack for a new chapter—deciding what to bring, what to store, and what it's finally time to let go.
Watching that process got me thinking about website redesigns.
One question comes up on nearly every redesign project I've been part of:
"Can we keep the previous website... just in case?"
It's a fair question. Every organization has different priorities, compliance requirements, and comfort levels with change. There's no universal right answer.
But over the years, I've realized that isn't the question I really care about.
The question I keep coming back to is this:
What problem are we still solving by keeping it running?
Preserving Isn't the Same as Maintaining
When someone moves to college, you don't throw everything away. You pack what they'll need, store what still has value, and eventually clean out the old bedroom—not because those memories aren't important, but because they no longer need to occupy the same space.
Website redesigns deserve that same kind of intentionality.
Just because something isn't part of everyday life anymore doesn't mean it has no value. Sometimes preserving it is enough—you don't have to keep living in it.
Too often, "keeping the old website" really means keeping an entire application alive. That's very different from preserving it.
An archived website can be a static copy, backup, or snapshot that's available if it's ever needed. A maintained website is still a living application. It requires software updates, security patches, SSL certificate renewals, backups, monitoring, and ongoing attention—even if almost no one visits it.
Those are two very different commitments.
The Question That Changed My Thinking
A few years ago, I worked on a redesign where we kept the previous WordPress site running after launch. For more than two and a half years, both websites existed side by side.
The legacy site wasn't publicly accessible. It lived in a staging environment, was gated to prevent public access, and blocked search engine crawlers. Even though it wasn't intended for visitors or search engines, it was still a live application that required ongoing maintenance.
The legacy site still needed WordPress updates, plugin updates, theme updates, SSL certificate renewals, backups, and periodic security reviews. None of those tasks were particularly difficult, but together they represented ongoing work for a website that had already served its purpose.
Looking back, I don't think keeping it was the wrong decision. At the time, it gave everyone confidence that nothing important had been lost.
What surprised me was something else.
We never revisited the decision.
The website wasn't still running because it was solving an important business problem. It was still running because it always had been.
That experience doesn't mean every organization should retire its legacy website. It simply reminded me that decisions made during a launch are worth revisiting once the dust has settled.
Today, instead of asking whether we can keep a previous website running, I ask:
What problem are we still solving by keeping it running?
Redirects and Legacy Websites Are Two Different Decisions
One of the biggest concerns after a redesign is SEO, and that's understandable.
Google recommends keeping 301 redirects in place for at least a year after a site migration so search engines and users can continue finding your content. Depending on your website, some redirects may remain useful much longer.
What that guidance doesn't say is that your previous CMS needs to remain online for a year.
Those are two separate decisions.
In many cases, redirects can be handled by your web server, hosting platform, CDN, or reverse proxy without maintaining an entire legacy application.
After a redesign, there are really two timelines to consider:
- How long should redirects remain?
- How long should the previous website continue running?
The answer to one doesn't automatically answer the other.
Every Website Has an Ongoing Cost
Hosting is usually the most visible expense, but it's rarely the only one.
Every live application requires someone to install updates, renew certificates, monitor security, verify backups, and respond when something breaks. Those responsibilities don't disappear just because traffic does.
That doesn't mean every legacy website should be retired. It simply means the ongoing maintenance should continue to provide value.
If the website is still serving an important business purpose, those costs are easy to justify.
If not, it may be worth considering whether an archive accomplishes the same goal with less complexity.
Revisit the Decision
Some organizations have legal, regulatory, or operational reasons to keep a previous website available. Others need it for historical reference, compliance, or internal workflows.
Those are all valid reasons.
The point isn't that legacy websites should never remain online. It's that the decision deserves to be revisited.
The reasons that made sense on launch day may not be the same reasons that exist two years later. Revisiting the decision gives organizations an opportunity to confirm the website is still providing value—or determine that it's time for a different approach.
Final Thoughts
One of the things I enjoy most about this industry is that every organization approaches these decisions differently. Different teams have different priorities, different constraints, and different levels of risk they're willing to accept. I don't always reach the same conclusion, but I always find it worthwhile to understand the reasoning behind it.
There's no one-size-fits-all answer.
Every organization has different priorities, different constraints, and different reasons for the decisions they make.
That's why I don't think the goal is finding the "right" answer.
I think the goal is making sure we're still asking the right question.
What problem are we still solving by keeping it running?
If that question has a clear business answer, then continuing to maintain the website is probably the right decision.
If the answer is simply, "Just in case," it may be time to preserve what matters, simplify your environment, and let the next chapter begin.
References
- Google Search Central. Site Moves with URL Changes
- Google Search Central. 301 Redirects
- OWASP Foundation. Web Security Testing Guide
- National Institute of Standards and Technology (NIST). Guide to Enterprise Patch Management Technologies
