An ERP (enterprise resource planning) system brings finance, purchasing, inventory, sales, manufacturing and often HR into a single shared database. When it works, everyone sees the same numbers and work flows between departments without re-keying. Getting there is the hard part. ERP implementation touches almost every process in the business, and its success depends more on preparation, people and data than on the software you choose.
This guide follows a typical implementation from decision to stable operation.
Before you start: agree why
Write down the business outcomes you expect, in measurable terms. Examples: month-end close in five days instead of fifteen; accurate stock levels across warehouses; one view of each customer's orders and payments. These goals guide every later decision, especially the many small arguments about whether to change a process or customise the software.
Also be honest about what the ERP will not fix. If processes are unclear or departments disagree on how work should be done, software will expose that, not resolve it.
The ERP implementation team
Most failed projects were under-resourced on the client side. You will need:
- An executive sponsor with authority to settle disputes between departments and protect the budget.
- A project manager who tracks plan, risks and decisions.
- Key users from each department who know current processes in detail and will test and champion the new ones. They need real time freed up, not "in addition to the day job".
- An implementation partner with experience of the chosen ERP, unless you have that expertise in-house.
- Technical support for integrations, data migration, hosting and security.
Phase 1: Discovery and design
The partner and key users map current processes and agree future ones. The output is often called a fit-gap analysis: for each requirement, does the ERP handle it as standard, through configuration, or only with customisation?
The guiding principle should be to adopt standard processes wherever they are good enough. ERP systems encode common good practice for accounting, procurement and stock control. Customising them to mirror old habits raises cost, complicates upgrades and adds long-term maintenance. Reserve customisation for processes that genuinely set you apart or are required by law.
Phase 2: Configuration and build
The system is set up: chart of accounts, tax rules, warehouses, product categories, approval workflows, user roles, document templates. Any approved customisations and integrations (with e-commerce, banking, payroll or shipping systems) are developed.
Work iteratively. Show key users configured processes early, using realistic examples, rather than revealing everything at the end.
Phase 3: Data migration
Data migration is regularly the most underestimated part of ERP implementation. Plan for:
- Scope: decide what to bring across. Master data (customers, suppliers, products, chart of accounts) and open transactions (unpaid invoices, open orders, current stock) are usually essential. Years of closed history often are not; archive it and keep it accessible instead.
- Cleansing: remove duplicates, fix inconsistent units and codes, and fill gaps. Assign business owners to each data set; this is not purely an IT task.
- Mapping: define how each field in the old system corresponds to the new one.
- Trial loads: run the migration several times before go-live and have users reconcile the results, for example comparing balances and stock values.
Phase 4: Testing
Test at several levels:
- Unit and configuration testing by the partner: each setting and customisation works.
- End-to-end process testing: complete business flows, such as order to cash or purchase to pay, across departments.
- Integration testing: data flows correctly to and from connected systems.
- User acceptance testing (UAT): key users confirm, with real scenarios, that the system supports their work.
- Performance testing with realistic data volumes, especially for month-end and reporting.
Do not compress testing to protect the go-live date. Problems found after go-live cost far more to fix, and they hit customers and suppliers directly.
Phase 5: Training and change management
People need to understand not only which buttons to press but why processes have changed. Train by role, using the organisation's own data and scenarios. Key users make excellent trainers for their colleagues. Communicate early and repeatedly about what is changing, when, and where to get help.
Phase 6: Go-live
Choose a cut-over approach:
| Approach | How it works | Suits |
|---|---|---|
| Big bang | All modules and sites switch at once | Smaller, simpler organisations |
| Phased | Modules or sites go live in stages | Larger or multi-site businesses |
| Parallel running | Old and new systems run side by side for a period | High-risk areas, though it doubles workload |
Prepare a cut-over checklist covering final data loads, opening balances, freezing transactions in the old system, and a go/no-go meeting with clear criteria. Many businesses time go-live for the start of a financial period to simplify reconciliation. Arrange extra support, sometimes called hypercare, for the first few weeks.
Phase 7: Stabilise and improve
Expect a dip in productivity while people adjust. Track issues, fix what matters and resist adding new features until the core is stable. Then return to the goals you set at the start and measure progress. ERP is a platform for continuous improvement, not a one-off project.
Mistakes that derail ERP projects
- Treating it as an IT project rather than a business change.
- Key users without time allocated to the project.
- Heavy customisation to reproduce old processes.
- Leaving data cleansing until the last month.
- Cutting testing or training to meet a date.
Open source ERP platforms are a credible option for many mid-sized firms, and our open source solutions page explains how selection, customisation and support work. For an independent view on product choice, partner selection or project planning, see software consulting. Hosting matters too: a well-sized, monitored server or cloud environment avoids performance complaints that users blame on the ERP itself.
Key takeaways
- Define measurable goals and appoint a sponsor with real authority.
- Free up key users' time; they are central to design, testing and training.
- Adopt standard processes where possible and customise sparingly.
- Start data cleansing early and rehearse the migration.
- Plan go-live carefully and budget for post-launch support.