How to run an ERP project, from scoping to go-live and beyond

An ERP project is not a software installation. It is a change programme in which a piece of software happens to be the main tool. Companies that treat it as an IT purchase tend to end up with a system that technically works and that nobody quite trusts. Companies that treat it as a business project, with an owner, a method and clear stages, tend to get the control and visibility they were after.

This guide describes the stages of an ERP implementation as they apply to a small or mid-sized business in the UK. For each stage you will find the objective, the deliverables you should expect and the pitfalls we see most often. If you are still at the stage of understanding what the software does, start with what an ERP is; if you already know and want to move, read on.

ERP project stages at a glance

The table below summarises the whole journey. The detail follows in the next sections.

Two points are worth stating before the detail. First, the stages are sequential in intent but overlap in practice: data cleansing starts during design, and training material is drafted while configuration is still under way. Second, every stage ends with a decision. If nobody is willing to sign off a stage, the project is telling you something, and it is cheaper to listen early.

Stage one: scoping the ERP project

Objective

Scoping answers three questions: why are we doing this, what must the new system achieve, and what is deliberately left out? The aim is a short, shared statement that the board, finance, operations and IT all recognise.

Good scoping starts from business pain, not from features. Typical drivers include month-end closing that takes too long, stock that nobody trusts, spreadsheets that only one person understands, a group structure that has outgrown the current accounting package, or a need to meet tax and e-invoicing obligations more cleanly. Write these down in plain language and attach an owner to each.

Deliverables

• A project charter naming the executive sponsor, the project manager and the decision-making rules.
• A first version of your requirements, structured by process rather than by screen. Our ERP requirements template gives you a starting structure.
• A description of the current landscape: the systems in use, the integrations that matter and the data you will need to carry across.
• An initial budget envelope and an honest view of the internal time the project will consume. For a realistic picture of what to budget for, see the guide on ERP cost.

Pitfalls

• No sponsor with authority. When trade-offs arise between departments, someone has to decide. If that person is not in the project, decisions drift.
• Scope defined by wish list. Everything is "essential", so nothing is prioritised. Separate what is needed at go-live from what can wait for a later phase.
• Underestimating your own workload. Your people must answer questions, validate designs and test. The integrator cannot do that on your behalf.

Stage two: selecting the ERP and the integrator

Objective

Selection is where you move from needs to a decision. You are choosing two things at once: the software and the firm that will implement it. Many projects that fail on paper chose well on the first and badly on the second.

The ERP market for growing businesses includes Odoo, Microsoft Dynamics 365 Business Central, Sage, Oracle NetSuite and SAP Business One. They differ in licensing model, depth of functionality, ecosystem and the type of company they suit best. Our guide on how to choose an ERP sets out the criteria, and the software overview compares the options neutrally.

Deliverables

• A shortlist built from your requirements, not from vendor marketing.
• Scripted demonstrations in which the vendor or integrator shows your scenarios on your kind of data, rather than a generic tour.
• A written proposal and statement of work that describe the scope, the assumptions, the responsibilities on each side, the way change requests are handled and how the price is built.
• Reference conversations with companies of similar size and sector, so that you hear how the integrator behaves when things go wrong.

Pitfalls

• Choosing on price alone. The licence is only part of the cost. Implementation effort, hosting, support and your internal time often weigh more over the life of the system.
• Ignoring the deployment question. Cloud, hosted or on-premise has consequences for security, upgrades and cost. Our comparison of cloud and on-premise ERP explains the trade-offs.
• Vague proposals. A proposal that cannot tell you what is excluded will generate change requests later. Ask for assumptions in writing.

Choosing the integrator deserves its own method. The guide to choosing an ERP integrator covers what to check, and our matching service is built to put you in front of firms suited to your sector and size.

Stage three: solution design

Objective

Design translates your requirements into a description of how the business will operate in the new system. It is the most intellectually demanding stage and the one most often rushed. A good design workshop questions existing habits: some processes exist only because the old system forced them.

The guiding principle is to adopt the standard processes of the product wherever they fit and to document, with a business case, each place where you need something different. That discipline protects you at upgrade time and keeps the project affordable.

Deliverables

• Process maps for the main flows: order to cash, procure to pay, record to report and, where relevant, plan to produce or project to invoice.
• A design document covering organisation structure, chart of accounts, VAT and tax set-up, approval workflows, roles and permissions, reporting needs and integrations.
• A fit-gap analysis showing which requirements the standard product meets, which need configuration, which need an add-on and which would need development.
• A data migration strategy: what is moved, from where, in what form and who is responsible for cleansing it.

Pitfalls

• Recreating the old system. If the design simply copies today's screens and reports, you pay for a new tool and keep the old problems.
• Forgetting UK specifics. Think early about VAT schemes, Making Tax Digital submissions, payroll interfaces, bank formats, multi-currency and any sector-specific compliance. Raise them in design, not at testing.
• Silent departments. If purchasing or the warehouse did not attend the workshops, their objections will arrive at acceptance testing, when they are expensive.

Stage four: configuration and build

Objective

Configuration builds the agreed design in a test environment, using the standard options of the product. The integrator sets up companies, currencies, tax codes, products, price lists, workflows, document templates and security roles, and develops any extension that survived the fit-gap analysis.

Work is best done iteratively. Rather than disappearing for months and returning with a finished system, a good team shows working increments at regular intervals so that you can correct course while it is still cheap.

Deliverables

• A configured environment that reflects the design, available for your team to try.
• Documented settings, so that the configuration can be reproduced and understood by someone who did not build it.
• Specifications and test evidence for every custom development or integration.
• A plan for environments: development, test and production, with a clear rule about how changes move between them.

Pitfalls

• Customisation creep. Each small request seems harmless. Together they make upgrades harder and support slower. Keep a visible list of customisations and require a business owner for each.
• Integrations left until the end. Connections to e-commerce platforms, banks, payroll, CRM or logistics providers often cause the longest delays. Start them early and test them with realistic volumes.
• No change control. Without a simple process for handling new requests, the scope moves silently and so does the budget.

Stage five: data migration

Objective

Data migration moves the information the business needs to operate from the old systems into the new one: customers, suppliers, products, bills of materials, open orders, opening balances, fixed assets and so on. Many projects are slowed down not by software but by data that nobody has looked at for years.

The principle is to migrate what you will use, not everything you have. Historic transactions can often be archived or kept in a reporting tool rather than loaded. Our guide to ERP migration goes deeper into approaches and controls.

Deliverables

• Data mapping from each source field to its destination, with transformation rules.
• Cleansing rules and a named owner for each data set: duplicates removed, addresses standardised, obsolete items closed.
• Several trial loads, each with a reconciliation report. Finance should be able to agree opening balances to the old ledger.
• A final cutover load procedure that has been rehearsed, with timings and a rollback option.

Pitfalls

• Treating migration as a technical task. Only the business knows which supplier record is the right one. Cleansing needs business owners.
• Leaving it late. Data problems found at the last moment are the most common reason for a postponed go-live. Run trial loads early and repeatedly.
• Skipping reconciliation. If trial balances and stock valuations do not match the source, the system will not be trusted, however good it is.

Stage six: acceptance testing

Objective

Testing proves that the system supports real business scenarios from start to finish, with realistic data and the people who will actually use it. It is not a demonstration; it is an attempt to find what does not work while there is still time to fix it.

Deliverables

• Test scripts written around business scenarios, for example a quote converted to an order, delivered, invoiced, paid and reported, including returns and credit notes.
• Integration and performance checks, including month-end and period-close routines.
• A defect log with severity, owner and status, reviewed at every project meeting.
• Formal acceptance by each process owner, recorded in writing.

Pitfalls

• Testing by the integrator only. The integrator tests that the system does what was configured. Only your people can confirm it matches how the business works.
• Happy path only. Test exceptions: partial deliveries, cancelled orders, foreign currency, price overrides, manual journals and users who lack permissions.
• Pressure to accept. A looming deadline tempts teams to sign off with open issues. Agree in advance what level of defect blocks go-live.

Stage seven: training and change management

Objective

Training makes people able and willing to work in the new system. It is often squeezed because it happens when the deadline is closest, yet it determines whether the investment is used or bypassed by side spreadsheets.

Effective training is role-based. A sales administrator, a buyer, a warehouse operative and a finance controller each need to learn their own processes, not a tour of every menu.

Deliverables

• A training plan by role, with sessions held on a copy of your own configured system.
• Short process guides and quick reference sheets written in your terminology.
• Key users who are trained in depth and can support colleagues after go-live.
• A communication plan that explains to the wider business what is changing, when and why.

Pitfalls

• Training too early or too late. Too early and people forget; too late and there is no time to practise.
• Ignoring resistance. People who feel the system was imposed will find reasons not to use it. Involving them in design and testing is the best remedy.
• Dependency on one expert. If only one person understands the system, you have recreated the spreadsheet problem in a more expensive form.

Stage eight: go-live and stabilisation

Objective

Go-live is the switch from the old way of working to the new one. The aim is a controlled cutover with an agreed decision point, not a heroic overnight effort. Choose timing with care: avoid the busiest trading period and think about where you are in the VAT and financial year calendar.

Deliverables

• A cutover plan listing each task, owner, duration and dependency, with a go or no-go checkpoint.
• A final data load, reconciled and signed off by finance and operations.
• Heightened support after launch, with a clear route for raising and prioritising issues.
• A stabilisation plan covering the first invoicing runs, the first VAT return and the first month-end close in the new system.

Pitfalls

• Going live without a no-go criterion. If nobody has defined what would stop the launch, the date becomes the only criterion.
• Running in parallel for too long. Keeping both systems alive doubles the workload and blurs which one is the truth. Set a firm end date for the old system.
• Disbanding the team the day after. The first weeks always bring surprises. Keep the project team available until the system is stable.

Our guide on common ERP project mistakes collects the patterns behind most troubled go-lives and how to avoid them.

Stage nine: continuous improvement

Objective

Go-live delivers a working foundation; value comes afterwards. Continuous improvement is the practice of reviewing how the system is used, removing workarounds, extending it to new areas and keeping it current as the business changes.

Deliverables

• A post-implementation review comparing results with the objectives set during scoping.
• A prioritised backlog of improvements: reports, automations, additional modules, integrations and user requests.
• A support and maintenance agreement that states response expectations, upgrade responsibilities and how enhancements are quoted.
• Regular reviews of user access, data quality and performance.

Pitfalls

• Declaring victory and moving on. Without an owner, the system slowly drifts from how the business works.
• Falling behind on upgrades. Small, regular updates are easier than a large catch-up. Plan them with your integrator.
• Measuring nothing. Go back to the pain points identified at the start and check whether they have actually been resolved.

Roles and governance throughout the project

Whatever the stage, a few structural choices decide whether the project runs smoothly.

A steering committee that meets at regular intervals, a shared risk and issue log, and a rule that scope changes are priced and approved before work starts will prevent most disputes. Insist that progress is reported against the plan in business terms, not only as a percentage complete.

Choosing an approach: phased or all at once

Two broad strategies exist for the cutover. In a single switch, all modules and entities go live together. In a phased rollout, you start with finance and add sales, stock, production or further sites in waves, or you launch one entity or country first and replicate the template elsewhere.

A single switch reduces the period of running two systems but concentrates risk. A phased approach spreads effort and lets the team learn, at the price of temporary interfaces and a longer overall programme. For most small and mid-sized businesses, a core of finance, sales and stock first, with specialist functions following, is a sensible balance. Your integrator should explain the reasoning for their recommendation rather than simply offering one option.

Setting up your ERP project for success

A few habits separate smooth projects from painful ones:

• Name one accountable owner on your side and protect their time.
• Decide early which standard processes you will adopt and resist changing them without a business case.
• Start data cleansing at the beginning, not at the end.
• Test with real scenarios and real users.
• Keep a clear record of decisions so that nothing is reopened without reason.
• Plan the period after go-live as carefully as the period before it.

If you would like to be introduced to an ERP integrator that fits your sector, size and preferred software, you can see how our matching works. The service is free to you; the integrator is the one who delivers the project, and you remain free to compare proposals and choose.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.