Going live without stopping the business

A system goes live on the morning the business starts keeping its records in it, not the afternoon the code reaches a server. That difference decides who stands where, what is printed on paper, and what happens when the first real order misbehaves. A deployment is reversed with a command; a cutover is reversed by people who have already done a day of work in the wrong place.

Is a big bang or a parallel run the safer cutover?

A parallel run protects the numbers and spends the staff. Most bad cutovers were decided by somebody who weighed only the first half of that sentence.

Parallel means every transaction is entered in both systems and reconciled each evening. For money it is safer. The cost is attention: the second entry happens at the end of a long day, by the person who also served customers, so it is the first thing skipped — and a skipped entry looks exactly like a reconciliation difference. Within weeks there are two truths and no way to say which is stale.

A big bang is one switch: a clean state and one bad day. It works when the scope is narrow, the opening data is reconciled, the fallback is paper, and the rollback trigger is written first.

Mix them: parallel for the numbers that must reconcile, over a window with an agreed end date; one switch for the typing.

Cutover	What it protects	What it costs
Big bang	A clean state on day one	Every error lands on one morning
Parallel run	A number you can compare	Double entry, and a gap that widens
Phased by module	Attention on one flow	Temporary links between old and new

Which day and which hour make a rollback possible?

The quietest trading day of the week, at an hour early enough that the people who can decide are awake and the day's work has not begun. Not Friday evening.

A rollback needs three things at once: someone with the authority to stop, someone able to restore the previous state, and enough hours left to restore and re-enter whatever happened since. A Friday night cutover loses all three by Saturday: the business is shut, the person who can restore is unreachable, and the first trading day is already the second day of the problem.

Avoid the first of the month, salary week, stock-count week, the day before a holiday, and any day the accountant is away.

What must be printed before anything switches?

The control totals you will compare against, on paper, signed by two people, with one copy out of the building.

Name them now: opening balances per account, stock quantity and value per item, open customer balances with their age, supplier balances, undelivered orders, unposted invoices, the cheque list. Plus the counts, per branch.

Paper matters because the old system will be off or read-only, and a file exported from the system you are replacing is the copy nobody trusts when the two disagree. Print the last version of each report you rely on, too: when the new one prints it in a different shape, the old sheet proves the difference is presentation, not a missing row.

Who stands at the counter on the first morning?

The clerk who does the job, driving. The person who built the system, beside them with their hands off the keyboard.

Deliberately. The clerk has to feel the screen fail in their own hands; whoever has not yet been slow will not ask for the field to be moved. The builder writes down every hesitation.

When the first order fails, and one will, the answer is already written: that order goes on paper, numbered, and a named person enters it later inside a stated window. Debugging at the counter, with a customer waiting, teaches the clerk that the software is fragile and that the safe response is to avoid it.

What does the written rollback say?

It says who decides, what going back restores, and what happens to work done after the switch. The trigger as conditions, not feelings: invoicing impossible for a stated period, stock wrong in a way that would ship the wrong goods, a payment that cannot be recorded at all. The decision-maker by role. The steps in order, each with a name. The data question settled in advance: whatever was entered since the switch is re-entered by name, or left and reconciled on return.

Then the expiry. Every rollback has one: after a few days of real trade, going back means re-entering days of work, and fixing forward is cheaper. Write the date down so nobody decides in a panic.

Security practice treats a recovery plan as something exercised and revised rather than written once and filed — NIST SP 800-34 is the reference we work from.

How do you run a cutover?

1. Freeze the scope a week out: fixes only, nothing merged that nobody has used.
2. Choose the day and hour against the trading calendar, with the decision-maker reachable.
3. Print and sign the control totals; take one copy off-site.
4. Load the opening data and reconcile it to those totals in writing.
5. Rehearse the switch on a copy, timed, rollback included, with the same people.
6. Write the first-day fallback: paper forms, a numbering rule, who enters them.
7. Name who stands where, and state that the clerk types.
8. Keep the old system read-only for a fixed period, not switched off.
9. Review at the end of day one and week one: what was entered twice, skipped, asked for.

Where this goes wrong

• A Thursday night before a long weekend. Everyone is tired, and the first person to test the switch is a customer on Monday.
• Nobody printed the totals, so the first reconciliation becomes an argument about which system lied, settled by memory.
• The rollback says "restore the backup" and nothing about transactions entered since. Restoring loses them; not restoring loses the rollback.
• The builder drives the keyboard for two days. The clerks never get past watching and the paper fallback becomes the process.

What this does not cover

No timeline and no figures: how long a cutover takes depends on volume, on the quality of the old data, and on how much must move. It does not say how long old records must be kept; accounting rules decide that, not the project plan. It assumes one system goes live — when two do in the same week, run them a month apart, because the same people cannot stand at two counters. It says nothing either about the old system that is a spreadsheet several people edit: that cutover is a data-cleaning project.

We plan cutovers against the trading calendar rather than the release calendar, because the day of the switch is still a day the business has to open.