A big bang ERP deployment is a weekend where no one sleeps and the CFO has the CTO’s number on speed dial. A phased rollout is eighteen months of running two systems that barely talk to each other. A parallel run is daily double entry that wears down accounting teams. A pilot is three months of wondering whether to roll it out. None of these four strategies is inherently good or bad. The question isn’t “which is the best.” The question is “which fits your context, your risk appetite, and your budget.”
This article dissects the four ERP deployment strategies, quantifies their real costs, and proposes a six-criteria decision tree to reach a clear recommendation for your specific project. It addresses the CIO, project manager, or executive sponsor starting an implementation in a mid-market or structured SME, deciding between a single switchover and a progressive deployment.
The four ERP deployment strategies and what they really mean
Before making a decision, we need to precisely define the options. The four strategies are not equivalent in cost, duration, or risk level.
Big bang: complete switchover over a weekend
All modules, all users, all sites switch simultaneously to the new system. The old ERP is shut down on Friday evening. The new one runs on Monday morning. In between, a 48 to 72-hour window to freeze data, execute migration, validate consistency controls, and open access.
This strategy is not the majority choice. According to Panorama Consulting’s 2025 report, less than a quarter of organizations choose a big bang deployment, partly because most projects involve multinational entities where simultaneous switchover is too risky.
Phased rollout: scope by scope
We break down the perimeter and switch in successive blocks. Three possible breakdowns:
- Geographic: site by site, country by country, or region by region.
- Functional: first finance, then procurement, then production, then sales. Each module is deployed across the full scope before moving to the next.
- By legal entity: first the pilot subsidiary, then the rest of the group.
Phased is the dominant strategy for multi-site and multi-entity projects. It smooths risk over time, but requires running old and new systems together for a period that can exceed 24 months on complex groups.
Parallel run: old and new systems running concurrently
The old and new ERP run simultaneously on the same scope for X weeks to X months. Each transaction is entered twice (or replicated via interface) and results are reconciled to validate consistency. This strategy is typical of sectors where a switchover error is unacceptable: banking (Basel III), insurance (Solvency II), healthcare (HIPAA in the US), sectors subject to SOX audits.
Parallel run is expensive. According to ERP Research, it accumulates three cost overruns: internal teams must enter each transaction twice, external consultants often support both environments, and legacy system licenses continue to be paid. Beyond 30 days of parallel run, costs become structurally heavy. Reserve for contexts where the constraint is regulatory, not discretionary.
Pilot: one test entity before generalization
We choose a representative entity (a subsidiary, a BU, a site) and deploy the complete new system there. We observe for 3 to 9 months. Then we generalize based on pilot lessons: refined configuration, calibrated training plan, proven data migration, validated change governance.
The pilot is not an autonomous strategy. It’s a preliminary step to a big bang or phased rollout on the rest of the scope. It costs a 3 to 9-month delay but mechanically reduces generalization risk: we’ve already seen what breaks, who resists change, which reports are really missing.
Big bang: for whom, why, at what cost
Contexts where big bang wins
Contrary to the dominant discourse that associates big bang with risk, there are contexts where this strategy is objectively the most rational:
- Single-site SMEs under 200 employees: the cost of running two systems in parallel is disproportionate to the security gain.
- Homogeneous business: if 90% of users apply the same processes (e.g., consulting firm, service company), training is shareable and simultaneous switchover simplifies governance.
- Truly obsolete legacy: when the old system can no longer be maintained (disappeared vendor, end-of-life hardware, untraceable skills), extending its life costs more than switching quickly.
- Constrained business window: between two closings, between two commercial campaigns, a weekend switchover may be the only option.
Hidden costs of big bang
A big bang is not “free” compared to phased. It shifts costs in time:
- Total mobilization over 48 to 72 hours: the integrator bills the go-live cell (10 to 25 consultants depending on size), internal teams are requisitioned, some functions switch to shift work.
- Binary risk: if the switchover fails, you must either rollback (operation rarely truly tested in real conditions) or live with a degraded system while stabilizing.
- Mandatory executive sponsor: without a leader capable of freezing specifications, arbitrating under pressure during switchover, and protecting the project team from last-minute requests, a big bang derails into crisis.
- Intense stabilization window: the two to four weeks post-go-live consume as much energy as the previous six months, with a 24/7 operational crisis cell.
Three quantified contexts
- Industrial SME 120 employees, single site: big bang weekend D-Day, 60-hour window, go-live budget £30,000 to £70,000. Justification: moving from aging Sage 50 to Sage X3 cloud on a single perimeter.
- Consulting firm 180 consultants, two offices: big bang on Sage Intacct, 48-hour switchover, go-live budget £20,000 to £40,000. Justification: identical processes, low turnover, few external interfaces.
- Pure-play e-commerce, 60 people: big bang on Microsoft Business Central during a three-day window in January (post-sales commercial lull), go-live budget £25,000 to £60,000. Justification: sales peak to avoid, inventory and orders too linked to segment.
Phased rollout: the complex project standard
The three possible breakdowns
The breakdown determines everything: duration, costs, complexity of temporary interfaces, change management workload.
- Geographic breakdown: adapted to multi-country groups where regulatory issues vary (chart of accounts, payroll, VAT). A pilot site in the UK, then Germany six months later, then Italy, etc.
- Functional breakdown: first finance (core), then procurement and supply chain, then production, then sales and customer service. Advantage: each wave sees an already operational ERP base. Disadvantage: during each intermediate wave, cross-functional processes require expensive temporary interfaces.
- Legal entity breakdown: subsidiary by subsidiary. Adapted to groups whose subsidiaries have similar business but distinct reporting and accounting entities.
How long really?
Public data on ERP deployment duration converges on wide ranges:
- A basic ERP deployment runs around 6 to 12 months, with a median close to 9 months for cloud SaaS projects on a restricted scope (source: Ultra Consultants).
- A complete multi-module deployment, on mid-market companies with multiple sites, typically reaches 18 to 24 months in traditional mode, and can exceed 30 months if the number of subsidiaries is high.
The classic phased trap: plan 12 months, deliver 24. Each intermediate wave awakens requirements that had slipped under the radar in design, extending the next one. A realistic phased schedule includes a 25 to 35% provision on total duration.
The dual-run trap
Throughout the phased duration, you’re running two or more systems together. It’s not a parallel run (the same data isn’t entered twice) but it’s cohabitation: the old and new ERP share responsibilities, connected by temporary interfaces.
This cohabitation costs:
- Cumulative licenses: the old system remains under maintenance as long as it carries part of the scope.
- Disposable interfaces: each temporary bridge (old ERP to new, new to legacy reporting, etc.) is developed then discarded when the scope switches.
- Doubled accounting load: month-end managed on two systems with manual consolidation for group reporting.
- Repeated change management: each wave relaunches communication, training, local support.
On phased projects that drag on, the cohabitation overrun represents a substantial part of TCO over the period, sometimes comparable to the initial project cost itself. See our detailed analysis in ERP total cost of ownership: the 8 hidden items.
Parallel run and pilot: hybrid strategies
Parallel run: the safety belt for regulated sectors
Parallel run is not a comfort strategy. It’s a disguised regulatory obligation. When a switchover error exposes the company to a regulator sanction (FCA for banks, PRA for insurance, CQC for healthcare), double entry for several weeks is no longer a luxury but an audit committee validation condition.
What really costs:
- Operational teams absorb doubled workload throughout the period. In a finance team of 15 people, this translates to three temporary hires or two months delay on other projects.
- The reconciliation cell (1 to 3 dedicated people) compares data from both systems weekly and traces discrepancies. It provides audit evidence for commissioning.
- Beyond 8 to 12 weeks, operational fatigue begins to degrade entry quality in both systems. A dragging parallel run ends up producing two incorrect datasets.
Pilot: validate before generalization
The pilot is not a POC. A POC is a sandbox (few users, data subset, no production impact). A pilot is a real deployment on a bounded scope, with official go-live and users working daily on the new system.
Typical use cases:
- Multi-entity group: deployment on the most representative subsidiary (often the most mature on processes, not the smallest), then generalization.
- International pilot site: the new system runs first on the UK site, then on German and Italian sites 9 months later with configuration already calibrated for local payroll and VAT.
A well-conducted pilot materially accelerates generalization. Configuration is already validated in real conditions, missing reports are identified, data migration has been tested on a complete dataset. Subsequent waves see their duration reduced by 20 to 40% compared to a first ex nihilo deployment.
Decision tree: which strategy for your project?
There’s no magic formula. But six criteria, honestly evaluated, point toward a dominant strategy.
The six deciding criteria
- Company size: under 200 employees, single site, single business → realistic big bang. Over 500 multi-site employees → almost mandatory phased.
- Number of sites/entities: single site → big bang or short pilot. Multiple sites with different businesses → phased by entity.
- Risk appetite: if the board refuses any binary scenario → phased or pilot. If the organization accepts rapid switchover with tested rollback plan → viable big bang.
- Regulatory constraints: sector under continuous audit (banking, insurance, healthcare, energy) → parallel run on financial core. Unregulated sectors → strategy of choice.
- IT maturity: structured IT department with proven integrator → big bang or rapid phased. Light IT, first major project → pilot then progressive phased.
- Budget: constrained budget with no dual-run provision → big bang. Comfortable budget with 25 to 35% cohabitation provision → viable phased.
Decision matrix
| Profile | Recommended strategy | Typical duration | Justification |
|---|---|---|---|
| SME < 200 employees, single site | Big bang | 6 to 9 months | Disproportionate phased TCO, homogeneous business |
| SME 200-500, 2-3 sites | Pilot then generalized big bang | 9 to 14 months | Pilot to validate, then rapid switchover |
| Mid-market 500-2000, 3-10 sites | Phased by entity or site | 14 to 24 months | Essential risk smoothing |
| International mid-market, 10+ sites | Progressive geographic phased | 24 to 36 months | Local regulatory complexity |
| Banking, insurance, healthcare | Finance parallel run + phased rest | 18 to 30 months | Required regulatory audit |
| Omnichannel retail seasonal peak | Off-season big bang + IT reinforcement | 9 to 12 months | Non-negotiable business window |
Signals forcing a strategy change mid-project
A strategy chosen at kickoff may need revision during design or testing. Signals that should trigger a review:
- More complex data migration than expected: if quality gaps detected exceed 15% of data stock, moving from big bang to phased avoids switchover with corrupted data.
- Functional scope creep: if specifications inflate by more than 30% between kickoff and end of design, phased becomes impractical (each wave will be rethought in progress). Returning to pilot helps stabilize scope.
- Executive sponsor departure: without visible, engaged sponsor, big bang becomes risky gamble. Switch to phased piloted by IT and finance.
- Regulatory event: new obligation (electronic invoicing, DAC7, CSRD) imposing target date. An 18-month phased may need to contract to big bang on the concerned module.
The 5 errors that derail deployment (all strategies combined)
Whatever the strategy, the same five errors systematically return in post-mortems:
- Underestimating data migration. Duplicates, inconsistent item codes, non-normalized historical charts of accounts mobilize 2 to 4 analysts for 3 to 6 months before switchover. The cost almost never appears in the initial budget.
- Go-live timing on critical fiscal or commercial period. Go-live two weeks before year-end closing, in the middle of Black Friday for a retailer, during subscription campaign in insurance: it’s risk we could eliminate free by shifting 6 weeks.
- Absence of tested rollback plan. Everyone writes a plan. Few teams really test it. The day we need to execute, we discover backups don’t restore, interfaces aren’t reversible, that going back would take 5 days.
- User communication too late. Announcing change two weeks before switchover guarantees maximum resistance. Organizations that succeed communicate from design phase, explain arbitrations, give visible milestones.
- No post-go-live crisis cell. On D+1 day, we need a physical or virtual war room, super-users identified by service, documented escalation levels, extended hours for support teams. Without this, each incident derails into business blockage.
An analysis that converges with Gartner 2024 peer community data: the majority of delays and failures don’t come from software but from these five project gray zones.
Go-live checklist (whatever strategy chosen)
A mandatory passage: the D-30, D-7, D-1 review. Each point must be formally validated by a named responsible.
| Milestone | Control point | Responsible |
|---|---|---|
| D-30 | Functional acceptance signed on all critical processes | Business project manager |
| D-30 | Data migration plan tested on complete dataset | Data manager |
| D-30 | End-to-end tested rollback plan | IT + integrator |
| D-30 | Training completed for 100% of D-Day go-live users | Change manager |
| D-7 | Specifications and interfaces freeze | Sponsor |
| D-7 | Crisis cell constituted and on-call schedule distributed | IT department |
| D-7 | D-1 and D+1 user communication distributed | Internal communication |
| D-7 | IT access reviewed (new system roles and permissions) | IT security |
| D-1 | Complete legacy system backup + restoration point | Infrastructure team |
| D-1 | Legacy system transaction freeze at H hour | Business management |
| D-1 | Go/No-Go in steering committee | Sponsor + IT |
| D-Day | Reference data switchover | Integrator |
| D-Day | Consistency control validation (totals, balances) | Finance director |
| D-Day | User access opening | IT support |
| D+1 | War room open, daily committee at fixed time for 10 days | Project manager |
This checklist is not exhaustive. It gives the form. Each project adds its specific business points (electronic invoicing acceptance, EDI integration, health data compliance, etc.).
To go further on project preparation, consult the three following resources that complement this strategic arbitration:
- The 5 phases of a successful ERP project details the breakdown of scoping, design, implementation, testing and deployment.
- How to choose your ERP integrator: 100-point scoring grid gives criteria to evaluate the partner side, including their ability to deliver in big bang vs phased.
- ERP total cost of ownership: the 8 hidden items quantifies the items that deployment strategy shifts.
If you’re in the scoping phase, a 3-month pilot on a bounded scope (one BU, one module, one site) remains the least costly way to validate your strategy hypothesis. Typical budget: £12,000 to £25,000. Result: a Go/No-Go decision on generalization, supported by real figures and not a forecast Excel.
