Customization, and the cost of one more thing
Every customization is a permanent cost, not a one-off one. You pay for it once to build and then again at every upgrade, for as long as you own the ERP system.
That is the whole argument, and it is why experienced implementers get twitchy about small requests.
Use the standard features first
The vendor's default process is not arbitrary. It encodes how a few thousand other organizations do the same job, and most of the time it works.
So the default answer to "can it do it our way" should be another question: why is our way different, and is that difference worth paying for every year? Sometimes it clearly is, and often it is habit that survived because nobody had a reason to look at it.
A useful test: if you cannot explain the customization to a new finance manager in two minutes, it is probably not a competitive advantage.
Limit and document what you do change
Set a customization budget in advance.
Not money — count. Agree the number of customizations the project will carry before requests start arriving. A cap forces prioritization; an open list never gets one.
Document every change as you make it.
What was changed, why, who asked, and what it touches. Undocumented customization is what turns a routine upgrade into a discovery project two years later.
Separate configuration from customization.
Configuration uses settings the vendor supports and upgrades cleanly. Customization is code. Most requests that arrive as customization turn out to be configuration, and knowing the difference saves both budget and upgrade pain.
What this prevents: an upgrade path that costs more every year until the ERP system is too expensive to keep current and too embedded to replace.
Testing, data migration, go-live and the month after
The riskiest day is not go-live. It is the third week afterwards, when the consultants have gone and month-end arrives.
Test with the people who will use it
Four kinds of testing, and skipping the fourth is how projects get embarrassed.
Unit and integration testing.
Does each piece work, and do the pieces work together? Integration testing is where unbudgeted middleware gets discovered, so run it early rather than late.
User acceptance testing.
Real users, real scenarios and real data volumes, not a scripted walkthrough with three sample records.
Performance testing.
Run it at the volume you actually process, at your busiest hour, not at the volume in the demo.
Fix what testing finds, before moving on.
A defect log that grows faster than it shrinks is the clearest early warning an ERP implementation gives you. Treat a growing log as a schedule signal, not a quality one.
Data migration is the phase everyone underestimates
Data migration is not a technical task but an editorial one, and it needs a business owner rather than a developer.
Audit before you move anything.
How many customer records do you have, and how many are real? Duplicate, dormant and malformed records are the norm rather than the exception.
Clean at source, not in transit.
Cleaning during migration means doing it again next time, while cleaning in the legacy system means the mess stops growing.
Decide what not to bring.
Ten years of closed transactions rarely need to live in the new ERP system, and an archive is cheaper, faster and safer than a migration.
Test the migration twice, with real data.
Two full dry runs against production volumes, because the first one always finds something and the second one proves you fixed it.
Go-live preparation
Choose phased or big bang deliberately.
A phased rollout by site or module lowers risk and lengthens the project. A big bang is shorter and less forgiving. Both are defensible, and what is not defensible is picking one because it was on the vendor's template.
Write the cutover plan by the hour.
Who does what, in what order, and who decides if something fails, because go-live weekend is not the moment to discover the sequence was implied rather than written.
Run a full dry run.
The whole cutover, rehearsed end to end with a stopwatch, is the highest-value day in the entire ERP project.
Agree the rollback point in advance.
Decide beforehand what would make you stop, and who can call it, because nobody makes that judgement well at 3am.
The first month after go-live
Hypercare is a real phase and it belongs in the plan with real names against it.
Keep the implementation team available rather than immediately reassigned. Watch performance and user feedback for the problems that only appear at full volume. Expect a dip in productivity for two to four weeks; the mistake is not the dip, it is treating it as failure and reversing course.
Then keep going. Benefit realization is decided in the months after go-live, not on the day, and the benefits that need the operating model to change are the ones the 2026 data says are hardest to land. Those need continued attention long after the project is formally closed — reporting and financial close in particular, which our piece on how ERP systems improve financial management covers in more depth.
Not sure which phase carries your risk? Send us your implementation plan and we will tell you which phase is thinnest, where the unbudgeted technology usually hides, and what your timeline looks like against a nine-month median. No charge, and no obligation.
