Why your ERP upgrade keeps slipping, and how to make it a non-event

The system that takes your orders is usually the oldest software in the building. Not because anyone decided that, but because the upgrade has been proposed four times and postponed four times, and every postponement was individually reasonable.

The reason is always the same. Nobody can tell you what will break. Without that answer, an upgrade is an open-ended risk to the one system that cannot go down, and no sensible owner signs up for that in Q4. So it slips, the version gap widens, and the eventual upgrade gets harder, which makes the next estimate longer, which makes the next postponement easier to justify.

The postponement spiral

Three things get worse while you wait.

Support and security. Older versions stop receiving fixes. At some point your core business system is running on software that will not be patched again, which is a conversation your cyber-insurance carrier will eventually want to have.

The size of the jump. Upgrading across one version is a project. Upgrading across five is an archaeology dig, because every customization written over those years has to be reconciled at once instead of one release at a time.

Institutional memory. The person who knew why that field was added left in 2022. Every year you wait, more of your customizations become things nobody can explain, and unexplainable customizations cannot be safely dropped or safely kept.

Where the risk actually lives

It is worth being precise about this, because the fear is usually aimed at the wrong thing. Core software upgrades themselves are routine and well-trodden. The risk lives in three specific places:

• Your customizations. Custom fields, custom reports, custom workflows, and anything a previous consultant wrote. This is where nearly all breakage happens.
• Your integrations. The shipping connector, the payment gateway, the e-commerce sync, the spreadsheet somebody’s macro pulls from the database at 6am. These break quietly and are noticed days later.
• Your data. Fifteen years of records built up under older rules, including records that would not be accepted by today’s validation.

Notice that none of those are unknowable. They are all inventoriable, in advance, on a copy of your system where nothing you break matters.

Rehearse it

We treat a core system upgrade the way you would treat moving a production line: you do not find out on the day.

Build a full copy first. A complete duplicate of the live system (data, customizations, integrations) running somewhere isolated. Everything after this happens on the copy.

Upgrade the copy and fix what breaks. This is the bulk of the work, and it is entirely risk-free, because the only thing on fire is a disposable environment. At the end you have a written list: every customization that needed changing, every integration that needed reconnecting, every data problem that needed cleaning.

Rehearse with your people, on a clock. Your order desk, your accounting lead, your shop floor supervisor sit down at the upgraded copy and do a normal day’s work. They find the things engineers do not: the report that lost a column, the button that moved, the workflow that now needs one extra click four hundred times a day. We time the whole cutover while they do it, so the real weekend is a schedule and not an estimate.

Do it twice. The second rehearsal exists to prove the first one’s fixes held, and to produce a cutover runbook precise enough that the actual upgrade is transcription rather than problem-solving.

Then cut over on a weekend, with the old system still standing. Freeze Friday evening, upgrade Saturday, verify Sunday with the same people who rehearsed. Keep the back-out plan armed for a week afterward. It is usually not needed, and it is what makes the decision reversible, which is what makes it approvable in the first place.

What this changes

Rehearsal does not make an upgrade cheaper. It moves the uncertainty from the weekend of the cutover, where it costs you orders, into the weeks before it, where it costs engineering hours. That is a trade almost every business should take.

It also changes the conversation with the owner. Instead of “we would like to upgrade the ERP, it should take a few weeks and we think it’ll be fine,” the proposal becomes: here is the list of everything that breaks, here is what each fix takes, here is the timed rehearsal result, and here is the Sunday afternoon we expect to be finished. That version gets approved.

The last one we ran this way finished at 4pm Sunday, two hours ahead of the deadline, and the order desk opened Monday at 7am on the new version with no emergency fixes in the first week. It is written up in more detail on our case studies page. Nothing about it was lucky. It was just rehearsed.