Template · Website relaunch
Plan a website relaunch backwards from the launch date.
Eighteen linked tasks from kickoff to aftercare, each with an owner and a definition of done. Set the launch date the client wants and how long their reviews take. The planner works out when you have to start and how late the content can arrive.
Weekends move to the next Monday.
Client review turnaround
working days
Scope, design, and UAT sign-offs.
Content arrives late by
working days
Try more than the slack.
- Kick off by
- Thu, Nov 12
- 56 working days before launch
- Launch
- Fri, Jan 29
- 3 client reviews on the critical path
- Ask for content by
- Thu, Dec 24
- Latest without moving launch: Thu, Jan 7
Critical pathClient review or inputHas slackSlack
- 1 Kickoff and scope confirmation, Project lead, Thu, Nov 12 to Mon, Nov 16, on the critical path
- 2 Client signs off scope, Client sponsor, Tue, Nov 17 to Mon, Nov 23, on the critical path
- 3 Content audit and sitemap, Strategist, Tue, Nov 24 to Mon, Nov 30, on the critical path
- 4 Wireframes for key journeys, UX designer, Tue, Dec 1 to Mon, Dec 7, on the critical path
- 5 Visual design for core templates, Designer, Tue, Dec 8 to Thu, Dec 17, on the critical path
- 6 Client design review and sign-off, Client decision-maker, Fri, Dec 18 to Thu, Dec 24, on the critical path
- 7 Content brief and copy deck, Content lead, Tue, Dec 1 to Thu, Dec 3, 10 working days of slack
- 8 Client supplies copy and assets, Client content owner, Fri, Dec 4 to Thu, Dec 24, 10 working days of slack
- 9 CMS setup and content model, Developer, Tue, Dec 1 to Mon, Dec 7, 13 working days of slack
- 10 Build page templates, Developer, Fri, Dec 25 to Thu, Jan 7, on the critical path
- 11 Redirect map and page metadata, SEO lead, Tue, Dec 1 to Thu, Dec 3, 40 working days of slack
- 12 Analytics and conversion tracking, Developer, Fri, Jan 8 to Mon, Jan 11, 13 working days of slack
- 13 Populate content, Content lead, Fri, Jan 8 to Thu, Jan 14, on the critical path
- 14 QA: journeys, forms, and devices, QA lead, Fri, Jan 15 to Thu, Jan 21, on the critical path
- 15 Accessibility review, QA lead, Fri, Jan 15 to Mon, Jan 18, 3 working days of slack
- 16 Client UAT and go/no-go, Client sponsor, Fri, Jan 22 to Thu, Jan 28, on the critical path
- 17 Launch and production smoke checks, Developer, Fri, Jan 29, on the critical path
- 18 Aftercare: 404s, forms, analytics, Project lead, Mon, Feb 1 to Fri, Feb 12, 0 working days of slack
The download has these dates filled in, in Fluidwork's import format. Import it from Issues → Import CSV, then place the issues on a timeline and link them.
Working days only, Monday to Friday. Public holidays and team availability aren't included, so check them before you commit to a date. Prefer a blank copy? Download the undated CSV.
What the plan tells you
Three things decide most launch dates.
01
Client reviews compound.
Scope, design, and UAT sign-offs all sit on the critical path. With 5-day reviews, that's 15 working days of waiting, and every extra day of turnaround moves launch by 3. Agree the turnaround in the statement of work, not in week six.
02
Content has slack. Spend it carefully.
Copy and assets are needed when the templates are built, not when the deck goes out. In this plan that leaves 10 working days of slack. Give the client the early date, and know the late one. Every day past it is a day off the launch.
03
Unpinned work gets forgotten.
Redirects, metadata, and analytics have weeks of slack, which is exactly why they slip to launch day. Linking them to the launch task means the go-live can't be scheduled without them.
The template
Every handoff says what done means.
A task like “content” can't be handed off. “Reviewed copy and images for every launch page” can. Each task names an owner, what it waits on, and the condition the next person can check before they start.
| Task | Owner | Days | Waits on | Done when |
|---|---|---|---|---|
| LAUNCH-1Kickoff and scope confirmation | Project lead | 3 | — | Deliverables, page count, integrations, and success measures are written down. |
| LAUNCH-2Client signs off scope | Client sponsor | Review | 1 | The sponsor has approved the written scope, and who signs off each later stage is named. |
| LAUNCH-3Content audit and sitemap | Strategist | 5 | 2 | Every launch page is listed with its template, owner, and old URL. |
| LAUNCH-4Wireframes for key journeys | UX designer | 5 | 3 | The top journeys work end to end in low fidelity. |
| LAUNCH-5Visual design for core templates | Designer | 8 | 4 | Each template in the sitemap has a desktop and mobile design. |
| LAUNCH-6Client design review and sign-off | Client decision-maker | Review | 5 | Feedback is consolidated into one round and the designs are approved. |
| LAUNCH-7Content brief and copy deck | Content lead | 3 | 3 | The client has a page-by-page deck with word counts, image specs, and a due date. |
| LAUNCH-8Client supplies copy and assets | Client content owner | 15 | 7 | Reviewed copy and images for every launch page are in the deck. |
| LAUNCH-9CMS setup and content model | Developer | 5 | 3 | Content types match the sitemap and editors can log in. |
| LAUNCH-10Build page templates | Developer | 10 | 6, 9 | Every approved template renders real CMS content on staging. |
| LAUNCH-11Redirect map and page metadata | SEO lead | 3 | 3 | Every old URL maps to a new one and every page has a title and description. |
| LAUNCH-12Analytics and conversion tracking | Developer | 2 | 10 | Key events fire on staging and appear in the analytics property. |
| LAUNCH-13Populate content | Content lead | 5 | 8, 10 | Every launch page on staging has final copy and images. |
| LAUNCH-14QA: journeys, forms, and devices | QA lead | 5 | 13 | No open blocker or critical issues on the agreed browsers and devices. |
| LAUNCH-15Accessibility review | QA lead | 2 | 13 | Keyboard, contrast, and screen reader checks pass on every template. |
| LAUNCH-16Client UAT and go/no-go | Client sponsor | Review | 14, 15 | The sponsor has recorded a go decision for the launch date. |
| LAUNCH-17Launch and production smoke checks | Developer | 1 | 11, 12, 16 | DNS points at the new site, redirects resolve, and forms and analytics work in production. |
| LAUNCH-18Aftercare: 404s, forms, analytics | Project lead | 10 | 17 | Two weeks without new 404s or form failures, and the first traffic report is sent. |
Launch week
The runbook for LAUNCH-17.
The launch task is one day on the plan and a week of preparation in practice. This is the checklist behind it.
Five working days out
- Lower the DNS TTL on the records you will change to 300 seconds, so the cutover propagates in minutes.
- Confirm who holds registrar, DNS, hosting, and analytics access, and that they are available on launch day.
- Book the go/no-go meeting with the client sponsor for the day before launch.
Two working days out
- Freeze content on the old site. Anything published after this point has to be re-entered by hand.
- Crawl the old site and run every URL through the redirect map on staging. Each one should return a single 301 to the right page.
- Check that staging blocks search engines and that production will not.
Launch day
- Switch DNS or deploy, then confirm the certificate is valid on every hostname, including www.
- Remove noindex, check robots.txt, and submit the XML sitemap in Search Console.
- Submit every form and confirm the message reaches the client's real inbox, not a test address.
- Watch the analytics real-time view while someone walks the key journeys.
- Keep the old site running until the redirects are confirmed. Know who can switch DNS back, and how fast.
The two weeks after
- Review the 404 log daily and add redirects for anything the map missed.
- Compare organic landing pages week over week against the old site's baseline.
- Send the client a short aftercare report, then raise the DNS TTL back to its usual value.
In Fluidwork
From CSV to a timeline the client can follow.
- What does the import create?
- Eighteen local issues, LAUNCH-1 to LAUNCH-18, with titles, owners and done-when criteria in the description, and the planner's dates if you downloaded the dated copy. Add assignee emails in the spreadsheet first if you want them assigned on import.
- Are the dependencies imported?
- No. CSV import creates issues, not links. Each description lists what the task starts after, so linking them on the timeline takes a few minutes. Once they are linked, moving a task moves everything that waits on it.
- What if I import it twice?
- The rows carry explicit identifiers, so a second import updates LAUNCH-1 to LAUNCH-18 instead of creating duplicates. The import preview shows which rows will be created and which updated before you commit.
- Our team already works in Linear.
- Use the template as a coverage check and plan from the Linear issues you already have. Client reviews and inputs can sit on the same timeline as local issues. See how planning with Linear works.
- How do we share it with the client?
- Snapshot the plan at scope sign-off as your baseline, then share the live timeline so the client always sees current dates. Here's exactly what they can see.
- Why does aftercare come after launch?
- Because launches break things that only real traffic finds: missed redirects, forms routed to old inboxes, tracking that fires twice. Two weeks of deliberate monitoring is cheaper than the support tickets.
Free for one planner