In short
A relaunch needs three communicated fixed points: a timeline with named phases, a clear rule for how and where feedback happens, and a defined moment for final approval before going live. Without these three, delays almost always come from misunderstandings, not from execution problems.
Why relaunches fail on communication more than on tech
The technical migration is plannable. What often stays unclear is who sees what and when, who is allowed to approve, and what happens if feedback arrives after the deadline. These gaps are what cause delays.
Communicate the timeline as phases, not just one date
A single launch date with no intermediate steps leaves room for misunderstandings. Communicate named phases instead:
- Design phase with a review window
- Development phase with staging approval
- Migration phase (content, redirects)
- Launch window with a defined time
- Aftercare phase (first 1–2 weeks)
Define the feedback channel before the relaunch
Clarify up front where feedback on the new site gets collected — on the staging environment, directly on the element, not scattered across email and calls.
Address redirects and SEO openly
Clients rarely ask proactively about redirects for old URLs, but they get worried if rankings drop after launch. Communicate proactively that a 301 redirect strategy is part of the project.
Set expectations for short-term visibility fluctuations
After a relaunch, search rankings often fluctuate briefly even with a clean technical setup. Explaining this beforehand prevents panic in the first week after launch.
Actively request the final sign-off
Set a date for the last approval before going live and phrase it actively: “Without a reply by [date], the reviewed version is considered approved.”
Inform internal teams of the launch time
Sales, support and marketing should know the launch time before it happens, so inquiries about the “old” or “new” site don't fall flat.
Communicate the rollback plan, don't hide it
A brief note that the old version can be restored if something goes wrong takes the edge off pre-launch tension for the client.
Checklist for relaunch communication
Before the launch date, make sure:
- All phases and dates are communicated in writing
- Everyone knows the feedback channel for the staging phase
- Redirects are created and tested
- A date for final sign-off is set
- Internal teams (support, sales) are informed
After launch: a short message instead of silence
A brief confirmation after going live (“the new website has been live since [time], we're actively monitoring the first hours”) builds more trust than silence.
Clarifying roles: who talks to whom?
A relaunch usually involves more people on the client side than just the project team. Define who is the main contact for timeline questions, who consolidates content feedback, and who gives final sign-off. Without that clarity, questions land with random team members who can't answer them, which slows down the perceived progress even when the project is technically on schedule.
How to measure whether relaunch communication worked
Two simple indicators show whether the communication worked: does final sign-off arrive on the planned date, and do post-launch questions stay limited to technical rather than organisational topics? If instead you hear “I didn't know this was happening today”, one item in the communication checklist was phrased unclearly or sent too late.
Frequently asked questions
When should you communicate the relaunch date?
As soon as the timeline with all phases is fixed, ideally several weeks in advance.
How do you handle late feedback right before launch?
Flag it clearly as a post-launch item instead of delaying the date because of it.
Should the client see the staging environment?
Yes, with access protection — transparency during the build phase reduces surprises at launch.
How do you handle ranking drops after a relaunch, if they happen?
Check redirects first, then proactively inform the client of the status and the expected timeframe for recovery.
Who should give the final approval?
A named person with decision authority on the client side, documented in writing.
How do you announce the relaunch to the website's end users?
A short note through existing channels (newsletter, social media) is usually enough, depending on how much the structure or URLs change.
What if the launch date needs to move?
Communicate early with a concrete new date, instead of letting the original date pass without comment.