What actually happens between signing and go-live. The phases, realistic timelines, what drives the cost, who you need internally, and the failure patterns worth designing out before you start.
The single most useful thing to understand before starting is that an ERP implementation is not an IT project with a business impact. It is a business change project with a software component, and the organisations that treat it that way finish faster and get more from the result.
Cloud ERP has made the mechanics far simpler than they were. There is no infrastructure to procure, no environment to build, and configuration can be shown to the business within days rather than at the end of a long design phase. What has not changed is the human work: agreeing how processes should run, cleaning the data, and getting people confident before go-live.
That is where timelines are won or lost. Partners control configuration, migration tooling and testing discipline. Customers control decision-making speed, data quality and the availability of the people who know how the business actually works. Projects slip on the second set far more often than the first.
Cloud projects run these in overlapping cycles rather than a strict waterfall, but every phase happens.
Walking the current processes, agreeing what must change and what is fine as it is, and settling scope in enough detail that everyone is talking about the same project. Decisions deferred here reappear later at three times the cost.
Chart of accounts, dimensions, entities, currencies, approval rules, item and customer structures. The aim is to configure rather than customise, so future updates arrive without a regression testing project attached.
Customers, suppliers, items, open transactions and opening balances, extracted, cleansed, mapped and loaded in trial runs before the real one. This is consistently the most underestimated phase in the plan.
Connecting the systems that stay: ecommerce, EDI, payroll, CRM, bank feeds, warehouse hardware. Each one needs an owner on both sides and a test that proves it works with real data volumes, not a sample.
Your own people running real scenarios end to end, from quote to cash and requisition to payment, in a copy of the configured system. Sign-off should mean the business has tried it, not that the partner has demonstrated it.
Role-based training close enough to go-live to be remembered, a cutover plan with a rehearsed sequence and a rollback position, and hypercare in the weeks afterwards while the first month end runs.
A single-entity, finance-first cloud ERP rollout with reasonably clean data commonly runs six to twelve weeks from kick-off to go-live. That covers general ledger, payables, receivables, banking, purchasing and core reporting.
Add stock, multiple warehouse locations, several legal entities, multi-currency consolidation or project costing, and four to six months is the honest range. Manufacturing with bills of materials, routings and capacity planning sits at the upper end of that, or beyond it where the shop floor process is being redesigned at the same time.
Two factors move these more than any other. The first is data: if customer, supplier and item records need consolidating and de-duplicating, that work happens either before the project or during it, and during it is slower and more expensive. The second is decision latency. A project waiting a fortnight for a chart of accounts decision has simply lost a fortnight.
Year-end and peak trading periods are worth planning around rather than through. Going live at a natural accounting boundary simplifies opening balances, and no warehouse team should be learning a new system during their busiest month.
Almost never for technical reasons. These are the patterns that show up repeatedly.
A project lead without authority or protected time cannot settle cross-department disagreements, so decisions queue and the timeline stretches quietly.
Rebuilding existing workarounds in a new system delivers the same problems at higher cost. An implementation is the one realistic opportunity to change how things run.
Dirty, duplicated or incomplete master data derails testing and destroys confidence at go-live. Cleansing early is cheaper than cleansing under deadline.
A single session a week before go-live is not training. Role-based, scenario-driven preparation is what separates a calm first month from a chaotic one.
Asking for code before living with the standard process locks in assumptions that turn out to be wrong, and adds a testing burden to every future update.
When the executive sponsor stops attending after contract signature, scope creeps, priorities drift and nobody is left to say no on behalf of the business.
Implementation services normally exceed first-year licensing, and the variables that move the number are predictable: the count of legal entities, currencies and stock locations, whether manufacturing or warehouse management is in scope, how many integrations are needed, how much reporting must be rebuilt, and the condition of your data.
What rarely moves it is the software itself. Two organisations of the same size buying the same product can receive quotes that differ substantially, and the difference is almost always scope, not licensing.
Compare quotes on assumptions rather than totals. How many days of data migration are included, how many integrations, how many test cycles, whose responsibility is data cleansing, what happens if user acceptance testing finds a gap, and what support looks like in the first month end. A quote that is silent on those is a quote that will grow.
Budget for year two as well. Licensing recurs, support is typically a monthly retainer or a block of hours, and most organisations make further changes within twelve months once they understand what else the platform can automate.
Tell us your scope, your entities and where your data sits today, and we'll give you an honest view of the timeline, the internal effort required and what it would cost.
A single-entity, finance-first rollout on a cloud ERP with clean data commonly runs six to twelve weeks. Multi-entity, multi-currency, warehouse or manufacturing projects with integrations usually run four to six months. Enterprise programmes run considerably longer. Data quality and the availability of your own team move timelines more than anything the partner controls.
Discovery and requirements, solution design, configuration, data migration, integration, user acceptance testing, training, go-live and post-go-live support. Cloud implementations run these in overlapping cycles rather than strict sequence, with the business seeing working configuration early instead of at the end.
Implementation services normally exceed first-year licensing. Cost is driven by the number of legal entities, currencies, stock locations and manufacturing or warehouse processes, the number of integrations, how much reporting must be rebuilt, and the state of your existing data. A finance-first single-entity rollout sits at the low end; multi-site manufacturing at the high end.
Rarely for technical reasons. The recurring causes are an unclear scope agreed by nobody in particular, no empowered internal owner, replicating existing bad processes rather than improving them, underestimating data cleansing, treating training as a week before go-live, and an executive sponsor who disengages once the contract is signed.
An executive sponsor who can settle disputes, a project lead with real authority and protected time, and a process owner from each affected area - finance, purchasing, warehouse, sales, operations. These people need capacity carved out of their day job. Where that does not happen, the timeline slips regardless of how good the partner is.
Phasing is the safer default for most mid-sized organisations. Finance and purchasing go live first, then stock and warehouse, then projects or manufacturing. It reduces the risk concentrated on any single weekend and lets the team build confidence. A single big-bang go-live suits smaller, simpler scopes where phasing would create more integration work than it removes.
