✦ ERP and CRM
ERP implementation: the plan that decides whether it lands
ERP implementation is where most of the risk in an ERP project actually sits - not in choosing the software. Here's the stage-by-stage plan that determines whether a system lands well or limps along for years.
Haystak · 12 August 2026 · Updated 12 August 2026 · 9 min read
ERP implementation is the work that turns a piece of software into a system your business actually runs on: configuring it around your processes, moving your data in, testing it against real scenarios, training the people who'll use it, and getting through go-live without the business grinding to a halt.
Most ERP disappointment has nothing to do with the product chosen. It comes from a rushed or vague implementation plan - scope agreed too loosely, data migration left too late, training treated as an afterthought. Get the plan right and a mid-range product will outperform an expensive one implemented badly.
What ERP implementation actually covers
Buying an ERP licence or commissioning a build is a small part of the total project. Implementation is everything between that decision and the system being genuinely relied on day to day: configuration, data migration, integration with other tools, testing, training and support through the early weeks after go-live.
If you're still weighing up what an ERP system actually costs, it's worth knowing implementation is usually the largest single line, bigger than the licence itself for most mid-sized businesses.
The stages, in order
| Stage | What happens | Common mistake |
|---|---|---|
| Scoping | Agree which processes the system will cover and which it won't | Leaving scope vague so every request becomes a change |
| Configuration | Set up workflows, approval chains, roles and reports | Configuring around today's habits rather than the process you actually want |
| Data migration | Clean, map and move existing records across | Starting too late, once every other stage is already booked |
| Integration | Connect the ERP to other systems it needs to talk to | Discovering integration needs after configuration is finished |
| Testing | Run real scenarios, not just the standard demo data | Testing the happy path only, missing edge cases that show up in month one |
| Training | Get every role confident using the parts relevant to them | One generic session for everyone regardless of role |
| Go-live and stabilisation | Cut over, watch closely, fix issues fast | Treating go-live day as the finish line rather than the start of stabilisation |
Scoping: deciding what's in and what's out
A good scoping stage starts from your actual processes, not the software's feature list. Business process mapping beforehand gives everyone - your team and the implementation partner - the same picture of what the system needs to do, which cuts down on scope creep once configuration is underway.
Decide explicitly which processes the ERP will own from day one and which will stay outside it, at least initially. Trying to cover everything in one go is a common reason implementations overrun; a phased rollout by module or by site is usually steadier.
Configuration: fitting the system to the business, not the other way round
Configuration is where the product's standard workflows get shaped into your approval chains, numbering conventions, roles and reports. The temptation is to replicate exactly how things are done today, including the workarounds that exist because the old system couldn't do better. A good implementation partner will push back gently on that and ask whether each workaround should survive the move.
Data migration: the stage that most often runs late
Moving stock, customer, supplier and order history into a new system is slower and more manual than most timelines assume, because it depends on the quality of data you already have, not the new software. We cover the mechanics of doing this properly in our guide to data migration - profiling, cleansing, mapping, reconciliation and cutover - which is worth reading alongside this one rather than repeating here.
The practical point for an implementation plan: start data work in parallel with configuration, not after it. Leaving it until testing is meant to start is the single most common cause of slipped go-live dates.
Testing: beyond the happy path
- Test with your real data, not the vendor's demo data - edge cases in your actual records are what break things.
- Test the exceptions, not just the standard flow: a returned order, a part-shipped delivery, a credit note against an old invoice.
- Include the people who'll actually use the system daily, not just project team members who already know it well.
- Test integrations under realistic volume, not a single sample record.
Training and go-live
Training that's role-specific and hands-on, close to go-live rather than weeks before, sticks far better than a single generic walkthrough. Our guide to user adoption for a new system goes into what actually makes people use a new system rather than working around it.
Go-live itself should be planned as a stabilisation period, not a single day. Budget for a support-heavy first few weeks where issues get fixed fast and small configuration tweaks are expected, rather than treating every post-launch request as a failure of the project.
Off-the-shelf or built around you
Some businesses implement a standard product like Odoo, NetSuite or Dynamics 365 Business Central. Others need a system built around their process where the standard product's assumptions don't fit their operation. The implementation discipline above applies either way - the difference is how much of it is configuration versus development.
If your process has real quirks - unusual costing rules, multi-site stock, compliance records specific to your sector - it's worth having that conversation before committing to a product, not after the licence is signed. Get in touch and we'll give you a straight view.
✦ Where this fits
More on this from us: ERP systems.