Custom ERP development timeline in NZ: how long it actually takes and how to phase it

The most-cited ERP implementation timelines — 6 to 12 months for a mid-market system — are for configuring software that already exists. The vendor's product is built; your team configures it, migrates your data, and trains your people. A custom ERP build is a different undertaking: the data model, business logic, user interface, integrations, and operational workflows all have to be designed and constructed from scratch. The timelines are longer, the phases are different, and the things that cause delays are not the same.

This guide is for NZ businesses considering a custom ERP build — or already in one — who want a realistic view of what drives the timeline, how to phase the work to reduce risk, and what tends to push projects beyond their original estimate.

Why the timeline depends on scope, not technology

Custom ERP projects do not have a standard timeline because they do not have a standard scope. The three variables that determine duration more than any other are: how many distinct business workflows the system needs to support, how many other systems it needs to integrate with, and how much complexity lives in the data model. A system covering one operational area (purchasing, or distribution, or customer account management) with two or three integrations and a clean data model builds faster than a system that replaces multiple legacy applications, integrates with eight external systems, and must handle complex pricing, financial consolidation, and compliance requirements simultaneously.

Realistic ranges for NZ businesses, measured from signed contract to stable go-live:

• Narrow-scope system (one business unit, 2–3 integrations, fewer than 20 users): 9–15 months.
• Mid-scope system (company-wide operation, 4–8 integrations, 20–100 users): 15–24 months.
• Full-scope custom ERP (multi-entity financials, complex operational workflows, 8+ integrations, 100+ users): 24–36+ months.

These ranges assume a properly documented scope going into the build. Projects that skip or rush a discovery phase and resolve requirements mid-build consistently add 3 to 6 months while scope questions that should have been settled before the first line of code get resolved during development.

The five phases of a custom ERP build

Regardless of scope, a custom ERP build moves through five phases, each with distinct deliverables and dependencies.

Discovery (4–8 weeks). Process mapping, data model design, integration assessment, and architecture decisions. The output is a documented scope — not a features list, but a definition of what the system must do, what data it must hold, what it must integrate with, and what the boundaries of phase one are. A discovery phase that produces this is the difference between a build that proceeds with shared understanding and one that surfaces fundamental disagreements during UAT.

Foundation build (8–16 weeks). The core data model, authentication and user management, primary data entities (customers, products, inventory, orders), and the first integration connection. This phase does not produce a working product — it produces the structure that everything else builds on. Teams that skip or compress the foundation build spend disproportionate time refactoring later.

Functional build (12–20 weeks). Business logic, operational workflows, reporting, secondary integrations, admin tools, and the features users will actually interact with. This is where the majority of the development work lives. For larger projects, multiple functional streams (ordering, inventory, financial, reporting) can run in parallel once the foundation is stable.

UAT and hardening (4–8 weeks). Structured user acceptance testing against documented scenarios, edge case resolution, performance testing, and a data migration dry-run. UAT cannot start usefully before the functional build is stable — beginning UAT on half-built features produces feedback about work that has not been done rather than feedback about work that has been done incorrectly.

Deployment and stabilisation (4–8 weeks). Final data migration, go-live, and a hypercare period where the team actively monitors the system and resolves issues before they become operational problems. The stabilisation period is often underestimated. Systems that go live and are handed over without structured hypercare consistently surface more problems in the first three months.

What can run in parallel — and what cannot

The common mistake in timeline planning is treating the five phases as purely sequential when several workstreams can run concurrently.

What can overlap: UI and UX design can run alongside the foundation build. Secondary integration builds (connecting to a B2B ordering portal, connecting to a reporting platform) can run in parallel with each other once the core data model is stable enough to integrate against. Training material preparation can begin during UAT.

What cannot: the core data model must be stable before business logic can be built reliably on top of it. Reporting cannot be finalised before the data structures it reads from are settled. UAT cannot produce useful findings before the functional build reaches a testable state. Data migration cannot happen before UAT confirms the system is ready to receive the data. These dependencies are not bureaucratic — they reflect the technical reality of what each phase depends on from the prior one.

NZ-specific factors that affect the timeline

Several NZ regulatory and operational requirements add complexity that generic ERP timeline guides — written for the US or UK market — do not account for.

GST and IRD compliance must be designed into the data model from the start, not retrofitted. The seven-year record-keeping requirement under the Tax Administration Act affects retention design. GST reporting periods, invoice tax status, and the April 2023 TSI rule change for electronic invoicing above $1,000 all have data model implications that surface early or late depending on when they are considered.

NZ ERP integration complexity varies significantly by system. On-premises NZ ERPs — Accredo, MYOB Exo, CSB-System, Pronto Xi — have different API coverage, different integration patterns, and different deployment environments than cloud systems. Integration complexity for these systems is frequently underestimated at the scoping stage, particularly for complex pricing hierarchy reads and historical data access.

MPI compliance for food businesses adds batch traceability requirements to the data model that affect both the inventory module and the ordering module. If MPI traceability is a requirement, it must be in the data model from the foundation build — not added as a late-stage feature.

NZ resource availability. The pool of developers and architects with deep experience in complex NZ B2B ERP systems is smaller than in Australia. Project timelines that assume a larger team can be assembled at short notice to compress a phase may not reflect the practical availability of senior NZ-based resource.

Why a phased rollout almost always beats a big-bang go-live

A big-bang go-live cuts over the entire business to the new system on a single date. Everything must work on day one. Any significant failure on that day affects the whole operation. For a food distributor, that failure might mean orders that cannot be processed, invoices that cannot be generated, or stock that cannot be confirmed.

A phased rollout brings one module or one business area live while others continue on existing systems. The B2B customer ordering platform goes live first, integrated to the existing ERP — giving the customer-facing operation the benefit immediately, while back-office operations continue unchanged. The ERP replacement, if required, follows in a subsequent phase. Zeabyte's food distributor clients — including Starfoods, Stevos, and Firstlight Frozen — typically go live on a B2B ordering platform integrated to their existing Accredo or CSB-System environment before any change to the ERP itself.

The phased approach limits blast radius, allows real-world usage to validate assumptions, and gives the team time to stabilise one phase before the next begins. The exception is where processes are so tightly coupled that running two systems in parallel is operationally impossible — some financial cut-overs fall into this category. For most NZ mid-market operations, though, phasing is the lower-risk path.

Four reasons custom ERP projects run late

1. Scope additions without timeline adjustment. New requirements added mid-build without formal change control extend the project without either party acknowledging the extension. The feature gets added; the go-live date stays unchanged; the team works to absorb the difference; the go-live date moves anyway, but later and without warning.
2. UAT starting before the functional build is stable. Testing half-built features generates findings about work that has not been done, not about work that has been done incorrectly. UAT that starts too early consumes testing capacity on development rework rather than on validation.
3. Data migration underestimated. Legacy data quality problems — duplicate records, inconsistent classifications, fields used for undocumented purposes — always take longer to resolve than initially estimated. A migration dry-run scheduled too close to go-live leaves no time to resolve what the dry-run finds.
4. Integration complexity discovered mid-project. NZ on-premises ERP API and file-based integration complexity — particularly for custom pricing hierarchy reads, historical data access, and file schema assumptions — is frequently underestimated at scope. Integrations that were budgeted as straightforward become the longest items on the critical path.

What a realistic timeline conversation looks like

A custom ERP development partner who gives you a precise timeline in the first conversation — before scope has been established — is giving you a number, not an estimate. Realistic timeline conversations name the variables that drive duration, identify the phases, flag the NZ-specific factors that apply to your environment, and return a range after a discovery phase has produced a documented scope.

The discovery phase guide covers what a properly run scoping engagement produces and why the outputs matter. The project governance guide covers how to manage the build once it is underway — change control, steering committees, UAT structure, and go-live risk management. For businesses still deciding whether to build custom or implement an off-the-shelf system, the custom ERP vs off-the-shelf guide covers the ownership economics and the decision logic. If you are considering a custom ERP build and want to understand what the scope and timeline look like for your specific environment, talk to the team — Zeabyte designs and builds custom ERP systems for established NZ businesses, including the ERP integrations that connect them to the systems they need to work with.