How Long Does ERP Implementation Take? Realistic Timelines

A phase-by-phase answer to how long an ERP project takes, the things that make it longer, and a contrasting timeline for an accounting core you integrate through an API.

A small company moving to a cloud ERP with standard modules typically needs three to six months from signing to go-live. A mid-sized company with several entities, custom workflows and integrations typically needs six to twelve months. A large multinational rollout runs one to three years, often in waves by region or business unit. These are ranges that match what implementation partners publish and what finance teams report; they are not the output of a survey, and a specific project can fall outside them in either direction.

The single number people want does not exist, because "implementation" is nine separate pieces of work, and the length of each depends on decisions the buyer makes before the project starts. This article breaks the timeline into those pieces, shows what stretches each one, and then describes a different calendar: the one you get when the accounting core is an API your own software talks to rather than a system you configure.

The nine phases and what drives each

Phase	Typical duration	What drives the length
Selection	1–3 months	Number of vendors shortlisted, demo rounds, reference calls, procurement rules
Design	2–8 weeks	How many processes must be mapped, whether the team agrees on them, how much the vendor's standard flow is accepted as-is
Data migration	4–16 weeks	Quality of master data, how many years of history move, number of source systems
Configuration	4–12 weeks	Number of entities, charts of accounts, countries, tax regimes, approval flows
Integration	4–20 weeks	Count of systems to connect (bank, payroll, e-commerce, CRM, warehouse), quality of each side's API
Testing	3–8 weeks	Number of end-to-end scenarios, whether test data is realistic, how many defects the first pass finds
Training	2–6 weeks	Headcount, role diversity, how different the new process is from the old one
Go-live	1–2 weeks	Cutover method (big-bang or phased), timing against period end
Hypercare	4–12 weeks	Open-defect count at go-live, first month-end close, first VAT return from the new system

The phases overlap in practice. Integration starts while configuration is still running; training often overlaps with testing. A realistic plan is not the sum of the column, but the critical path usually runs through data migration and integration, and those two are where most slips come from.

What makes it longer

Customisation. Every change to the vendor's standard behaviour has to be specified, built, tested, documented, and then re-tested at every future upgrade. A project that accepts the standard process for 90% of flows and customises the rest tends to finish; a project that starts by replicating the old system's screens tends not to.

Dirty master data. Duplicate customers, suppliers with three spellings, items with no unit of measure, a chart of accounts that grew by accretion for a decade. Migration cannot be faster than the cleanup, and cleanup is done by the people who also have day jobs. This is the most common cause of a slipped go-live date, and the least visible in the original plan.

Multiple entities. Each legal entity needs its own chart, numbering, VAT registration, bank accounts and period close. Intercompany flows between them need a design of their own. Multiply the configuration phase by the entity count, then add the consolidation design on top.

Multi-country tax. A company selling into several EU member states has to get place-of-supply rules, reverse charge, OSS reporting and the local filing formats right in the new system before the first return falls due. If the vendor's localisation for a country is partner-built rather than native, that partner's availability becomes part of the critical path.

Integrations with weak APIs. An ERP that exposes only file-based imports forces every connected system into a batch pattern, and every batch pattern needs reconciliation logic that someone has to write and test.

A go-live date fixed before scope. When the date is set for political reasons and scope is discovered later, the project either cuts testing or moves the date. Both are expensive.

What makes it shorter

Accepting the vendor's standard processes where the business is not actually different.
Cleaning master data before the project starts, not during it.
Migrating opening balances plus open items rather than full history, and keeping the old system readable for lookups.
Choosing a cutover date at a period boundary with a locked, reconciled closing trial balance.
Naming one process owner per module with the authority to decide.
Testing with real documents from the last twelve months, not with invented samples.
Picking a system whose API lets integrations be built and tested in parallel with configuration rather than after it.

A different calendar: the API-first accounting core

The timelines above describe a system that humans configure through screens and then use through screens. There is another shape of project, and it has a different clock. When the accounting core is an accounting API, the integration work moves to the front, and most of the configuration phase disappears because there is less to configure: the chart, the tax rules and the filing formats arrive with the product.

What that looks like with Nordlet, stated as what the product does today rather than as a promise:

Day one: a sandbox company. A sandbox company is created from the app or with one API call. It behaves exactly like a real company, with the same modules and the same endpoints, and you can run as many as you need. The getting-started guide walks through the first calls.

Days one to five: the first working flow. Create a partner, create an invoice, issue it, receive a payment, read the journal entry the issue produced. Every operation is a POST /v1/{module}/{resource}/{action} call with a JSON body, and typed SDKs exist for nine languages, so the first flow is a few dozen lines of code. Retries are safe because an Idempotency-Key header replays the stored response instead of creating a second invoice.

Week two: history. The migration importer takes the chart of accounts, partners, items, opening balances or the full journal history, open customer and supplier invoices, fixed assets with depreciation to date, and stock on hand, and writes them in one database transaction. The check-only endpoint (migration/books/validate) runs every validation and writes nothing, so you iterate on the package until it reports no errors, then run migration/books/import once. If any row fails, nothing is stored.

Weeks two to four: the rest of the integration. Bank feeds through PSD2 connections, camt.053 statement import, Stripe exports, webhooks such as sale_invoice.paid so your system reacts to events instead of polling. Each piece is a separate endpoint and can be built by a separate developer in parallel.

Compliance: already registered. The VAT treatment of a cross-border sale is resolved by the EU VAT engine, and the filing calendar for the company's country is populated from built-in rules. The filing support table lists, for all 30 countries, which deadlines Nordlet files itself, which it builds a file for, and which are keyed in by hand. None of that is project work.

Period close as the test. The first month-end close is where an ERP project finds out whether it worked. With an immutable ledger and period locking, a posting dated into a locked month is rejected with a 409, so the close is enforced by the system rather than by discipline, and integration bugs that would have been found in hypercare surface in the sandbox instead.

Honest limits of that calendar: it covers the accounting, tax and filing core. If your project also needs warehouse management, manufacturing scheduling or a CRM, those are either Nordlet modules you integrate the same way (inventory, production, e-commerce orders, leads) or systems that sit beside it, and the integration work for the latter is still yours. Nordlet is also a young product, in early access in 2026 and onboarding design partners, which is a factor in any vendor decision.

How to estimate your own project

Count entities, countries and VAT registrations. Each one is configuration work in a traditional ERP and a company record in an API-first one.
Count integrations and check each system's API before signing. A file-only interface roughly doubles the integration estimate.
Decide how much history to migrate. Opening balances plus open items is weeks; full multi-year history is months.
Decide the cutover date from the period calendar, not the other way round. A year-end or quarter-end boundary with a reconciled closing balance is the cheapest cutover there is.
Assume the first close takes twice as long as a normal one, and budget hypercare for the first VAT return and the first payroll run from the new system.
Write the acceptance test before the project starts: the list of documents, reports and filings that must come out of the new system correctly for the first closed month. The pre-production test plan is one template for the accounting part.

FAQ

Can an ERP implementation take less than three months?

Yes, for a single-entity company that accepts standard processes, migrates opening balances only, and has one or two integrations. For an API-first accounting core the first working flow is measured in days, and the longest remaining item is usually the data migration package.

Which phase slips most often?

Data migration, followed by integration. Both depend on the state of systems the vendor does not control: the quality of your existing data and the APIs of the systems you connect.

Should we migrate full history or only opening balances?

Opening balances and open items are enough for the new system to be complete from the cutover date, and they take a fraction of the time. Full history is worth it when you need comparatives inside the new system or when the old system is being switched off entirely. Nordlet's importer accepts either.

Is a phased rollout faster than a big-bang cutover?

Phased rollouts take longer in total but carry less risk per step and let the team learn from the first entity before the next. Big-bang is shorter when the organisation is small enough that one cutover weekend covers everything.

How is "implementation" different for an API-first product?

There is no screen-by-screen configuration project. The work is integration and migration, done by developers against a sandbox, and the compliance layer (VAT rules, filing formats, calendars) ships with the product. The trade-off is that someone on your side writes code.