The Cutover Weekend: Seventy-Two Hours That Decide How the Project Is Remembered

At six in the evening on a Thursday, somebody posts the last invoice in the old system and sends a message to a group of forty people saying the freeze is on. Then a warehouse supervisor rings to say a container has just cleared and the driver is at the gate, and asks what he is supposed to do with it.

That call, or a version of it, happens on every cutover. It is not a failure of planning. It is the moment everyone discovers that a business does not have an off switch, and that the plan on the wall was written by people imagining a company that pauses.

Cutover is a different discipline from implementation. Implementation is design and configuration and argument, and almost all of it is reversible. Cutover is a sequence of dependent, timed, mostly irreversible operations performed under fatigue by people who have not done it before. The skills that got the project this far — analysis, patience, persuasion — are not the skills the weekend requires. The weekend requires a list, a clock, and one person willing to say no.

This is what that weekend actually contains.

The freeze is not a date, it is a set of exceptions

"We freeze on Thursday evening" is a statement about the system. Business does not freeze. Goods arrive, customers order, a subcontractor turns up wanting his gate pass, a machine breaks and somebody needs a spare.

So the freeze is really a decision about each of those flows: does it stop, does it queue on paper, or does it continue in the old system and get re-entered. Every one of those three answers is legitimate for some flow and catastrophic for others, and the work is deciding which is which in advance, in writing, with the person who will be holding the paper.

The flows that need an explicit answer, in almost every mid-market company: goods receipts, goods issues and deliveries, cash and card receipts, petty cash, payroll if it falls in the window, customer orders, purchase orders, production declarations, and anything a customer sees. For each, name the fallback, name who holds it, and name the person who re-enters it on Monday. A paper log with nobody assigned to re-enter it is a discrepancy you will find in week three, when it is expensive.

Two specific decisions cause most of the trouble.

The first is invoicing. If you stop invoicing on Thursday and cannot invoice until Tuesday, that is two working days of revenue documentation delayed, which your customers' payment terms may or may not forgive. Some companies pre-invoice; some accept the delay; a few discover on Monday that a customer's portal requires submission within a window that has closed.

The second is receiving. A container that arrives during the freeze either sits, or is received on paper into a quarantine location and entered on Monday, or is received in the old system after the cut-off — which corrupts the very balance you spent a week agreeing. Pick one, write it down, and tell the gate.

Final balances: counted, calculated, agreed

There are three kinds of opening balance and they fail in different ways.

Counted balances are stock. You count them because no ledger anywhere is trusted enough to be an opening position, and because the count is the last opportunity to find out that the difference between the system and the shelf is nine per cent rather than the one per cent everyone assumed.

Calculated balances are the general ledger, the sub-ledgers, the trial balance, the aged receivables and payables. They come out of the old system as a report at a fixed instant and are loaded as an opening journal. They are only as good as the instant: a report run at nine on Friday morning that includes transactions posted at eleven is not a balance, it is a fiction with a timestamp.

Agreed balances are the ones with a counterparty. Bank balances agree to a statement. Customer balances that matter agree to a statement the customer has confirmed. Intercompany balances agree to the other entity's ledger, which is where an hour of work on Friday saves a fortnight of argument in the following quarter.

The discipline that separates a clean cutover from a messy one is that every opening balance is signed. Not approved verbally. Signed, by the person who owns that ledger, on a document that states the instant it was taken. When someone in November asks why the opening retention balance was what it was, that signature is the answer, and without it the answer is a three-day forensic exercise.

The count, and the parts of it nobody schedules

A full physical count is the single most disruptive item in the weekend and the one most often compressed. Compressing it is a false economy: the count is the only chance to enter the new system with a stock position that the operations team believes, and belief is what determines whether they use the system or keep a spreadsheet.

The parts that get missed are consistent.

Work in progress. A partially completed production order is stock, and it is stock in a state your new system needs a defined way to represent. Deciding on the Saturday how to represent half-machined components is not a decision, it is a guess.

Goods in transit. Anything shipped by a supplier and not received, or shipped to a customer and not delivered, belongs to somebody and appears in nobody's count. It needs an explicit position.

Consignment and customer-owned material. Stock on your floor that you do not own, and stock at a customer's site that you do. Both are routinely counted wrongly in both directions.

Site stock and tools. For a contractor this is the whole problem: material issued to site, material at a store on site, and material that was issued three months ago and has been consumed without anybody saying so. If your business is projects rather than warehouses, the count is really a reconciliation of what the sites admit to, and it should start weeks earlier — one of several reasons a contracting cutover is harder than a trading one.

Scrap, rework and quarantine. Material that exists physically and should not exist in a valuation.

And the practical one: reconcile and approve the count sheets before the load, not after. A count whose variances are still being investigated when the load runs has produced a number, not a balance.

The open documents nobody thought about

The list of master data to migrate is always written. The list of open transactions is usually not, and it is where the ugly surprises live, because each of these is a partially completed state that has to be represented in a system that models states differently.

Partly delivered purchase orders. Ten ordered, six received, four outstanding. Does the new system carry the whole order with a partial receipt history, or only the outstanding four? Both are defensible. Only one matches what your buyer expects to see.

Partly invoiced sales orders and partly received customer advances. An advance payment sitting against an order that will deliver next month is a liability, an order commitment and a cash item at the same time.

Unbilled work in progress. Time and materials incurred, not yet on an invoice. This is the single most commonly missed item in professional services and contracting, and it is the one that makes the first month's revenue look wrong.

Retention. Amounts withheld on certified work, releasable on dates and conditions that live in a contract nobody has entered into a system before. Retention balances that arrive as a single lump sum with no contract, no release date and no counterparty are a problem you have moved, not solved.

Open letters of credit, bank guarantees and performance bonds. Each has an expiry, a beneficiary, a value and a document. They are usually held in a folder by one person in finance, and they are usually discovered during the weekend.

Open service contracts and warranties, which generate invoices and work orders on dates. Subcontractor commitments, ordered and partially certified.

Serial and lot history where traceability is a regulatory obligation rather than a convenience — medical devices, food, anything where a recall has to reach a batch.

Approved-but-unposted anything. Requisitions, expense claims, timesheets, credit notes in draft. Every one of them is somebody's expectation.

The rule that works: for each category, one named person writes down the count of open items, the total value, and the decision on how it will be represented — and does so at least three weeks before the weekend. Not because the number will be right that early, but because the decision needs argument time, and the weekend has none. The same reasoning is why data migration kills more projects than software does: the work is deciding what is true, and deciding takes longer than loading.

The sequence

Below is the shape of a cutover for a mid-market company with inventory. Yours will differ in detail. What should not differ is the discipline of writing every step with its dependency, its owner and the condition that means it failed — because at two in the morning on Saturday, nobody is going to reason it out from first principles.

Step	When	Depends on	Owner	It has failed if
Final backup of the old system, verified by restoring it somewhere	Before the freeze	Nothing	IT	The restore was not actually tested
Freeze declared, fallback logs issued, gate and reception briefed	Thursday evening	Freeze exceptions agreed in writing	Cutover manager	Anyone is still transacting an hour later
Final transactions posted and old system closed to entry	Thursday evening	Freeze	Finance and operations leads	A posting appears after the cut-off timestamp
Extract of all balances and open documents at a stated instant	Thursday night	System closed to entry	Data lead	The extract time and the close time differ
Physical count executed and sheets returned	Friday	Movement genuinely stopped	Operations	Counting is still running when the load window opens
Count variances investigated, adjusted and approved	Friday	Count complete	Operations and finance	Variances are still open at approval time
Master data final load and verification against agreed counts	Friday	Extract complete	Data lead	Record counts do not match the source figures
Opening balances loaded: GL, AR, AP, stock, fixed assets	Friday night into Saturday	Master data loaded and verified	Finance lead	The trial balance does not balance to the signed figure
Open documents loaded: POs, SOs, WIP, retention, contracts	Saturday	Opening balances loaded	Process owners	Any category has no named owner confirming it
Reconciliation pack produced and signed line by line	Saturday	All loads complete	Finance lead	Any line is unexplained rather than merely different
Integrations connected and tested with real payloads	Saturday	Loads complete	Integration lead	Any interface is tested with sample data only
Business validation: named users perform named transactions	Saturday into Sunday	Everything above	Process owners	The scripts were written that morning
Go or no-go decision	Sunday, at a stated hour	Validation results and reconciliation pack	The single decision owner	The decision is taken by consensus
Security, permissions and printing verified for real users	Sunday	Go decision	IT	Anyone discovers it on Monday
Communications issued: what to do, who to call, what is different	Sunday evening	Go decision	Change lead	People find out from a colleague
Open the system; first transaction executed deliberately	Monday morning	Go decision	Cutover manager	The first transaction is a customer's, not yours

The two dependencies that most often break are in the middle of that table. Loading opening balances before master data verification means loading against records that later change, and the fix costs more than the wait. Testing integrations with sample payloads rather than real ones means you have tested the connection and not the content, which is a different thing and the one that fails.

Build in slack that is genuinely slack. Schedule every step back to back and the first delay eats the buffer of all the rest, until by Saturday evening you are trading quality to protect a Sunday deadline. That is the mechanism by which good teams go live with bad data.

The roles, and the one that cannot be shared

A cutover needs a manager who owns the sequence and nothing else. Not the project manager, who is exhausted and emotionally invested in the date. Someone whose entire job that weekend is the list, the clock and the escalation.

It needs an owner per data stream, by name, who signs their own numbers, and a communications lead, because the largest source of Monday chaos is people who did not know what was happening.

And it needs exactly one person who says go or no-go. Not a committee. A committee at eleven on a Sunday night, with everyone tired and a public date behind them, will always find a reason to proceed. One person, named in advance, with the criteria written down a week earlier while everyone was calm, is the only structure that reliably produces a no.

Write the criteria before the weekend and make them binary. The trial balance agrees to the signed figure. Stock variance after adjustment is within an agreed tolerance. Every interface has passed with a real payload. Every open-document category has a signature. A named user has raised, approved, delivered and invoiced a real order end to end. If any is false, the answer is no, and the answer being no is not a failure — it is the control working. A structured way to assess whether you are anywhere near those conditions before the weekend arrives is what the go-live risk assessment is for.

The rollback that must exist and almost never does

Ask any project team what the rollback plan is and you will be told: we restore the old system and carry on.

Then ask three questions. How long does the restore take, tested, not estimated? What happens to the transactions entered in the new system between opening and the decision to roll back? And who tells the customers whose invoices carry new numbering?

The honest answer, in most mid-market cutovers, is that a genuine rollback is available for a few hours and becomes fiction shortly afterwards. Once the business has transacted in the new system for a day, restoring the old one means either losing that day's work or re-entering it manually, and the second option is a week of effort during the exact week nobody has capacity.

The useful discipline is therefore not to write a rollback plan you will never use. It is to name the point of no return explicitly, on the plan, at a stated hour — and to make the go decision before it rather than after. Before that point, the fallback is real: stop, restore, resume in the old system, take the reputational cost of a delay. After it, the only path is forward, and every problem is handled by fixing rather than reversing.

Companies that name that hour make better decisions on the Sunday. Companies that believe in an unlimited rollback proceed on the Sunday because they think they can undo it, and discover on Wednesday that they cannot.

The one genuine middle option is to keep the old system open for reference and reporting while every new transaction happens in the new one. That is not a rollback, it is a safety net for questions, and it is cheap. What it must not become is dual entry.

Monday morning

The system opens and the first hour sets the tone for the quarter.

Plan the first transaction rather than receiving it. Have a named person raise a real sales order, approve it, pick it, deliver it and invoice it, in front of people, before the queue forms. If it works, everyone in the room saw it work. If it does not, you found out at eight rather than at eleven with six customers waiting.

Put experienced people physically where the work happens: at the invoice desk, at the goods-in door, on the production floor. Not on a support email address. The first day's problems are not defects, they are people who cannot find a button, and a person standing next to them resolves in thirty seconds what a ticket resolves in a day.

Log everything, including the trivial, because the pattern in the first week's log is the most valuable diagnostic you will get about your training and your design.

Produce one report at the end of day one that reconciles: transactions entered, documents issued, and the resulting balances against what you expect. The discipline of reconciling daily for the first fortnight catches a systematic error while it is a hundred records rather than four thousand.

And keep the go-live team in place. The most dangerous period is not the weekend; it is the fourth to eighth week, when the consultants have demobilised, the workarounds are becoming habits, and nobody is watching. That is the argument made properly in why the most dangerous day of your project is not day one, and it is the reason the weekend should be planned as the start of a ninety-day period rather than the end of a project.

What separates the two outcomes

The cutovers that are remembered as milestones share three unremarkable things. The open-document decisions were made three weeks early and signed by named people. The sequence was written with dependencies, owners and failure conditions, and rehearsed at least once on a full-size copy of the data. And one person had the authority to say no on the Sunday, against a set of criteria written the previous week.

The ones remembered as incidents almost always share one thing: a date that had been announced publicly, and a team that could no longer imagine moving it.

Whether the numbers you then produce mean the system is working is a separate question, answered with a small set of measures rather than an adoption percentage — which is what to measure in the ninety days after go-live.

If you want the sequence, the open-document decisions and the go criteria written and rehearsed by someone who has run the weekend before, that is a defined piece of work, and it sits inside how we run an implementation.