Andy Dufresne escaped Shawshank with a rock hammer, a poster and nineteen years of patience. Escaping a legacy ERP takes less time but the same qualities. Seven moments from The Shawshank Redemption, and what each one says about leaving an old system behind and moving to Business Central.
Andy Dufresne didn't escape Shawshank in one dramatic night. He escaped it a handful of rubble at a time, for nineteen years, with a rock hammer small enough to hide in a Bible. Nobody noticed the work until the morning the cell was empty.
That is a better picture of most ERP projects than anything in a vendor's brochure. Leaving a legacy system behind isn't a single heroic act. It's persistence, patience, a plan nobody else can see yet, and a lot of quiet work behind a poster. Here's what the film has to say about it.
Red describes how prison walls work on you: first you hate them, then you get used to them, and eventually you depend on them. That's the institutionalised legacy system. The fifteen-year-old NAV install, the Sage company file with three spreadsheets bolted on, the month-end that only works because one person knows the order to press the buttons in.
Nobody chose it. It just grew around the business until the workarounds became the process. The first step in any migration is noticing the walls at all: list the spreadsheets, the re-keying, the reports that take a day, the person who can't go on holiday. That list is the case for change.
Brooks spent fifty years inside and couldn't cope with the world outside when he finally got there. Every business has its Brooks: the people who've used the old system for so long that the new one feels like a threat, not a release. They aren't being difficult. The old way is the only way they know.
Don't leave them to figure it out on go-live Monday. Bring them in early, show them the new system with their own data, make them part of testing, and give them a super user down the corridor for the first month. The people most attached to the old system often become the sharpest testers of the new one, because they know every exception it has to handle. (More in change management.)
Andy's tunnel was dug with a tool Red said would take six hundred years. It took nineteen, because Andy turned up every night and did a little more.
That's data clean-up, technical debt and retiring old customisations. Nobody gets a budget for "clean the customer master". But a team that merges ten duplicate customers a week, fixes the item units of measure a category at a time, and retires one unused modification a month arrives at migration day with data that reconciles first time. Start the chipping long before the project does. (See the data migration nobody wants to do and old customisations.)
Andy wrote to the state senate every week asking for library funds. For six years he got nothing. Then a cheque arrived, and he doubled his letters.
Getting an ERP replacement approved is often like that. The first business case gets parked, the second gets "next year". Keep making the case with numbers: hours lost to re-keying, days to close the month, the cost of the support contract on an unsupported version, the risk of the one person who knows how it works leaving. Boards approve what they've heard about repeatedly, with evidence. And when the budget arrives, use it properly.
The warden kept the real figures somewhere nobody else could see them, and it was his undoing. Most businesses have a gentler version: the spreadsheet that holds the real margin, the real stock figure or the real cash forecast, because nobody trusts the system's version.
A Business Central implementation should end the second set of books. One ledger, one stock figure, numbers the board trusts because they come straight out of the system and reconcile to the penny. If finance still keeps a parallel spreadsheet six months after go-live, the migration isn't finished. (See direct posting to control accounts for one of the usual reasons.)
For nineteen years, a poster hid the tunnel. Every cell inspection, nobody looked behind it.
Every legacy system has a poster too: the thing that looks fine from the front. The integration that "just works" because someone runs a script every Friday. The report that's right because a formula in column Z adjusts it. The backup that has never been restored. Before you migrate, look behind every poster. The health check is mostly that: finding the tunnels before they find you.
Andy always knew where he was going: a small town on the Pacific coast with no memory. He described it to Red years before he escaped. The destination made the digging bearable.
A migration needs its Zihuatanejo, described simply enough that everyone in the business can picture it. Month-end in five days. Stock on the system matches stock on the shelf. Sales can promise a delivery date without phoning the warehouse. Nobody re-keys an order. Put it on one page (the IT roadmap), put it in front of people often, and measure against it after go-live.
In the end it comes down to the choice Andy puts to Red. A legacy system doesn't stay still. It gets older, the people who understand it retire, Microsoft stops supporting the version, and the workarounds pile up. Standing still is a decision too, and it's the expensive one.
So choose. Start the clean-up, make the case, pick the partner, set the date. And when the go-live weekend comes, you'll find, as Andy did, that the hard part was all the nights of digging that came before it.
For the practical version: moving from Xero, upgrading from NAV, and the go-live weekend, hour by hour. Or book a 30-minute call and we'll help you plan the tunnel.
