How long does a custom ERP take?

A schedule follows scope, not the label ERP

ERP can describe anything from a stock and purchasing application for one operation to a multi-company financial, manufacturing and fulfilment platform. Those systems do not share a meaningful single duration. A credible schedule begins by defining which business events must work at the first release, which sites and legal entities are involved, and which existing systems remain authoritative. A narrow operational core can be delivered in months. Replacing finance, inventory, production, sales, procurement and reporting together introduces dependencies that commonly extend delivery across several release cycles.

Calendar time also differs from engineering effort. Stakeholder interviews, process decisions, data cleansing, user acceptance and supplier access all consume elapsed time even when no developer is blocked full-time. Adding engineers does not compress decisions or make source data understandable. The plan should expose both kinds of work and name the party responsible for each dependency. Dates presented before source systems, interfaces and approval routes have been examined are targets, not estimates. Discovery turns them into a sequenced plan with explicit assumptions and confidence.

The phases that make up the duration

A discovery phase usually occupies two to six weeks for a bounded system and longer where processes differ by site or entity. It should produce process maps, a domain model, integration and migration assessments, non-functional constraints, release boundaries and a costed delivery plan. Delivery then proceeds in vertical slices: a complete purchase-to-receipt flow is more testable than separate batches of screens, APIs and tables. Environments, deployment automation, identity and observability belong in the first slices because postponing them creates an artificial appearance of speed.

• Allow time to reconcile source records before transforming them.
• Schedule interface testing around the availability of external system owners.
• Reserve complete business cycles for acceptance, including reversals and exceptions.
• Plan cut-over rehearsals with measured timings and named decision points.
• Keep a stabilisation period after release rather than treating go-live as completion.

Migration is often the longest uncertain path

The number of rows rarely predicts migration difficulty. Meaning, consistency and reconciliation do. Legacy identifiers may have been reused, statuses may encode undocumented practices, and totals may only agree after off-system adjustments. Migration therefore needs profiling, mapping, cleansing ownership, repeatable transformations and reconciliation reports. At least one full rehearsal should run against a representative extract, followed by a cut-over rehearsal using the intended sequence. Historical data may remain in a controlled archive when moving it provides little operational value, but retention and access obligations must be designed rather than assumed.

What expands or compresses the plan

A single empowered product owner, accessible subject-matter experts and stable statutory requirements shorten elapsed time because questions are answered while context is current. Parallel approval committees, undocumented exceptions and integrations owned by unresponsive vendors do the opposite. Scope can be reduced safely by choosing a coherent first operating model, not by deleting controls. Removing journal approval, stock reconciliation or permission testing makes a release smaller only on paper. Phasing by site, process or entity is effective when interfaces between old and new states are explicit and temporary duplication is tolerable.

How progress should be judged

Progress is best measured by accepted business capabilities. A demonstrable order-to-cash slice includes permissions, accounting effects, notifications, reporting and failure handling, not merely an order form. Each iteration should retire uncertainty: prove a difficult integration early, reconcile a sample migration and test the highest-volume workflow under realistic conditions. A backlog of completed technical tasks can conceal an unusable system if cross-functional flows have never run. Acceptance criteria should state business outcomes and evidence, with defects prioritised by operational and financial consequence rather than visual prominence.

Set the date with evidence

An initial range can be set after discovery, then narrowed as the riskiest assumptions are tested. The release date should account for operational calendars, period close, seasonal peaks, training and support cover. A readiness review examines unresolved defects, reconciliations, user access, runbooks, rollback conditions and ownership after launch. If those controls cannot fit the desired date, reduce the release boundary or move the date. Compressing verification transfers time into production disruption, where correction is slower and evidence is harder to reconstruct.