The new site is being built. It might be ready in a few weeks, or it might be a few months, because redesigns have a habit of running past their planned date. Meanwhile the old site is still the one customers see, still taking enquiries, still sitting on a server. And because everyone’s attention is on the new one, the old one has quietly stopped getting any care at all.
Website maintenance during a redesign is easy to neglect and surprisingly important. For a while you are running two sites: one that is live and slowly being abandoned, and one that is unfinished and often more exposed than anyone realises. This post covers how to keep the old site safe and current until the day it is switched off, how to protect the new one while it is being built, and how to stop content getting lost between them.
Why the in-between period is risky
Three things tend to go wrong while a redesign is under way.
The old site is left unpatched. The reasoning is understandable: why spend time updating something that is about to be replaced? But “about to be replaced” can last a long time, and security releases do not pause for your project. An old site that is hacked during a redesign can delay the launch, damage your search listing and put customer data at risk.
The new site is exposed. Development copies are often set up quickly, on a subdomain or a temporary address, with simple passwords and every plugin installed to try things out. If search engines can reach it, it can appear in results before it is finished, competing with your real site.
Content drifts. Someone updates prices on the old site in month two. The new site was built from a content copy taken in month one. On launch day, the old prices come back.
Keeping the old site running during a rebuild
Treat the current site as a live business system until the moment it goes offline, because that is what it is.
Keep applying security updates
You do not need to apply every feature update or make improvements. You do need security releases for WordPress, the theme and the plugins, applied with a backup in place. If an update is large and risky, and the site is weeks from being replaced, it is reasonable to ask whether a security fix exists for the current version line instead.
Keep backups running
The backup schedule should carry on unchanged. If the redesign runs late, these are the copies you will rely on if something goes wrong.
Keep testing the form
Enquiries still come through the old site until the switch. Check the form still delivers, especially if anyone has been working on email settings or DNS records as part of the new project.
Do not start big changes on the old site
No new plugins, no theme changes, no structural edits. Anything you add now has to be rebuilt in the new site too, and every addition is another thing that can break while attention is elsewhere.
If the old site already has someone looking after it, tell them about the redesign and the expected date. A website maintenance services company that knows the site is being replaced can adjust the routine, holding back non-essential changes while keeping security and backups going.
Content freezes and the change log
The content problem has a simple fix, and it works only if everyone follows it.
Agree a content freeze date
Pick a date after which no non-urgent content changes are made to the old site. Before that date, the developer takes the content snapshot for the new site. After it, changes go into the new site only, or wait until launch.
Keep a change log for anything urgent
Some changes cannot wait: a price change, a new phone number, a legal notice. When one of those has to be made on the old site after the freeze, write it down in a shared list with the date, the page and the change. Before launch, every item on that list is checked against the new site. It sounds bureaucratic. It prevents a familiar launch-day complaint: something everyone thought was fixed has come back.
Decide who owns the list
One named person, not “the team”. They are the one who checks it before launch.
Protecting the new site while it is built
The new site is unfinished, which means it is often less protected than the live one.
- Put it behind a password. Not just a “coming soon” page that anyone can bypass, but proper access control at the hosting level or through WordPress, so only the people working on it can see it.
- Tell search engines to stay out. Use the WordPress setting that discourages indexing, and remember that a password is the stronger protection. Make sure both are removed at launch.
- Keep it updated too. A development site that sits for months with outdated plugins is a target just like a live one, and if it shares hosting with the live site, a compromise of one can affect the other.
- Remove test plugins as you go. Builds often involve trying several plugins for the same job. Delete the ones not chosen, rather than leaving them deactivated.
- Use real separate logins. Each person working on the build gets their own account, so access can be removed cleanly later.
If the new site is being built as a copy of the old one on the same server, the guide to how a WordPress staging site works explains how to keep the two from interfering with each other, particularly around shared databases and outgoing emails.
The switchover: where maintenance and launch meet
The general steps of planning and launching a redesign are covered in the step-by-step redesign guide. The parts that belong to maintenance are the ones people forget on the day.
- Take a final full backup of the old site. Files and database, stored somewhere off the server, labelled clearly. You may need something from it months later.
- Check the change log one last time. Every item confirmed on the new site.
- Leave the email records alone. If the launch involves DNS changes, make sure the records that route your email are not changed or removed by accident. Check mail is still arriving after the switch.
- Set up redirects from the old addresses. Every page on the old site that had traffic or links should lead to its new equivalent. The guide to fixing broken pages after a redesign covers finding the ones that slip through.
- Move tracking across. Analytics, ad conversion tags and any verification codes need to be on the new site from the first minute.
- Re-test every form on the new site, from a phone.
Website maintenance during a redesign that runs long
Many redesigns overrun. If yours is drifting from weeks into months, revisit the arrangements:
- Is the old site still receiving security updates, or did that stop when the project began?
- Has the content freeze turned into a content standstill that is costing you? It may be better to lift it and keep a fuller change log.
- Is the development site still protected, and still being updated?
- Are both sites still being backed up?
A long overrun is a good moment to check that nothing has been forgotten on either side, because by this point most people have stopped thinking about the old site entirely.
After launch: retiring the old site properly
Do not delete the old site the day the new one goes live. Keep it, offline and not publicly reachable, for a while, along with the final backup. Then, once you are confident nothing is missing:
- Cancel any hosting used only by the old site.
- Remove its files and database rather than leaving them on a server you no longer watch.
- Cancel or move any premium licences tied only to the old site.
- Remove old user accounts and any access given to people who worked only on the old version.
From there, the new site needs its own routine, and the post on the first months after a new site goes live picks up exactly where this one stops.
If you are planning a redesign
If the redesign has not started yet and you would like the building and the care of the old site handled by the same people, our redesign service page sets out what the service covers, so you can plan the in-between period from the start.
