Most ERP timelines you are shown in a sales meeting are a straight line. Real ones are not. For a manufacturing company of around twenty people, the work can finish inside a month or it can run past six, and the difference usually has nothing to do with the software. It has to do with the state of your data and how much of your own time you are able to give it.

Here is the shape of the project, stage by stage, with the parts that go wrong marked.

Stage one and two: discovery, then a proposal you can argue with

It starts with meetings and questionnaires. The point is to write down what you actually do, which modules you need, and which processes are load bearing. Not the processes on the quality manual wall, the ones people really follow.

Out of that comes an implementation plan with a timeline and a quote. If the proposal reads like it could have been written for any company, discovery was too shallow and you should send it back. A twenty person shop and a twenty person assembly operation need different things configured, and that difference should be visible in writing before anybody signs.

Stage three: contract, then configuration begins

Signing is when the module list stops moving and the integration plan gets written down. Configuration starts here.

This is also the moment to be honest about scope. Every customisation you add later will be quoted separately and will cost you calendar time, not just money. If you know you need something unusual, it belongs in this stage, not in month four.

Stage four: data migration, which decides your timeline

This is the hardest and often the longest part of the project. Not sometimes. Usually.

You export your data from the old ERP or accounting system, ideally as CSV or Excel. An NDA is signed before anything moves. Then the mapping work starts: your fields to the new ones, decided field by field, tested, and adjusted with you until the result is right.

What makes this hard is never the export button. It is what the export contains. Twenty years of part numbers with three different naming conventions. Customers entered twice. Stock quantities that have been wrong since a stocktake nobody trusted. Bills of material that live in a spreadsheet on one person’s laptop rather than in the old system at all.

None of that is unusual and none of it is a reason to delay starting. But it does mean the cleanup is real work, and it is work only your people can do, because only your people know which of the two customer records is the live one.

If you want a single lever on the timeline, this is it. Clean exports shorten the project more than any other decision you can make.

Stage five: testing on a copy

Configuration and migrated data go into a staging environment, which is a separate copy of the system, not your live one. You validate there.

Validation means your people running their real work through it. Take last month’s orders and put them through the new system. Quote something. Book a goods receipt. Errors found in staging are cheap. The same errors in week one of live running cost you internal credibility, which is harder to get back than a day of work.

Stage six: training people who already have a full time job

Training runs as webinars and workshops, online or on site, and is phased from the basics to the more advanced features rather than delivered in one exhausting block. There is built in documentation and there are guides, and access to the training material continues after go live, so the person you hire in March next year is not stranded.

The realistic constraint here is attention. Your production planner is not going to absorb four hours of training on a day when a machine is down. Book the sessions like you would book maintenance, with the time actually protected.

Stage seven: go live

Go live is a date, not an event. If stages four and five were done properly it is a quiet day.

Phasing is worth considering. Onboarding can be staged, with core functions live first and further modules or integrations following. For a company of this size that is often the calmer route, with fewer things to learn at once.

Stage eight: the first week

The first week after launch gets reinforced support, with active monitoring, issues resolved as they surface, and extra training where it turns out to be needed. Expect to find things. Everybody does. The questions in week one are mostly about habits rather than software, and they are worth answering carefully because that is when the new way of working sets.

Where integrations fit

Integrations run on their own clock and are worth planning separately. A simple one, in the region of a week. A complex one, one to two months or more. Reading data from CNC machines, Omron PLCs, Universal Robots or other IoT devices sits at the more involved end, because the work is specific to your equipment.

Field mapping between systems is done by us, then tested and adjusted with you. After launch there is one month of free fixes, and after that integration maintenance falls under a support package or a separate agreement, with issues going through the ticket system.

If an integration is not critical for day one, let it follow go live. Trying to land a machine integration and a new stock process in the same week is how a good project acquires a bad reputation internally.

What you have to bring

This is the part most often underestimated. You will need to provide:

Exports of your existing data from the old ERP or accounting system.
Documentation of your internal processes, even if it is rough.
Named people from the business who will actually participate, not just be listed.
Access to any system that has to be integrated.

Involve leadership and key staff from more than one department, and appoint one internal project coordinator. One name, with the time to do it. Projects without that person do not fail dramatically, they just drift, because every decision waits for a meeting.

What actually makes it late

Four things, in roughly this order:

Complex data migrations.
Not enough internal resource on your side.
Data exports that were not properly prepared.
Extra customisations that surface in the middle of the project.

Three of those four are on the customer side. That is not a complaint, it is the useful part of the information. The variables you control are the ones that move the date.

So, one month or six

A smaller organisation can finish in a month. A larger or more complex one can take half a year or more. A twenty person manufacturer with tidy data, a named coordinator and no exotic integration sits near the short end of that range. The same company with its bills of material in a spreadsheet and nobody free until after the summer shutdown sits somewhere else, and no software decision changes that. Worth knowing before you start rather than in month three.

What an ERP implementation for a 20 person manufacturer actually looks like