With Jordan Parker, Migration and Integration Consultant.
"I work with businesses as they move their data and operations from one ERP system to another."
Here are the five things I would recommend an executive to check before approving Go-Live.
1. Let your team test real data early
One of the things I want to do on a migration project is get the customer’s own data in the new system. It doesn’t need to be perfect at that stage, that’s what the first data cut is for.
Once your team can see customers they know, products they recognize, their vendors, pricing and stock, the system stops feeling like a demonstration. They can start testing how their work will happen.
That’s also when we begin to get useful feedback. You can tell us what’s missing, what doesn’t look right and what you need to see differently.
Sometimes the data is correct, but because it appears in a new way, people are still unsure whether they can trust it. It's better to discover that early, while there's time to work through it.
I wouldn’t expect the first data cut to be right. I’d expect it to give your team something to question.
2. Find out what testing has found
When I hear that testing went smoothly, my next question usually is: ok, but what did you learn?
Testing should help you find the awkward products, unusual orders, pricing exceptions and data issues that could cause problems once the business is live.
This doesn’t mean every project has to find a serious problem, but you should expect testing to provide some kind of learning, rather than it just being a tick box exercise.
Ask: Which difficult or unusual scenarios have we tested?
3. Look for the person the project can’t afford to lose
I’ve seen how quickly risk becomes visible when knowledge, responsibility or timing depends on one person.
In one project, an employee who owned critical purchasing and data knowledge unexpectedly left shortly before go-live. The wider team was not prepared to take over. The migration hadn’t created that dependency; it had exposed one that already existed.
The same principle applies to the cutover plan. A plan should not only show what happens when everything arrives on time. It should account for delayed data, unavailable employees, third-party dependencies and tasks that take longer than expected.
My advice would be to build capability across two or three people rather than place all critical knowledge with one trusted employee.
Ask: Which critical activity would stop if one person became unavailable?
4. Make sure you’re improving the business, not rebuilding the old system
Customers naturally want the new ERP to look and behave like the system they already know. That familiarity can help people adjust, but I’d also challenge you on whether a process that has been used for ten years is still the right process.
You want to avoid spending significant time and money recreating the limitations the business was trying to leave behind.
5. Make sure somebody can say the business isn’t ready
The final decision is customer-driven.
I’d want an environment where the customer and implementation team can raise concerns openly, present the evidence and make a deliberate decision, not one where everyone stays quiet because the date has already been announced.
As go-live gets closer, changing the date can feel like failure. But sticking to it for the sake of the calendar can create a much bigger problem.
If testing has uncovered something important, a critical integration is not behaving as expected or your team still doesn’t feel confident carrying out a key process, that needs to be discussed honestly.
As an executive, you need to be confident that the decision to go live is being driven by evidence, not by the pressure to hit a date.
Ask: What would we need to see to decide we’re not ready?
Go-live should be an evidence-based decision
None of these checks will make an ERP migration risk-free. That’s not the goal.
What they should give you is evidence: your people have worked with real data, testing has taught you something, critical knowledge isn't sitting with one person, you're moving towards a better way of working and people can speak up if something isn't ready.
By the time you approve go-live, you shouldn't be asking “Do we think this will work?”, you should be able to say, “We've done enough to know we're ready.”
You should have enough evidence to know what’s been tested, where the remaining risks are and whether your people are genuinely ready to run the business in the new system.
There may still be things to manage after go-live. The difference is they shouldn’t come as a surprise.
Don’t approve the date. Approve the readiness.