Everyone plans the go-live project for months and then compresses the riskiest 60 hours into a weekend. A 90-person retailer with 6 stores did exactly that, and I was in the room for it. Here is the honest timeline, including the parts that nearly went wrong.
Friday 6 p.m.: the last invoice on the old system
The plan said the old system stops at 6 p.m. At 6:40 the store manager at the busiest location was still ringing up a customer on it, because a queue had formed. Nobody had told the stores that the cut-off was a hard stop, not a guideline for the office.
By 7:15 we froze it anyway and agreed to re-enter those four sales manually on Monday. The lesson costs nothing to learn in advance: write the cut-off in the store’s language and post it where the till is, not in the project plan.
Saturday: the part everyone underestimates
Data transfer finished at 11 a.m., ahead of schedule. Then the real work started, and it was not technical. It was the 1,400 customer accounts with two records each, a duplicate phone number format, and a spelling difference between “Street” and “St.”
The team had a rule from the planning phase that saved the weekend: merge only where the phone number and the last name matched exactly. Everything else went to a review list. That list had 118 names, and it took two people until 9 p.m. to work through.
What nobody had prepared for was opening stock. Six stores counted inventory the previous Wednesday. Deliveries arrived on Thursday and Friday. Nobody updated the counts.
So the numbers loaded on Saturday night were already two days stale. We loaded them anyway, then ran a physical verification at the two highest-volume stores on Sunday morning and adjusted. If we had waited for perfect counts, the stores would have opened Monday on paper stock.
Sunday: the quiet failure
Sunday afternoon the system worked. Everyone relaxed. That was the dangerous moment, because a quiet test proves nothing about the volume of a real Monday.
We spent Sunday evening doing something more useful than another test:
- Ring through 200 dummy transactions at one store, at 9 a.m. pace, to time the checkout screen.
- Print a receipt, a return, a refund, and a gift receipt. All four are different code paths and returns were the one that broke.
- Run a full day-end close on the dummy data to see how long it takes and what report it produces.
- Write the first-three-days hotline number on a card and tape it next to every till.
Monday 7 a.m.: what tells you it worked
The store staff arrived 45 minutes early, which never happens. By 9:30 the first shift had processed 340 transactions and the checkout screen was running 4 seconds slower than the old system. Not a failure, but worth knowing before a lunchtime rush.
ERPNext Consulting had set up two things that mattered more than any feature. A single dashboard that showed transactions per hour by store, so a store that went silent was visible within 20 minutes. And a rule that no price or stock adjustment could be made in the first five days without a manager log, which kept the first week’s data clean enough to trust.
ERPNext Consulting also insisted on a rollback decision point at Sunday 6 p.m. That point passed without being used, and having a real deadline is exactly why everyone stayed focused.
The takeaway for your own cutover: count your stores’ inventory as late as physically possible, define your merge rule in writing before the data arrives, and test a return, not just a sale. Returns are where the money and the confidence quietly leak out in week one.