An ERP implementation is the project of setting up new business software (an ERP, or enterprise resource planning system, is one system that runs stock, purchasing, sales, jobs or production and the finance side together) and moving your business onto it. Most businesses hire the vendor or one of its partners to configure the system, and that part is usually done well. The parts that most often go wrong sit around the software and are often thin in the scope: moving and reconciling your data, connecting the ERP to your other systems, rebuilding the reports people relied on, changing processes and approvals, planning the cutover, and support once the project team leaves. This guide explains each, what to ask your vendor, and what good looks like.
It applies whether you've chosen NetSuite, Business Central, Acumatica, Pronto, MYOB Advanced, ERPNext or another product. The gaps are much the same.
What an ERP implementation usually includes
A typical implementation proposal covers:
- Design workshops, where the vendor learns how you work and agrees the set-up.
- Configuration: entities, tax codes, item types, warehouses, approval rules and forms.
- Some data import, often limited to loading the vendor's templates.
- Training for key users, who then train everyone else.
- Go-live support for a set period.
Read the scope closely and you'll often find phrases like "client to provide data in the supplied templates", "integrations out of scope" or "standard reports only". That isn't the vendor being sneaky. Their team is expert in their own product; your old data, other systems and spreadsheets aren't, so they are left to you. Yet these are the parts that decide whether go-live goes well.
ERP data migration: the part that sinks go-lives
ERP data migration means moving your records into the new system: customers, suppliers, items, prices, open orders, balances and sometimes history. It sounds like an export and an import, but it is the part most likely to delay a go-live, because nobody knows how messy the data is until they try to load it.
- Open items or history? Moving only what is still live (unpaid invoices, open orders, stock on hand, balances) is simpler. Years of transactions is much more work and often isn't needed if the old system stays available read-only. Decide early.
- Mapping. Old account codes, item categories, tax codes and customer types rarely match the new system one to one. Someone has to decide where each goes.
- Cleansing. Duplicate customers and suppliers, items nobody has sold in years, wrong addresses. Moving them just moves the problem. Our guide to data cleansing before a migration covers how to find and fix them.
- Test loads. Load into a test copy of the ERP, fix what breaks, and load again.
- Reconciliation. Prove the data arrived complete and correct: record counts that match between old and new, debtor and creditor balances that agree, stock quantities and values that agree, and a trial balance (the list of every account balance) that ties out to the old system at the cutover date.
What to ask your vendor: Who extracts the data from our old systems? Who does the mapping and cleansing? How many test loads are included? Who signs off the reconciliation, and what does it check?
What good looks like: a written migration plan, at least two full test loads, and a reconciliation pack your finance manager can read and sign: counts, balances and a trial balance that agree. Our data migration plan and checklist walks through each step.
ERP integration with your other systems
Most businesses keep other systems around the ERP: a job or project system, a CRM (where sales keeps leads and quotes), a warehouse system, an online store, payroll, portals, and sometimes separate accounting software. ERP integration means connecting these so information flows automatically instead of being typed in twice.
That retyping is called double data entry (the same information typed into two systems). It's slow, causes errors and lets the systems drift apart. It also leaves data silos: information stuck in one system that the people who need it can't see.
Integrations get left out of scope because they mean working with someone else's software. Some are standard connectors (a ready-made link between two products). Many are not, or the connector does less than people assume.
What to ask your vendor: For each system we keep, is the connection a standard connector or custom work? What information goes which way, and how often? What happens when a record fails to go across, and who gets told? Who supports it after go-live? Our list of questions to ask a software vendor about integration goes further.
What good looks like: a simple list of every connection, what it carries and in which direction, tested with real records before go-live, with failures that show up on a screen or in an email rather than being found weeks later at month-end. This is the work our third-party software integration and database integration and migration services cover.
Reports and processes people relied on
Two things tend to get missed until the week before go-live.
Reports. People build reports they trust over the years: the weekly margin report, the morning stock report, the spreadsheet the owner opens every Monday. A new ERP's standard reports rarely match them. If the board pack or commission report can't be produced in the first month, confidence in the new system drops quickly.
What to ask: Which of our current reports will the ERP produce on day one, and which need to be built? Who builds them, and are they in the scope?
What good looks like: a list of every report people use, each marked standard, to build, or retire, with the important ones checked against the old numbers before go-live.
Processes and approvals. A new system changes who raises a purchase order, who approves it, how a job is closed and when an invoice is sent. Vendors configure to a design, but how your people work is your decision. If nobody agrees the new process, staff keep the old way with a spreadsheet on the side, and the ERP becomes an expensive data entry tool.
What good looks like: each key process written down as it works today and as it will work in the new system, with the approval rules agreed by the managers who own them. Process mapping before configuration saves rework later.
Cutover and go-live
Cutover is the switch from old system to new: the final data load, the last day in the old system, the first day in the new one, and who does what in between.
Common gaps:
- No agreed date when the old system stops taking new transactions.
- No plan for what happens to orders, deliveries and invoices that are in progress on the day.
- No final reconciliation of balances at the cutover date.
- No fall-back plan if the final load fails.
- Go-live set at a busy time, such as end of financial year or the peak sales season.
What to ask: Is there a written cutover plan with tasks, owners and times? What is the fall-back if something fails? Who signs off that we're ready?
What good looks like: a cutover rehearsed on the test system, a checklist with a name against each task, a go/no-go decision on agreed criteria, and reconciled opening balances on day one.
After go-live: who fixes what?
Once go-live support ends, the project team moves on. The question is who you call when an integration stops overnight, a report doesn't match last month, or an approval goes to the wrong manager. The vendor supports its own software, but may not support integrations, custom reports or data fixes, especially if someone else built them.
What to ask: After the go-live support period, what does ongoing support cover, and what does it cost? Who supports each integration and report? Who inside our business owns the system day to day?
What good looks like: a named owner inside the business, written notes on how each integration and report works, and a clear line between what the vendor supports and what someone else does. Without that, the knowledge sits in one person's head, which is key person risk.
Questions to ask before you sign the implementation scope
Get the answers to these in writing before you sign.
- Exactly which data comes across: open items only, or history? Who extracts, maps, cleanses and reconciles it?
- How many test loads are included, and what does the reconciliation check?
- Which systems will connect to the ERP? For each one, is it a standard connector or custom work, and is it in the price?
- Which of our current reports will be ready at go-live?
- Who maps our processes and agrees the approval rules?
- Is there a written, rehearsed cutover plan with a fall-back?
- What support is included after go-live, for how long, and what's excluded?
- What do you need from our team, and how much of their time?
If several answers are "that's your responsibility", that's fine, as long as you know now and plan for it. If you're still choosing a product, our software selection consultant service helps you compare options and their implementation scopes before you sign.
Where Kenomont fits
Kenomont is vendor-neutral. We work alongside your ERP vendor's team on the parts that sit around the software: data migration and reconciliation, integrations with your other systems, reports, process mapping, cutover planning and support after go-live. Your vendor configures their product. We make sure the data, the connections and the reports are ready when it goes live. Our ERP implementation page explains how this works.
We also implement ERPNext from start to finish. ERPNext runs operations, such as stock, purchasing, manufacturing, projects and CRM, alongside your accounting software, which keeps the accounts. It doesn't replace it. If you're weighing ERPNext against another open-source option, see our ERPNext vs Odoo comparison.
We've been running client systems since 2005, including a purchase order approval system in daily use at a large retirement living provider since 2014, and were the client-side technical adviser on a multi-state aged care provider's move to Microsoft Azure, including vendor selection and cutover.
If your project is already under way and running late, our guide to getting a stalled ERP project back on track may help.
Frequently asked questions
What does ERP implementation involve?
Setting up the software, moving your data in, connecting other systems, rebuilding reports, training staff, switching over and supporting it afterwards. Vendors usually handle setup and training; data, integrations, reports and cutover are often only partly in scope.
How long does an ERP implementation take?
It depends, and a figure given without seeing your business is a guess. The drivers are how many entities and sites you have, how much data you're moving and how clean it is, how many systems need connecting, how much processes change, and how much time your team can give. Data and integrations are the usual causes of delay.
Who does the data migration in an ERP implementation?
Many vendors supply templates and load the data, but expect you to extract, map, cleanse and check it. Look for "client to provide data" in the scope. If your team lacks the time or skill, bring in someone who has it, and agree who signs off the reconciliation.
Do we need an independent ERP consultant?
Not always. If the scope covers your data, integrations and reports, and someone inside the business has time to run the project, you may not. An independent ERP implementation consultant helps when you have several systems to connect, messy data, or nobody on your side who can check the vendor's work.
Can you help part-way through an implementation?
Yes. We can join once configuration is under way and the data, integrations or reports turn out to need more work than planned, working alongside the vendor's team.
What is ERP integration?
Connecting the ERP to your other systems, such as a job system, CRM, warehouse, online store, payroll or separate accounting software, so information flows between them automatically. It removes double data entry and means everyone works from the same numbers.
If you're planning an ERP implementation or are part-way through one, book a free initial chat and we'll talk through where the gaps are. For a full written review of your processes and systems before you commit, our $5,000 Process & Systems Audit maps how work flows today and what the new system needs to connect to.