Go-live gets the champagne. The project plan ends there, the consultants roll off, the steering committee stops meeting, and everyone exhales. Then week five arrives, and the picture is different: three people are maintaining spreadsheets alongside the ERP, the warehouse has invented a workaround nobody documented, and the old system is still running because nobody wants to be the one to turn it off.
This is where most ERP disappointment is actually manufactured. Not in the build. Not in the cutover weekend. In the ninety days afterward, when the work that converts a live system into a working system has no owner, no budget, and no place on anyone's calendar.
Go-Live Is a Load Test, Not a Finish Line
Up until launch, every assumption about your processes is theoretical. Testing happens with clean sample data, on a quiet Tuesday, by people who built the thing. Go-live is the first time your real transaction volume, your real edge cases, and your real staff hit the system simultaneously.
What surfaces in those first weeks isn't failure. It's information you literally could not have bought earlier. The mistake is treating that information as a punch list to be grudgingly endured rather than the most valuable input you'll get all year.
Start a Workaround Register on Day One
People are resourceful, which is the problem. When a new system makes a familiar task harder, nobody files a ticket — they route around it. Within a month, those detours harden into the way things are done, and you've paid for an ERP while running a shadow operation in Excel.
So hunt for them deliberately. Walk the floor. Sit with the AP clerk. Ask one question in every department: what are you doing outside the system to get your job done? Write down every answer, with a name attached. You're looking for things like a spreadsheet that tracks what the system won't, a CSV export that gets manually reformatted before it's useful, a report someone rebuilds by hand each Monday, or the sentence "I just email Dana and she fixes it."
Each one of those is a specification for work the project missed, or a signal that training never landed. Both are fixable. Neither fixes itself.
Sort Week Five Into Three Buckets
By the end of the first month, you'll have a messy list of complaints, bugs, and wishes. Triage it into three clearly separate lanes, because they need different owners and different urgency:
- Break/fix — the system is doing something wrong. Wrong tax calculation, failed integration, inventory that doesn't reconcile. Fix immediately; these erode trust fastest.
- Friction — the system is right but the path is painful. Eight clicks where there should be two, a screen missing a field people need. Batch these into a scheduled release.
- Deferred value — the capabilities you consciously postponed to protect the launch date. Dashboards, automation, the integrations that were "phase two." These need a funded plan, not a vague intention.
Mixing these together is why post-go-live backlogs stall. Break/fix screams loudest, so friction and deferred value never get touched, and the business concludes the ERP "doesn't do much."
Pick a Shutdown Date for the Old System
Parallel running is a legitimate risk control for a short window. It becomes a slow-motion failure when it has no end date. Two systems means two versions of the truth, double the data entry, and a permanent escape hatch for anyone who doesn't want to adapt.
Set a date before go-live. Communicate it. Then decide what has to be true to hit it — reconciled balances, a verified reporting replacement, archived records accessible for audit. The old system becomes read-only, then it goes dark. Until that happens, adoption is optional, and optional adoption is no adoption.
Measure the Operation, Not the Project
After launch, most reporting quietly shifts to project metrics: tickets closed, users trained, modules deployed. None of that tells you whether the business got better.
Pick a handful of operational measures and track them monthly from the start — order-to-cash cycle time, days to close the books, how many orders require manual intervention, how many touches it takes to move a quote to an invoice. If you captured baselines before go-live, you have a before-and-after. If you didn't, capture them now; a trend line starting in month two still beats guessing.
Fund the Second Release Before the First One Ships
The practical move is simple and almost nobody makes it: when you approve the implementation budget, approve the stabilization and phase-two budget at the same time, with a named internal owner and a standing monthly review. Not a contingency reserve to be fought over later — a planned release cadence that assumes you'll learn things at launch and intend to act on them.
Systems that return real value are the ones that keep getting improved after the project officially ends. That requires someone whose job it is to keep improving them.
If you're approaching a go-live, or sitting six months past one with a list of workarounds and a stalled phase two, that's exactly the conversation we have most often. Reach out to Infraxio and let's look at what your system is actually doing versus what you paid for it to do.