How Long an ERP Implementation Really Takes (By Team Size)

Last updated: August 27, 2026

By Robert Ardell, Co-Founder and Strategic Advisor, KORE1

Most mid-market ERP implementations take six to twelve months, and the variable that moves that number most is not the software but how many people on your side can make a binding decision without escalating. A two-person core team and a six-person core team running identical scope on identical software do not land in the same quarter. The gap runs months. Team size is the schedule.

I have been on the hiring side of ERP projects since 2005, which means I almost never see the build. I see the staffing plan in month one and I see the panic req in month seven. Both documents lie a little. Together they tell you more about a timeline than any implementation methodology deck ever has.

The panic req has a shape. It arrives with a start date inside two weeks, a rate ceiling somebody clearly argued about, and a title that is three roles stapled together. Every one of those reqs started as a team that was one or two people short at kickoff and made it up by working weekends until the weekends stopped working. I have kept a few of them.

Where my bias sits, since you will want to weigh it. We benefit when you hire. KORE1 runs an ERP recruiting desk and a hire is revenue for us, so a page arguing that thin teams take longer is a page arguing for our own product. Price that in. I will still spend a section below telling you which weeks no amount of hiring will buy back, because that is the part people get wrong in the other direction.

Hours Are the Vendor’s Number. Weeks Are Yours.

An ERP implementation timeline is the calendar distance from signed statement of work to the end of hypercare, covering discovery, design, configuration, data migration, testing, cutover, and post-go-live support. It is not the vendor’s hour estimate. They are different units. Hours measure effort. Weeks measure that same effort plus everything your organization does while the effort sits waiting on you.

Those two numbers get confused constantly, and it is not anybody’s fault. A statement of work quotes hours because hours are what the vendor controls. Nobody quotes your controller’s calendar. Your controller already has a job.

I read a NetSuite integration proposal earlier this year that handled this better than most. It wrote the client’s own approval speed directly into the schedule as a stated assumption: ten business days to review and approve a specification document, five business days to approve a test protocol before execution. The build schedule carried a rework allowance for revisions, which is normal and sensible, and it carried no allowance whatsoever for review latency past those windows. Miss the window and the date moves. The client agreed to that. It sat in writing before anyone signed.

Read that as a consultant protecting their own position if you want. The scars showed. I read it as somebody who has watched enough projects to know exactly where the weeks disappear.

Four Team Sizes, Four Different Calendars

Here is the version I give people when they call and ask for a number before they have a scope. It sorts by the size of the core team on your side, not by the vendor’s headcount, because the vendor’s headcount is the input you can buy and yours is the one you cannot.

Windows reflect our read of ERP and NetSuite projects we have staffed since 2005 across 30-plus U.S. metros. Not a published index.

The platform matters less than people expect inside any one row. A NetSuite or Sage Intacct rollout tends to run at the fast end, an Epicor or Dynamics 365 build with real manufacturing scope at the slow end, and SAP S/4HANA sits in its own conversation. But moving from row two to row three costs you more calendar than switching vendors ever will.

Panorama Consulting Group’s 2026 ERP Report puts the median project at nine months, which lands squarely in the second and third rows. More useful than the median is what sat behind the projects that ran past their planned schedule, and almost a quarter of them did. The most common reason was not technical at all. It was organizational: delayed sign-offs, design workshops that would not close, stabilization periods that kept extending. Governance, not code.

The Second Person You Add Buys Weeks. The Ninth Buys Meetings.

Fred Brooks wrote in 1975 that adding people to a late software project makes it later. Brooks was right. Fifty years on, ERP proves it about twice a year in our client base, usually in month eight.

The reason is not mysterious. Going from one person to three removes a queue. One person cannot design the chart of accounts, clean the item master, and sit in UAT in the same week, so the work waits in line behind them and every wait is calendar. The queue is real. Add two more people with real authority and three lines run at once. That is a genuine compression, and it is the single best schedule investment most mid-market companies never make. Few companies make it.

Going from six to twelve does something else. Twelve people generate coordination, and coordination is not throughput. It is a tax paid in meetings, in re-explaining a decision made last Thursday, and in two subteams designing the same process differently and finding out in integration testing.

There is a real threshold in there. In our experience it sits somewhere around five to seven on the client side for a single-entity mid-market build, and past that you need a governance structure or you are just adding people to a room. The Project Management Institute’s 2018 Pulse of the Profession put a number on that gap. Organizations with mature delivery capability finished 64% of projects on time, while low-maturity organizations managed 36%. Same industries. Same tools. Nearly double the on-time rate, purely on how the work was governed.

If the seats themselves are the open question rather than the count, we wrote a separate piece on ERP implementation team structure that walks the roles one at a time.

The Approval Clock Nobody Puts in the Plan

Every implementation plan I have seen budgets build time. Almost none of them budget decision time, and decision time is where mid-market projects lose their quarters.

Walk through what one design document has to survive before anybody signs it. Somebody reads it. Somebody who understands the downstream consequence reads it. Two of them disagree about how returns should post. The disagreement goes to a person who is traveling. Nobody scheduled that. Nine business days evaporate and not one hour of work was performed by anyone on either side. Nobody budgets for that.

The same PMI research found that 52% of projects experienced scope creep or uncontrolled scope change, up from 43% five years earlier. Scope creep is usually described as a budget problem. On ERP it is a calendar problem first, because every added requirement re-enters the design queue at the back and the queue is the schedule.

A rough rule I have not seen fail. Count the number of people who must say yes before a design decision is final. If that number is above three, add a month per additional approver to whatever the vendor quoted you. If nobody can name the number at all, the answer is worse than four.

One Person, Nine Months, No Backup

The single most fragile timeline is the one built on a person rather than a team, and it is almost always the client’s own person. A controller who knows why every account exists. An operations lead who is the only one who understands how the warehouse actually works versus how the SOP says it works. We see this monthly.

That proposal I mentioned earlier had one line in it I keep coming back to. The supplier said, in writing, that they would not hold a schedule commitment that depended on one individual being available every single week for nine months without flagging it first. Then they named an alternate for each role before work started.

Almost nobody applies that discipline to their own side of the project. I have asked. Your ERP timeline has a single point of failure and it is a person with unused PTO and a spouse who has noticed. That PTO gets taken.

This is where contract capacity does more for a schedule than most people expect, and yes, this is the part where I am selling something. Bringing in a contract ERP resource to absorb the day job frees the internal SME for the project, which is a different and better move than hiring a contractor to do the project while your SME keeps the day job. Our average time to fill on ERP and systems roles runs about 17 days, and 92% of the people we place are still in seat a year later, which matters more on a fourteen-month project than on a four-month one.

Budget-side reading if you need it. Our breakdown of NetSuite implementation cost and timeline benchmarks covers what these teams actually run per phase.

Where the Weeks Actually Go When a Project Slips

Almost none of it is the build. The pattern barely changes. In rough order of how much calendar they consume in the projects we staff:

• Data. Data is almost always first. Item masters with fourteen years of duplicates, customer records that three systems disagree about, open transactions nobody wants to own. Six weeks is common and eight is not rare, and the discovery of how bad it is usually happens in week three of a project scoped in week negative two.
• Approval latency. Covered above. It is the quiet one.
• Integration surprises. The warehouse system, the tax engine, the CRM, the bank feed. Each one has an owner who was not in the kickoff and a constraint nobody wrote down.
• Testing that finds real problems, which is testing working correctly and still costing you three weeks.
• Change of heart on process. Someone senior sees the configured system for the first time in UAT and says the thing everyone dreaded. This is why you demo early and often, and it is why phased rollouts are worth their overhead.
• Go-live timing. Nobody cuts over during their busy season or across a quarter close, so a six-week slip in October frequently becomes a fourteen-week slip into January. The calendar wins.

That last one deserves more space than I am giving it. A modest delay in the wrong month is not a modest delay.

What You Can Compress, and What You Cannot

Compressible, in rough order of return. Data cleanup, which can start before you have even selected a platform and is the most useful thing an underbooked analyst can do this quarter. Parallel workstreams, once you have the people for them. Training, which can overlap testing. Documentation, which can trail go-live by a few weeks without hurting anyone.

Not compressible, no matter what you spend. Money does not buy sequence, and you cannot test a configuration that does not exist yet. Sign-off cycles in a regulated environment do not shorten either. The close cycle waits, because a lot of validation only happens against a real month-end. And the plain human interval between seeing something and understanding it, which is where most reworked designs are actually born.

Companies routinely try to buy the second list with money and get very annoyed when it does not work. I understand the annoyance. It is a reasonable instinct and it is simply not how these projects fail.

Questions People Ask Before They Pick a Go-Live Date

Six months start to finish. Is that realistic for a mid-market rollout?

Six months is realistic for a single-entity company at $50M to $250M with a core team of three to five, clean financial data, and fewer than three integrations. It is not realistic if any of those four things is missing. Most six-month plans die on the data, not the configuration, and the data problem is usually visible before kickoff if anyone looks. Nobody looks.

Our partner quoted twelve weeks. What is that number measuring?

Twelve weeks is usually the vendor’s own effort estimate rather than an end-to-end calendar, and both parties can be honest about that number while meaning different things by it. Ask what the quote assumes about your review turnaround, how many of your people are assumed to be available and for how many hours, and what happens to the date if a specification needs a second revision. The answers reprice the timeline faster than any negotiation on rate.

Can we go faster by adding contractors?

Sometimes, and it depends entirely on which seat you fill. Adding a second or third person with real decision authority genuinely compresses the calendar. Adding a ninth pair of hands to a team that already has a decision bottleneck adds coordination overhead and nothing else. The bottleneck does not move. The version that reliably works is quieter than it sounds. Hire someone to backfill the day job of the internal expert everyone is waiting on, then protect that expert’s calendar for the project.

Does a phased rollout actually finish sooner than a big bang?

No, and it usually finishes later on total elapsed time. What phasing buys is a shorter interval to the first working thing, a smaller failure radius on cutover weekend, and a team that has been through a go-live once before the hard entity goes. Phasing costs elapsed time. For multi-entity companies I recommend it anyway. Just do not sell it internally as the fast option, because somebody will hold you to that in month eleven.

Nobody on our side can make the final call on process. Is that fatal?

It is not fatal, but it is the most expensive unfixed problem on this list, and it is fixable in an afternoon. Name one person who can decide how a process will work and who has cover from an executive to overrule a department. Put that name in the project charter. Projects with an ambiguous decision owner do not slip in one dramatic event; they slip four days at a time, in a way that is nearly invisible until the summer is gone.

When does the clock actually stop?

Not at go-live. The clock keeps running. Budget four to eight weeks of hypercare after cutover, with defined response commitments in writing rather than best effort, because the first month-end close on the new system is the real test and it happens after everyone has declared victory. Then somebody owns the system permanently. If you have not named that person by go-live weekend, you have not finished the project, and our go-live and hypercare staffing page exists mostly because of how often that seat is empty.

Count the Decision-Makers Before You Count the Months

Do this before your next steering meeting. Write down every person who must approve a design decision. Somebody knows the number. Mark which of them has protected time for this project versus which is doing it on top of a full job, and note who covers each of them if they are out for two weeks.

That page is your timeline. The page rarely lies. The vendor’s Gantt chart is a forecast built on it.

If the page comes back short, you are looking at a staffing problem several months before it becomes a schedule problem, which is the good version of finding out. KORE1 has placed ERP and enterprise systems talent since 2005 across 30-plus U.S. metros, and we can usually tell within one conversation whether a date is achievable with the team you have or whether it needs a seat filled first. Send the plan over and we will tell you which one you have. You can talk to a recruiter on our ERP desk this week. Bring the org chart, not the project plan.

One more thing worth knowing before you sign anything. The Bureau of Labor Statistics puts the median wage for project management specialists at $100,750 as of May 2024, with the field projected to grow 6% through 2034. A dedicated internal project manager is not a cheap line item. On a fourteen-month build, the absence of one costs considerably more.