Relaunch
The content freeze nobody agrees on
Of all the things that go wrong in a relaunch, this is the least spectacular.
5 min read
By Timo Wessels Published
Of all the things that go wrong in a relaunch, this is the least spectacular. It has no technical name, it produces no error message, and it is on no checklist.
It goes like this:
The content of the old site is transferred to the new one. Depending on the size, that takes days or weeks. Meanwhile the old site keeps running normally — it has to, it is the site currently bringing in customers.
And during the transfer, someone changes something on the old site.
The owner corrects a price. Someone in sales updates a reference. The intern puts a new post online. All completely correct actions on a running website.
Except: these changes are not on the new site. It was transferred before.
Why it only shows late
On switch-over day everything looks fine. The new site is complete, the structure is right, nothing is visibly missing.
What is missing are the changes of the last three weeks. And nobody notices them, because nobody is looking for them — they were there, after all, before the switch.
The price is back at the old value. The corrected phone number is the wrong one again. The post from the week before last has disappeared.
It gets noticed weeks later, one item at a time, and usually by a customer. And then it looks like a fault in the new site, although it is not.
The most annoying case is the corrected wrong detail that reappears. Someone reported an error, someone fixed it — and the relaunch undoes it.
The agreement
The solution is not a technical one. It is a sentence somebody has to say:
“From such-and-such a date, nothing more is changed on the old site. Everything after that goes into the new one.”
That sounds trivial. It still regularly gets skipped, and for an understandable reason: the date belongs to nobody. Whoever builds the site thinks about the transfer. Whoever maintains the content thinks about their work. That an agreement between the two is missing is only noticed once it has been missing.
The agreement has three parts:
From when. A date, not “when we are ready”.
For whom. Everyone who has access — not only the people who come to mind first. It is almost always more people than the client has in mind.
And where to instead. Whoever has to change something after the cut-off needs a route. Either access to the new site, or a place where change requests are collected. Without this third point the agreement gets broken, and rightly so — you cannot ask anyone to leave a wrong detail standing for three weeks.
And then you check it anyway
This is the part that comes from experience, not from theory.
The agreement gets broken. Not out of malice, but because someone did not hear about it, because an account was forgotten, or because something was urgent.
That is why agreeing on the freeze is not enough. You have to notice when it is not kept. There are tools for that which look at a website regularly and report when something has changed.
The effort is small, and the benefit is not control but catching up: if you know that a price was changed on Tuesday, you can add it to the new site. If you do not know, the change is lost.
That is the real point. It is not about forbidding anyone anything. It is about losing nothing.
The special case that is even more common
Sometimes the client transfers the content themselves — for larger sites that is common, because nobody else can judge the texts.
Then the same person bringing content onto the new site may at the same time be the one still correcting something on the old one. Or it is two people in the same team who do not talk to each other.
In this case the agreement matters more than in any other setup — and it is made less often, because everything happens within one organisation and is therefore considered settled.
What you do, concretely
Before the transfer starts: set the cut-off date, in writing, to everyone with access.
At the same time: say what happens to urgent changes after the cut-off.
From the cut-off: have the old site watched.
Shortly before the switch-over: compare once. What has changed since the transfer? Everything found is added.
After the switch-over: withdraw access to the old environment. Otherwise someone keeps maintaining a site nobody sees any more for months — and that happens more often than you would think.
Why nobody writes about it
For this article I looked at how often the topic comes up with German-speaking providers who do relaunches. Across all the collected sites, not once.
That is no reproach. It is because guides are written technically — about redirects, status codes, databases. A date on which people are supposed to stop typing fits none of these categories.
It still decides whether everything is there after the rebuild.
Sources
- Sitebulb webinar Website Migrations & Redirect Mapping Dos & Don'ts, November 2024, panel of four practitioners — the observation that when the client transfers the content themselves, someone else in the same team changes content on the running site in parallel; that this needs an explicit agreement on a cut-off date; and the explicit experience that the agreement is broken even when it was promised, which is why changes to the running site are monitored during the project.
- Udemy, Der perfekte Webseiten-Relaunch, phase 3 and phase 4 — that content is read out of the existing site and transferred, and that the client's go-ahead for switching over is obtained explicitly, because preparations are needed on their side too.
- Own measurement — across all collected competitor sites no term for a content freeze occurs, neither German nor English. Checked with two independently worded search patterns.
- Own practice — the three parts of the agreement, in particular the need for a route for urgent changes; the comparison shortly before the switch-over; and withdrawing access to the old environment afterwards.