.jpg)
Quick Answer:
If you're trying to put a date on your ERP go live, you've probably already collected three different answers from three different vendors, and none of them explained what the number was built on. That's the real problem with most timeline conversations. A figure like "twelve weeks" or "nine months" means very little until you know which phases it includes, who owns the decisions inside each one, and what happens when your data turns out to be messier than anyone assumed. So this post works in the other direction: we'll walk through the stages in order, put realistic durations against each, and show you what stretches or shortens an ERP implementation timeline in practice. Zanovoy is a NetSuite Alliance Partner and an implementation partner for Coupa, Rillet, and Campfire, so the ranges below come from projects we run, not from a brochure.
How long does ERP implementation take is the first question almost every finance leader asks, and the only accurate first answer is "it depends on four things." Scope (how many modules and entities you are standing up), data (how much history you are bringing across and how clean it is), integrations (how many systems the new platform has to talk to on day one), and decision speed (how quickly your team can answer the questions the project team puts to them). The software itself is rarely the constraint. Cloud platforms can be configured quickly. What takes time is the work around the configuration.
With that caveat in place, the average ERP implementation time falls into fairly consistent bands by company size. These are general industry ranges for planning purposes, not promises, and the platform you choose moves them in either direction.
Our own published ranges sit at the faster end of those bands because they describe focused scopes. A focused NetSuite implementation for a mid market company typically runs 10 to 16 weeks. Campfire deployments typically run 8 to 12 weeks, Coupa AP automation often runs 6 to 8 weeks, and a Rillet implementation can go live in about 45 days when scope is narrow and data is clean. The pattern behind all of those numbers is the same: a narrow scope and prepared data compress the schedule, and a broad scope or messy data stretches it. We'll come back to that in the section on what moves a timeline.
Choosing an ERP Implementation Methodology Before You Build the Schedule
Before anyone drafts an ERP project plan, it helps to settle the ERP implementation methodology, because the methodology decides how the phases relate to each other. A strictly sequential approach is predictable and easy to audit but pushes surprises late. An iterative approach puts working software in front of your users early, which surfaces misunderstandings sooner but needs more of your team's time.
Most successful finance-led projects end up with a hybrid. The phases and their exit gates are sequential, so everyone knows what has to be true before the project moves on. Inside the build phase, the work runs in short iterations, with your controller and AP lead reviewing real configuration instead of reading a design document. That hybrid is the shape of the ERP implementation process described below, and it is why you will see phases overlap on any realistic schedule. Data migration starts before configuration finishes. Test planning starts before the build is done. Treating the phases as strict boxes is one of the quieter reasons projects run late.
The Seven ERP Implementation Phases, in Order
Different firms label these differently, and you will see "ERP implementation stages," "phases," and "steps" used almost interchangeably. We use phases for the seven major blocks of work and ERP implementation steps for the tasks inside them. The phases, in order: discovery and planning, design, build and integration, data migration, testing, cutover and go live, and hypercare. The sections that follow take each one in turn, with typical timing for a mid-market cloud project.
Phase 1: The ERP Discovery Phase (Typically 2 to 4 Weeks)
The ERP discovery phase is where the project either gets its foundation or inherits its future change orders. The purpose is to document how your finance and operations teams actually work today, what the new system has to do differently, and who is accountable for each decision. It is not a software demonstration, and it is not a sales handoff.
The steps inside discovery are consistent. You and the project team map the current-state processes: the close calendar, order-to-cash, procure-to-pay, intercompany, revenue recognition, and every spreadsheet that currently patches a system limitation. You then define future-state requirements and rank them, separating what is regulatory or contractual from what is a preference. The team inventories every system that has to integrate, confirms the data sources for migration, names the project sponsor and the decision owners, and agrees the scope baseline that every later change request will be measured against.
If a fit-gap analysis was not completed during selection, discovery is the last responsible moment to run one. We cover that exercise in detail in our guides on fit-gap analysis for CFOs and on auditing ERP fit for manufacturers, and the short version is that gaps found here are priced and planned, while gaps found in testing become change orders.
Phase 2: Solution Design (Typically 3 to 5 Weeks, Overlapping Discovery)
Design turns requirements into a blueprint your team can sign off on. It covers the chart of accounts and segment structure, the entity and subsidiary hierarchy, the revenue recognition rules, approval workflows and delegation of authority, role and permission design, the reporting model, and the integration architecture. Every requirement from discovery gets a disposition: native configuration, scripted extension, connected third-party tool, or an accepted limitation.
This is the phase where finance expertise matters most, because the design decisions are accounting decisions. How you structure the chart of accounts determines how easily you can consolidate and report for years afterward. A CPA-led design team asks questions platform-only consultants tend to skip, such as how a contract modification will flow through revenue recognition, or what an auditor will want to see in the approval trail. The exit gate is a signed design document, and every ambiguity left open there reappears as rework in testing.
Phase 3: Build, Configuration, and Integration (Typically 4 to 8 Weeks)
Build is the phase most people picture when they think of implementation, and in a cloud ERP implementation it is often the shortest relative to the effort around it. The team configures the platform to the signed design: subsidiaries, accounts, workflows, roles, saved reports, and the customizations that discovery and design agreed were genuinely necessary. Cloud platforms make configuration fast, which is exactly why discipline matters.
Integrations are built in parallel, and they deserve their own line in the ERP project plan, because they are a common source of late surprises. Each connected system (procurement, CRM, payroll, banking, a billing engine) needs mapped fields, authentication, error handling, and a plan for who monitors the connection after go-live. In a connected finance stack, we build and maintain these through our zConnect integration platform, so the connections have an owner after launch rather than becoming unmanaged scripts. The build phase ends with a configured, integrated system in a test environment and a configuration workbook that documents every setting, which later becomes the reference for your administrators.
Phase 4: ERP Data Migration (Typically 4 to 6 Weeks, Running Alongside Build)
ERP data migration is the single most common reason a project slips, and the reason is almost never technical. The extraction and loading tools are mature. The problem is that legacy data reflects years of inconsistent entry: duplicate vendors, customers with three spellings, inactive accounts that still carry balances, and open transactions nobody has reconciled since the last system change. Cleaning that is a business task your team owns, and it competes with their day jobs.
A sound migration follows a repeatable sequence. First, decide what comes across at all: opening balances, open items (unpaid invoices, open purchase orders, unfulfilled sales orders), master data, and only as much transaction history as you genuinely need for reporting and audit. Then extract, cleanse, and map the source fields to the new structure. Load into a test environment, reconcile to the source (a trial balance tie-out is the minimum standard), and fix what does not match. Then repeat. Plan for at least three full migration cycles, commonly called mock loads, because the first always reveals mapping errors, the second proves the fixes, and the third proves the process can be run to a clock. Each load should end with a documented reconciliation that someone in finance signs, since that sign-off is also your evidence for the auditors later.
Start data cleanup in the first weeks of discovery, not after the build is complete.
Phase 5: The ERP Testing Phase (Typically 3 to 5 Weeks)
The ERP testing phase is where you find out whether the system works for your business, not just whether it works. It runs in layers. Unit and system integration testing confirms that configuration and integrations behave as designed. User acceptance testing (UAT) puts real scenarios in front of the people who will run them, using migrated data: a full procure-to-pay cycle, a month-end close, an intercompany transaction, a revenue recognition schedule on a real contract. Regression testing confirms that fixing one defect has not broken something else, and performance testing matters for any process with high volume.
Two practices separate projects that go live calmly from those that do not. The first is writing test scripts from your documented business scenarios rather than from the vendor's feature list, so you are testing your edge cases and not the demo path. The second is a parallel close, where finance runs a recent period in the new system and compares the results to the legacy books. A parallel close is the closest thing to a rehearsal of the first real month-end, and it routinely exposes issues no individual script would catch. The exit gate is a formal UAT sign-off with defects triaged: critical issues closed, minor issues logged with an owner and a date.
Phase 6: Cutover and ERP Go Live (Typically 2 to 3 Weeks of Preparation, a Short Window of Execution)
Cutover is the transition from the legacy system to the new one, and the ERP cutover plan is the document that choreographs it. It is a time-sequenced runbook that lists every task, the person responsible, the expected duration, the dependency on the previous task, and the checkpoint at which the team decides to continue or stop. A good cutover plan includes a transaction freeze window in the legacy system, a final data extract and load, a final reconciliation, user access activation, integration switch-over, and a communication plan so your staff and external parties know when the new system is live.
Three elements deserve particular care. The first is at least one full dress rehearsal of the cutover, timed, so you know the real duration of the final load instead of estimating it. The second is explicit go or no-go criteria agreed in advance: reconciliation tolerances, open critical defects, training completion, and integration status. Deciding the criteria before the pressure arrives keeps the decision honest. The third is a rollback plan, even if you never use it, which defines the point beyond which you commit and the steps to revert before that point.
Timing the ERP go live deserves thought as well. Most finance teams prefer the first day of a fiscal period, so opening balances are clean and there is no mid-period split to reconcile. Avoid year-end, quarter-end close, and audit fieldwork. A go live set a few weeks earlier or later to protect a close is almost always cheaper than one forced onto a calendar that collides with it.
Phase 7: ERP Hypercare (Typically 2 to 6 Weeks, Often Through the First Full Close)
ERP hypercare is the intensive support window immediately after go live, when the project team stays close to the business and fixes issues at a faster pace than normal support allows. It exists because the first weeks of live operation always surface things testing could not: a rarely used approval path, a report that needs a different grouping, a user who needs an additional permission, an integration that behaves differently with real volume.
Good hypercare is structured, not informal. There is a defined duration, a triage process with severity levels, a daily or twice-weekly review of open items, and a clear handoff at the end to ongoing support. For finance teams, the milestone that matters is the first full month-end close on the new platform, so hypercare commonly runs through that close and the following week. The exit criteria are simple: no open critical issues, the close completed within an agreed time of the target, and the support team confident enough to take over.
This is also the point where many implementation partners leave. Our managed services team picks up where hypercare ends, so the people who know the design are still accountable for it.
A Sample ERP Implementation Roadmap for a Mid Market Project
To make the timeline concrete, here is how the phases fit together in an illustrative 16-week ERP implementation roadmap for a mid market company with a few entities and a handful of integrations. Treat it as a structure to adapt, not a quote. Notice how much the phases overlap.
An ERP Implementation Checklist: What Must Be True Before Each Gate
A schedule only protects you if each gate has real entry criteria. Use this ERP implementation checklist as a starting point, and add items specific to your business.
- Before discovery ends: a named executive sponsor, named decision owners for finance, procurement, and operations, a ranked requirements list, and a documented scope baseline.
- Before design is signed: every requirement has a disposition, the chart of accounts has been reviewed against reporting needs, and your auditors have seen the approval and control design.
- Before build is accepted: every configuration setting is recorded in the workbook, every integration has an owner and an error-handling path, and customizations are limited to those that design approved.
- Before testing starts: test scripts are written from business scenarios, test data has been loaded from a reconciled mock migration, and the people running UAT have time blocked on their calendars.
- Before go live: UAT is signed, the parallel close results are explained, training is complete, the ERP cutover plan has been rehearsed, and go or no-go criteria are met.
- Before hypercare ends: no open critical defects, the first close is complete, support ownership is confirmed, and lessons learned are recorded for the optimization backlog.
What Stretches an ERP Project Timeline, and What Shortens It
When a project overruns, the cause is usually one of the same few things. Looking at them honestly during planning is the cheapest schedule protection available.
- Data quality. Legacy data that nobody has cleansed is the leading cause of slipped timelines, ahead of configuration and ahead of technology.
- Decision latency. Every open question has a cost in days. A project team waiting a week for an answer on a revenue recognition policy loses a week, and delays compound across phases.
- Scope growth. Requirements added after the design sign-off are the most direct route to a missed date. A change control process that prices and schedules each addition makes the trade-off visible.
- Integration complexity. Each extra connected system adds mapping, testing, and monitoring work, and legacy systems with limited APIs add more.
- Resource availability. The people who know your processes best are also the people running your close. If they are not released for project work, the schedule absorbs the shortfall.
The things that shorten a timeline are the mirror image. Complete a fit-gap analysis before you sign. Start data cleanup in week one. Name decision owners with authority to decide. Lock the scope baseline and manage changes formally. Phase the rollout when the business allows, bringing core financials live first and adding modules in later waves. A phased approach does not always reduce total effort, but it reduces the risk concentrated in any single go live.
ERP Implementation for Small Business vs Mid Market ERP Implementation
The phases are the same at every size. What changes is how much weight each one carries. ERP implementation for small business projects tend to be shorter because the scope is narrower: one entity, fewer integrations, less history to migrate, and fewer approval layers to design. The risk in a small business project is the opposite of the entERPrise one. With fewer people, there is no spare capacity, so a single finance manager can become the bottleneck for design decisions, data cleanup, and testing at the same time. The remedy is a tight scope and a partner who carries more of the configuration and migration workload.
A mid-market ERP implementation adds the complexity that makes the phase model earn its keep: multiple entities, intercompany eliminations, multi-currency, revenue recognition rules, procurement controls, and enough integrations that the architecture needs to be designed rather than improvised. The testing phase grows because more scenarios have to be covered, and the cutover plan grows because more systems switch over together. This is the segment where the difference between a configured, lightly customized platform and a heavily customized one shows up most clearly in the schedule, and in the cost of every future upgrade.
Where Zanovoy Sits in This
Zanovoy is a NetSuite Alliance Partner and an implementation partner for Coupa, Rillet, and Campfire, and our team is largely CPA-led, which means the people scoping your schedule have run a close and know which phases protect it. We build the ERP implementation plan around your close calendar, not a generic project template, and we say so when a date you are hoping for is unrealistic. Where your finance stack spans several platforms, our zConnect integration platform, built on 500+ connections, keeps the integration work on the same schedule as the configuration instead of trailing behind it. We have delivered 1,000+ implementations across 5 continents with a team of 120+ finance transformation professionals, and we stay engaged through hypercare and managed services, because a finance system is never really finished at go live.
.png)
.png)