Phased Rollout or Big-Bang Launch? How to Choose How Your Team Switches to a New Business System

Most owners spend months deciding what a new business system should do and about ten minutes deciding how the team will actually switch to it. That ten-minute decision, the cut-over strategy, decides whether launch day is a smooth Monday or a week of shouting, double typing and lost orders. It is far cheaper to choose it before the build than during the last week of it, because the choice changes what the builder prepares: data, accounts, test plans and what has to stay switched on.

This guide is for owners and managers of small and medium businesses who have commissioned, or are about to commission, a custom business system. It compares four ways to switch, shows how to choose between them, and covers the two things people skip: a written rollback plan and a go/no-go checklist. It is general guidance. It does not describe how any supplier launches projects, and it makes no promise about launch dates or after-launch help. Those belong in your written quote.

It sits between guides you may already know. How long the build takes is in how long a custom business system takes. Moving the old records is in moving your data into a new system. Getting people to use the system in the weeks after launch is in getting your team to use a new business system. This one covers the decision in between: how, and on what terms, you switch.

Start with the question: what would one bad day cost?

Every cut-over style is a different answer to one question: if the new system fails on its first real day, how much damage can we absorb? A florist whose orders arrive by WhatsApp can lose an afternoon and recover. A distributor whose invoices drive next month's cash flow cannot. Write the answer down in plain terms before comparing styles:

• What breaks first? Orders not taken, invoices not sent, stock counted wrongly, staff paid late. Name the one that would hurt most.
• How long can we cope by hand? A day, a week, or not at all. This sets how quickly you must be able to go back.
• Who is affected? Only staff, or customers and suppliers too. Outside parties raise the cost of a bad day sharply.
• Can the old way keep running? If the spreadsheet or old tool can stay available, you have more choices than if it will be switched off or is already unreliable.

Your answers will point towards caution or towards speed. The four styles below are positions on that line.

Four ways to switch, side by side

The names vary between books and suppliers, so here they are in plain words. In practice they are often combined, and the table is a map, not a menu of four pure options.

Two points often get missed. First, a pilot is about people and places (one branch) or one task (one workflow), while phasing by module is about parts of the software. Second, none of these replaces testing. A launch style decides how risk is spread; it does not remove risk that testing should have caught, which is the job of user acceptance testing.

Parallel run: old and new side by side

In a parallel run, the same work is recorded in both the old and the new system for a set period, and the results are compared. It is the most cautious style because the old way is still there to fall back on, and the most tiring because someone is doing the work twice.

• Keep it narrow. Run parallel only for records where a mistake costs real money, such as invoices, payments received or month-end totals. Asking every employee to type everything twice is how a parallel run turns into a revolt.
• Give it an end date. Write the date in the plan. A parallel run with no end becomes permanent double entry, which is the exact problem the new system was meant to remove.
• Name the comparer. One person owns the comparison, with a short list: the totals that must match, and what to do when they do not.
• Decide who wins. When old and new disagree, which is treated as correct while you investigate? Without a rule, every difference becomes an argument.
• Include a full cycle. If the figure that matters is the month-end close, the run must last through one. Two quiet weeks proves little about a month-end.

A short, targeted parallel run is often combined with another style, for example a pilot where only the pilot branch's cash totals are checked against the old sheet.

Pilot: one branch or one workflow first

A pilot switches a small, chosen slice to the new system while everyone else carries on as before. There are two ways to slice it.

• One branch or team. Everything that branch does moves over. This tests the whole system on real work in one place, and suits businesses with several outlets or departments.
• One workflow. Everyone does one task in the new system, say taking job orders, while other tasks stay on the old way. This suits a single site where the risk is in one process.

Choosing the pilot slice matters more than people expect. A good pilot group is typical enough to teach you something and forgiving enough to survive a rough start. Avoid the easiest branch, which hides problems, and the busiest, which cannot spare the attention. Pick a manager who wants it to work and will report problems honestly.

Decide, before the pilot starts, what “good enough to continue” means, in writing. For example: staff completed their normal daily tasks without the old sheet, the end-of-day totals matched, and the list of problems found has no unresolved item marked must-fix. Without agreed exit criteria, a pilot drifts. The length should cover at least one full cycle of the work, so a monthly task needs a month. Expect the pilot to find things; that is its purpose. Keep one list of problems, sorted into must fix before the next group, can wait and new idea.

The cost is time and awkwardness. Branches on the new system and branches on the old will not share a single view of the business until the last group moves, so reports for the owner may need stitching together by hand in the meantime. Plan for that before you start rather than discovering it in week two.

Phased by module: one part of the system at a time

Phasing by module suits larger systems made of parts that can work on their own, for example customer records, then orders, then stock, then invoicing. Each part goes live in turn, so the team learns one area at a time and the builder fixes one area at a time.

The risks are in the joins. While orders are in the new system and invoicing is still in the old one, someone has to carry information across, and that handover is where errors creep in. Ask three questions before agreeing to a phased plan:

• Can each module really stand alone? If orders cannot be used without stock levels, the order of phases is dictated by the dependency, not by preference.
• What carries information across while both exist? A temporary export, a manual re-key, or a simple link. Each has a cost in time and accuracy; ask for it to be named.
• What does each phase deliver on its own? A phase should leave the business better off, not just closer to a promise. If phase one gives staff nothing but extra typing, it will be resented.

Phasing is also how a system built from a small first version grows. If you scoped version one tightly, as in scoping a first app version, later modules arrive as later phases and each one gets its own launch decision using this same guide.

Big-bang: everyone, one date

A big-bang launch switches everyone on one set date and retires the old way. It has a bad reputation, and unfairly: for a small team doing simple work, it is often the right answer, because it is the shortest path and nobody lives in two systems.

It is reasonable when most of these are true:

• The team is small enough to train together and support in one place.
• The work is simple and the same for everyone, with no long chain of dependent steps.
• Testing used real data and real tasks, and the people who will use the system took part.
• Going back to the old way for a few days would be inconvenient but survivable.
• The date is quiet, and a rollback has been written and rehearsed.

It is a poor choice when the business runs several sites, when a mistake touches customers or cash, or when the data is untidy and untested. Big-bang does not have to mean “no safety net”. The safest big-bang launches keep the old system readable, and sometimes editable, for a defined period, as covered in the data guide’s section on a read-only safety net.

On the day itself, name where staff go for help and who decides. If your supplier will be available during the first days, get that in writing; this guide cannot tell you what any supplier provides.

How to choose: a decision table

Take each row, answer it for your business, and see which column keeps winning. If the answers split, a hybrid is usually the sensible result, for example a pilot first, then a big-bang for the remaining branches, with a short parallel run for end-of-day totals.

A worked example (made up): a three-outlet bakery

This example is invented to show the reasoning. It is not a real customer or a real project. Imagine a bakery with three outlets and a central kitchen. Orders and daily sales are kept in a shared spreadsheet and on paper, and a new system for orders, production lists and end-of-day sales is about to be delivered.

• Cost of a bad day: a missed morning production list wastes ingredients and disappoints regular customers; wrong sales totals confuse the owner's cash check.
• Old way available? Yes: the spreadsheet and paper can stay for a while.
• Decision: a pilot at the quietest-but-typical outlet for one full month, then the other two outlets together, with a short parallel run only for end-of-day sales totals.

The bakery did not need a long parallel run or a phased module plan; it needed a small proving ground, clear exit criteria and a calm second step. A one-shop business with two staff would reasonably have picked a big-bang. The skill is matching the style to the risk, not choosing the most elaborate one.

Choosing the date

Whatever the style, a date is a decision, not a deadline to be defended. A few rules of thumb:

• Avoid your busiest periods. Festive seasons such as Hari Raya, Chinese New Year and Deepavali, year-end sales, school-term starts or any campaign you run. A launch in the middle of peak orders removes the slack you need.
• Avoid the edges of the accounting cycle. The first and last days of a month, payroll day and year-end close are bad days to learn a new tool.
• Start early in the week, early in the day. A Monday morning start leaves the working week to find and fix problems; a Friday afternoon start leaves a weekend with no one watching.
• Leave room before and after. Allow a freeze on changes in the days before and a calm few days after, with the decision-maker and a champion available.
• Fix the date late, but announce it early. Move it only through the go/no-go decision, and tell staff well ahead so that nobody is surprised.

Rollback: decide how to go back before you go forward

A rollback plan answers: if this goes wrong, how do we return to working the old way, and who decides? It is uncomfortable to write one while excited about a launch, which is exactly why it must be written early. A plan invented in a crisis is a guess.

A usable plan is short and specific:

• Triggers, set in advance. For example: orders cannot be entered for more than a set time, totals differ from the old record by more than an agreed amount, or a must-fix problem appears that has no workaround. Agree the thresholds now, not under pressure.
• One decision-maker. A named person, with a named backup, who can say go back. Committees do not roll back quickly.
• What the old way needs. The old system or sheet must still be complete and usable. Take a backup of it on cut-over day, and keep it editable until the point of no return.
• What happens to work done in the new system. Entries made after launch must be re-entered, exported or deliberately abandoned. Decide which, and who does it.
• The point of no return. After a certain moment, such as the old data being archived or customers receiving documents from the new system, going back becomes costly. Name that moment, and require a fresh go/no-go before passing it.
• A rehearsal. Practise going back once on a test copy. A rollback nobody has tried is a hope, not a plan. A related rehearsal, the restore test, is explained in security basics for a custom business system.

Also write what you will tell staff and customers if you do roll back. Going back calmly and on purpose is a success of planning, not a failure of the project.

A go/no-go checklist

A go/no-go meeting is a short, scheduled decision, held a few days before launch with the people who can say no. Each item below should have a plain yes or no, an owner, and evidence, not a feeling. Any no that would cause a bad day means no-go.

A no-go is a decision, not an embarrassment. Record what is missing, who fixes it by when, and the new date. Moving a launch by a week is cheap; launching with a known gap is expensive. If your supplier resists a no-go that you can justify, that is useful information about how the project will go after launch.

Questions to ask your builder

• Which launch style do you recommend for us, and why? A good answer refers to your sites, your data and your risks, not to a habit.
• Can the old way keep running, and for how long? Ask what must be kept, and whether anything needs switching off.
• What does a rollback look like for this system? Ask for the steps, the time they take and who performs them.
• Can modules or branches be switched on separately? If so, ask whether that changes the quote or the timeline.
• Who will be available around launch, and what is promised in writing? The answer belongs in the agreement, not in a conversation.
• If the system includes a mobile app, how do test versions reach the pilot group’s phones, and how is a faulty version withdrawn? Ask before committing to a pilot date.
• What will you need from us before launch? Data checks, test users, decisions: ask for the list and the dates.

Put the same questions to every supplier so the answers can be compared. How to compare custom software quotes shows how to line them up.

Common mistakes

• Deciding the style in the last week. By then the data, accounts and tests have been prepared for the wrong plan.
• A parallel run with no end date. It turns into permanent double entry and quiet distrust of the new system.
• A pilot without exit criteria. Without a written definition of success, nobody knows when to proceed.
• Choosing the easiest or busiest pilot group. The first hides problems; the second cannot spare the attention to find them.
• Treating go/no-go as a formality. If the answer is always go, the meeting is theatre. Let a real no be possible.
• No rollback, or a rollback never tried. The first attempt then happens during the crisis.
• Launching at a peak period to meet a promise. A date chosen for a sales event, not for readiness, is a gamble.
• Switching off the old way too soon. Keep it complete and readable until you have passed the point of no return on purpose.
• Forgetting the week after. The launch is a start; plan the first month with the guide on getting your team to use the system.

Where Gotka Technologies fits

Gotka’s App & System Development service builds mobile apps, web apps and business systems, with indicative starting prices confirmed by a written quote once your needs are scoped. This guide is general advice. It does not describe how Gotka launches, phases or supports any project, and it promises no launch method or timeline. Whichever supplier you choose, ask for the launch approach, the rollback and the help available afterwards in writing before you sign. If you would like to talk through your situation, get in touch.

Related reading before a launch: what to prepare before your first conversation with a software developer.

Key terms used in this guide

• Cut-over: the switch from the old way of working to the new system.
• Big-bang launch: everyone switches on one set date, and the old way is retired.
• Phased rollout: the switch happens in stages, by location, team or module.
• Pilot: a first, small group (one branch, team or workflow) uses the new system while others wait.
• Parallel run: old and new are both used for a fixed period and their results compared.
• Rollback: returning to the old way if the new system fails after launch.
• Go/no-go: a scheduled decision, based on a checklist, on whether to launch or delay.
• Point of no return: the moment after which going back becomes costly or impractical.
• Exit criteria: written conditions that must be met before moving to the next stage.