Launches, Rebrands, and Migrations: when everything changes at once

How to plan a one-time project

A one-time project lands on a business that's already running

Maybe it's a rebrand you've already decided on. Maybe it's a move to a new CRM, or a new service that's designed and ready to launch. Whichever it is, it doesn't arrive in an empty week. The website has to change, and so do the systems, the documents, and the way your people work. Meanwhile the normal work doesn't stop. Clients still want answers by Tuesday.

So it waits, and every week something more urgent goes ahead of it.

One-time projects are harder than they look, for four plain reasons

Most of your business runs on repetition. You've sent the invoice, onboarded the client, and answered the same question so many times that the process lives in the doing. A one-time project has none of that.

Nobody on your team has done this one before. Not this rebrand, not this system, and not with your customers and your files. Every step is a first attempt.

It touches everything at once. A normal task lives in one corner of the business. A launch, a rebrand, or a migration reaches into the website, the inbox, the paperwork, and the people at the same time. The pieces depend on each other.

It sits on top of day jobs. The people who would do it already have full weeks. The project gets the gaps. For you, the hours are rarely what runs out first. It's the attention the project takes up, even on days when nobody touches it.

It won't repeat, so there's no process for it. This is the one that does the damage. Without a process, every piece needs a decision before anyone can start it. What does the new version say? Who signs it off? Does this old thing move, or stay behind? The work itself is often not that hard. The decisions are what pile up. And a pile of decisions waiting on one person looks exactly like a stalled project.

Start by listing every place the project touches

Before there's a plan, there's a list. Write down every place the old brand, system, or offer lives today. The website and email come first because they're obvious. Then the documents and templates, the listings and directories, and the accounts and logins.

Then add the two places that aren't files at all: your team's own habits, and what your customers have been told. Those get missed most often, because nobody can open them and check.

For a rebrand, the full list, with who changes each line, is in the rebrand rollout plan.

Decide the few things that block everything else

Look down the list and some items can't start until something is decided. The new name has to be settled before anyone designs around it. What moves to the new system has to be agreed before anyone moves it. Find those decisions, name who makes each one, and make them first.

Then draw the edges. For each piece, write down what's included, what isn't, and what counts as done. Write down where the project ends, too, or when you'll decide that. A launch has a finish line, and so does a rebrand. If the plan doesn't name it, the project drifts into permanent work. Name the goal behind it as well, in a sentence. When a small choice comes up halfway through, that sentence settles it faster than another meeting.

To get your project onto one page someone else could pick up, use our guide to planning a big project when you don't have a project team.

Rebrands, system moves, and launches each slip in a different place

The method is the same for all three. Where it tends to go wrong is not.

A rebrand that's already decided. The design is done. What's left is coordination: changing every place the old brand lives, in an order that doesn't leave customers finding half of each. The risk is in the places nobody looks at every day, like the invoice template nobody opens until it's time to bill. The order is in the rebrand rollout plan.

A move to a new CRM or system. The steps inside the software are the smaller part. The decisions come first: what moves, who owns it once it's there, who needs to be told, and who needs retraining. Settle those, and the move has somewhere to land. Then decide who runs the switch itself. It happens while the old system is still in use, so whoever runs it is doing two jobs at once. That can be someone on your team, or someone you bring in for it.

Launching a new service. Once the offer is designed, the launch is a project of its own. The pages, the systems behind them, and the documents all need to be ready. Someone also has to decide who hears about it, and in what order. The announcement is the part everyone sees. The work behind it is most of the job.

When two or three arrive together. They often do. After a business redesign, the website, the systems it runs on, and the marketing usually change in the same stretch. Planned as three separate projects, they compete for the same people and the same decisions. Each one stalls waiting on the others, and from inside any one project, nobody can see why. Planned as one, they share a single list. You make each blocking decision once, and the site, the systems, and the announcement line up behind it.

A website move is a people project as well as a technical one

Moving a website asks a lot of your people. They settle what the new site says, approve it, check it, and show everyone how it works, all on top of a normal week. Vibe-coding tools are quick at the building. The deciding and the approving still come out of your team's hours.

That speed is what makes it tempting to keep the whole move in-house, since it looks easy. But the build was never the slow part of a website project. Working out what the new site should say, and getting everyone to agree on it, is.

So the choice turns on one question: can your people take that part on and still keep up with the rest of their jobs? When they can, doing it yourselves is a perfectly good choice. If a site move is on your list, find out whether your team can take it on, or should hand it off.

Just need a website or blog content, and nothing else? FableForge and its Tech Team handle that.

Once it's all on paper, someone has to run it

Who runs a list this long is a question of its own. Outsourcing and Delegating helps you work out whether to get help, and what kind fits.

What comes after launch day, and where to start

After launch day, the new thing still has to be used by your people and written down so someone can run it.

The best launches barely dent the week: the new thing goes live, and your clients still get their answers by Tuesday. Sparkitive plans the whole list and sees every piece through, and your people take on only the parts you choose. On a free 30-minute discovery call, you can show Christina the list and hear what she sees in it.

Book a discovery call