How Long an ERP Implementation Really Takes, and What Makes It Longer

The proposal said four months. It said four months because you asked how long it takes, and because the bidder who says nine loses to the bidder who says four, and because there genuinely exists a version of your project that takes four months — the version where every answer arrives the day it is asked for, the data is clean, the two integrations are with systems whose owners are helpful, and nobody goes on leave.

You will not be running that version. Almost nobody does. But the interesting question is not why estimates are optimistic, which is well understood and universal. It is which parts of the elapsed time are bought with money and which parts are bought with calendar, because those are different currencies and most projects overspend the first trying to buy the second.

What "how long" is actually measuring

Three different durations get quoted as one number, and clarifying which you mean removes a great deal of later disagreement.

Contract to go-live is the one in the proposal. It ends on the day the old system is switched off.

Contract to stable ends when the system produces a month-end that finance signs without a reconciliation nobody can explain. That is typically one to three closes after go-live, and none of it is in the plan.

Contract to working ends when the decisions that justified the purchase are actually being made from the system: the job cost is trusted enough to price the next job, the stock figure ends the argument rather than starting it. This is usually two to three quarters after go-live, and it is the only one of the three that anybody outside the project cares about.

When a vendor says four months and a reference client says eighteen, they are frequently both telling the truth about different measurements.

A realistic shape

The following is elapsed time for a mid-market UAE company — one to four entities, real inventory or projects, roughly twenty to a hundred and fifty users, a first proper ERP. It is not effort. Effort and elapsed time diverge sharply, and the divergence is the whole subject of this article.

Phase	Typical elapsed	What sets the duration	Compressible?
Selection and contract	6 to 12 weeks	How many bidders, how decisive the board, how long legal holds the contract	Yes, by deciding faster
Discovery and design	4 to 8 weeks	Number of genuinely distinct processes; availability of the people who know how the work is done	Partly, by scoping tighter
Data profiling and cleansing	Runs from week one to cut-over	The state of your master data, and how quickly your people make decisions about it	Barely
Configuration and build	6 to 16 weeks	Distinct processes, exception rate, volume of custom code	Yes, by removing scope
Integrations	4 to 12 weeks, often overlapping	The far-end owner's calendar, not yours	Rarely, and never by paying your own partner more
User acceptance testing	3 to 6 weeks	Whether business testers actually test, alongside their day jobs	No
Data migration rehearsals	2 to 3 passes, spread over 6 to 10 weeks	How many defects each pass reveals	No
Training	2 to 4 weeks before go-live	Number of roles, number of sites, shift patterns	Partly
Cut-over	A weekend, or a long weekend	Volume of opening balances and open documents	No
Hypercare	4 to 8 weeks	Defect rate, and whether anyone stayed	No
To first clean close	1 to 3 month-ends	Data quality and whether finance was properly involved in design	No

Add it up honestly and a first ERP for a company of that shape lands somewhere between seven and fourteen months from contract to a month-end finance will sign. Fewer if the scope is narrow and the company is decisive. Considerably more if the entity structure is complicated or the data is bad, and the two usually travel together.

That range is wide because it is honest. Anyone who narrows it before seeing your entity list, your process count and your master data is quoting a phase rather than a project.

The work that cannot be compressed at any price

This is the part that surprises boards. A meaningful share of an ERP timeline is bounded by the calendar, not by the budget, and adding money to it produces nothing.

A month-end takes a month. You cannot test whether the design survives a period close in less time than a period. If the project's first close happens after go-live, you have chosen to test in production. If you want it tested beforehand, you need a month of elapsed time with real data in a test environment, and that month cannot be bought.

Data decisions run at the speed of the person who can make them. Extraction is fast. Deciding which of three spellings of a customer is correct, which items are genuinely obsolete, and whether an opening balance from an entity nobody has reconciled since 2019 can be signed off — that is human judgement, and it belongs to people who have day jobs. Doubling the consultant count produces a longer list of questions and the same answering capacity. It is why data migration kills more projects than software ever does, and why the profiling step belongs in week one rather than month five.

User acceptance testing is bounded by testers, and testers have jobs. A credit controller can test for perhaps two hours a day without her actual work collapsing. That arithmetic sets the calendar for UAT, and no amount of external resource changes it, because the whole point is that your people do the testing.

The far end of every integration runs on its own calendar. The bank's technical team, the customs portal, the payroll bureau, the marketplace. None of them work for you and none of them care about your go-live date. This is the most reliably underestimated line in any plan, and the reason is structural rather than negligent, as set out in why integrations cost what they cost.

Learning takes the time it takes. A storekeeper who has done a job one way for eleven years needs weeks of repetition, not a training session. Productivity drops after go-live in every implementation ever run, and the recovery curve is a property of human beings rather than of the plan.

Statutory cycles do not move. VAT periods, audit windows, financial year ends, licence renewals. Your project fits around them.

Fred Brooks made the general version of this point in 1975 in The Mythical Man-Month: adding people to a late software project makes it later. The ERP version is narrower. Adding consultants to a project waiting on decisions, testers or a third party does not accelerate anything; it raises the burn rate while the same queue drains at the same speed.

The work that genuinely can be compressed

Four things respond to effort and money, and they are where a serious acceleration conversation belongs.

Scope. By an enormous margin the most effective lever. Removing a business line, a country or a module from phase one removes design, build, testing, data and training simultaneously. Nothing else has that reach.

Parallelism on independent tracks. Integration development, document template design and report building can run alongside configuration if the design is settled. They cannot if it is not, and running them anyway produces rework rather than progress.

Pre-built sector configuration. A partner who has implemented six contractors already brings a starting configuration rather than a blank database. This is real and it is worth paying for, but interrogate it: ask to see it, and ask what proportion of their last project it survived. A pre-built configuration that gets overwritten in week three saved nothing.

Your own decisiveness. This is free, it is the largest lever after scope, and almost nobody treats it as a schedule item.

Decision latency, measured

A project moves at the speed of its slowest decision-maker. That sentence is worn from repetition, which is a pity, because there is a version of it you can actually measure.

Keep an open-questions log from day one. One row per question: what is being asked, who must answer, the date raised, the date answered. Then track two numbers weekly — the count of open questions and the median age of the open ones.

Those two numbers predict your go-live date better than the Gantt chart does, and they do it earlier. A log where the median age of open questions is three days describes a project that will finish near its plan. A log where it is three weeks describes a project that is already late, months before anyone announces a delay, because every one of those questions is blocking a piece of configuration and consultants who cannot configure are either working on something less useful or waiting.

The remedy costs nothing. A standing weekly hour, with somebody in the room who has authority to decide rather than authority to consult, and a written record of what was decided. Decisions taken in that hour cost a conversation. The same decisions taken during UAT cost a change request. Taken after go-live they cost a change request plus a data correction plus a retraining session plus the credibility of the system with people who have just learned it.

There is a second decision pathology worth naming: reopening. A design decision that gets revisited in month five because a director who missed the workshop has an opinion is more expensive than one never taken at all, because everything built on it is already there. Record decisions in writing, with the name of the person who made them, and treat reopening as a change request with a price. Not to be bureaucratic — to make the cost visible to the person considering it.

The politics of the go-live date

Somebody will propose aligning go-live with the financial year end, and the argument for it is genuinely good. Clean opening balances, no mid-year comparative problem, one set of statutory reports on one system, and an audit that does not straddle two ledgers.

The argument against it is also good, and it is usually ignored: the finance team is at its least available in exactly that window. You are asking the people who must accept the system, verify the opening balances and run the first close to do so while closing the previous year and hosting the auditors. Something gives, and it is usually the testing.

There is a middle position that works more often than either extreme. Go live at the start of a clean accounting period rather than necessarily the fiscal year, and accept the mid-year cost, which is smaller than it sounds: one set of opening balances at a period boundary, and comparatives that come from two systems for one year. Both are manageable. A finance team that never got to test is not.

Whatever date you pick, four windows are worth avoiding outright and everyone knows it locally, which is why they still get chosen by planners who are not local: your peak trading season, the statutory audit, a VAT return deadline in the first fortnight of running, and any period when a significant share of the workforce is on leave or on reduced hours. In the Gulf that last one has more than one occurrence in the year and it does not move to suit a project plan.

And there is one date politics problem that is not about the calendar at all. Go-live dates get fixed early, announced to the board, and then defended long after the evidence says they should move. The question that resolves it honestly is not "can we make the date" but "what will be untested on the day if we do". If the answer includes a period close, a payroll run or an integration to something you cannot control, the date has already moved and only the announcement is outstanding. The structured version of that conversation is what a go-live risk assessment is for.

Live is not working

The most expensive misunderstanding in this business is treating go-live as the end.

Live means transactions are being entered in the new system and the old one is off. That is an infrastructure state, and it can be achieved by a team that is exhausted, with a defect list, on a system nobody trusts.

Working means something different: the numbers are believed, the workarounds have not hardened into procedure, the second training round has happened, and somebody inside the company owns the configuration. The gap between the two is where projects are actually lost — the argument in why the most dangerous day is not day one.

Three things close it, and all three have to be in the contract rather than in the intention, because things in the contract happen.

The first is a second training round, four to six weeks after go-live. The pre-go-live round teaches people a system they have not used to do work they have not done in it, and most of it cannot stick. The round that changes behaviour is the one where everybody arrives with specific questions about what they have got wrong.

The second is a named internal owner, appointed before go-live rather than after, with the authority to approve configuration changes and the mandate to hold master data standards.

The third is a day-90 review against the business case, with the original problem statements read out and answered. Did the month-end close shorten. Is the job cost available before the next quotation. If nobody schedules that review while the contract is open, it does not happen, and the organisation never learns whether the money worked.

What to do with an unrealistic date you have already been given

If the timeline in front of you does not survive this article, there are three honest moves and one dishonest one.

Cut the scope. Phase it so the first release stands alone and produces a benefit somebody can name. This costs a second mobilisation and is almost always cheaper than the alternative.

Fix the decision machinery. Name owners per domain, hold the weekly hour, publish the open-questions log to the steering committee. This is free and it is the highest-return intervention available.

Move the date, early, in one move. A date moved once by three months at month two is a managed programme. The same three months surrendered a fortnight at a time is a project that has lost the confidence of its sponsor, and getting that confidence back is the hardest thing in the discipline. Recovering from that position is a specific piece of work in itself — what to do when the implementation has stalled.

The dishonest move is to hold the date and cut testing, training and the migration rehearsals, because those are the only lines that can be removed without a conversation with the vendor. That is how projects go live on time and broken, and the arithmetic is always worse: the weeks saved before go-live are repaid several times over in the quarter afterwards, when the budget is exhausted and everybody is watching.

If you want a realistic shape built against your own entity list, process count and data reality before a date is announced to the board, that is the ground our implementation work covers before anything is scheduled.