Go-live is the start of the project, not the end

The new system goes live on a Monday. The data is migrated, the logins work, and the vendor’s project manager sends a note of congratulations. By the third week, orders are stuck in a status nobody recognizes, invoices are going out late, and someone in the warehouse is quietly keeping a spreadsheet “just until things settle down.”

Nothing is wrong with the software. The project was declared finished at the moment it actually began.

Go-live is a switch. Value comes later, once the people around the system know exactly how the work runs in it. That part is rarely in the vendor’s contract, and it is the part that decides whether the switch was worth it.

What the old system knew that nobody wrote down

Every system a business has used for years is full of knowledge that never made it onto paper. A notes field that the team uses to flag customers who need a call before delivery. A report someone runs every Thursday because it is the only place a certain problem shows up. A workaround for the one vendor whose invoices never match the purchase order.

None of that lives in the data migration. The records move. The reasons do not.

That makes the cutover one of the easiest places for a business to lose what it knows. The habits that held the old process together get switched off on a single day, and nobody notices which ones mattered until something breaks. The spreadsheet in the warehouse is not stubbornness. It is the old knowledge trying to survive somewhere.

Write the procedures before the cutover

The work that decides the outcome happens before go-live, not after it. Before the switch, write down how the core transactions will run in the new system, step by step, in the order your team will actually do them.

Start with the three that touch cash and customers:

1. Receiving. How a delivery gets checked against the purchase order, entered, and put away, and what happens when the count or the item is wrong.
2. Order entry. How an order goes in, who confirms price and availability, and how a change after entry gets handled.
3. Invoicing. How an order becomes an invoice, who reviews it, and what happens when a customer disputes one.

For each one, cover the exceptions, not just the clean path. The exceptions are where the old system’s hidden knowledge lived, so writing them down is how you carry it across.

Then test each procedure before go-live. Have someone who did not write it run a real transaction from the page, in a training or test setup. Wherever they stop and ask a question, the procedure has a gap. Fixing it now is cheap. Fixing it in week three, with customers waiting, is not.

Plan the stabilization instead of hoping for it

The weeks after go-live are a phase of the project, with an owner, a plan and an end. Treat them that way.

• Name a stabilization owner. One person who collects every problem, decides which ones are urgent, and makes sure each gets fixed.
• Keep one issues list. Every problem goes on it, with a date and an owner. Problems that only get mentioned in the hallway get solved twice, or not at all.
• Check in daily at first, then weekly. A short daily review in the first weeks catches problems while they are small. Move to weekly once the list stops growing.
• Watch a few numbers. Pick the measures that show whether the core work is holding: deliveries received against a purchase order, orders shipped on the promised date, invoices sent on time.
• End stabilization when the numbers hold and the issues list stays short, not on a date picked before go-live.

The side spreadsheets deserve their own decision. Go through each one with the person who keeps it. Either the new system can do the job, and the spreadsheet retires, or it cannot, and the workaround becomes a written procedure with an owner. Neither is a failure. Leaving it unexamined is.

A switch is only as good as the process around it

This is not a case against new software. Sometimes the old system truly cannot support the way the business needs to work. When that is true, a well-run switch is worth the effort.

But the software is the smaller part of the project. The larger part is the process around it: written down, tested, owned, and watched until it holds steady on its own. You can’t optimize what you haven’t defined, and a new system will not define it for you.

If a system change is on your calendar, look at the plan for the weeks after go-live. If the plan ends on go-live day, that is the first thing to fix.