ERP Implementation — A Practitioner's Playbook

ERP implementation is the discipline of turning a signed software contract into a system that runs the business reliably. The discipline is harder than the contract, longer than the buyer expected, and more dependent on the implementation partner than on the software itself. Public failure rates — widely quoted at 30 to 50 per cent of ERP projects — reflect mostly poor implementation execution rather than poor software choices. The good news: the playbook for a successful implementation is well understood, and the patterns that produce failure are predictable enough to design against.

This guide describes the seven phases of a typical mid-market ERP implementation, the choice between big-bang and phased rollout, the critical success factors that distinguish stable go-lives from messy ones, and the cutover-weekend mechanics that nobody includes in their plan until they have lived through a bad one. It draws on patterns from DACH Mid-Market implementations specifically, but most of the playbook generalises. We treat the topic operationally rather than theoretically: the goal is to help internal project managers and steering committees ask the right questions and recognise the warning signs in time to fix them.

The seven phases of ERP implementation

Mid-market ERP implementations in DACH follow a recognisable seven-phase rhythm. Naming varies between methodologies (SAP Activate, Microsoft Sure Step, NetSuite SuiteSuccess) but the underlying shape is consistent:

Kickoff and planning (2–6 weeks). Project charter, steering committee, governance, master plan, scope confirmation, change-control procedure, risk register, communication plan. The output is a baseline plan that everyone signs.
Process design and fit-gap (6–12 weeks). Process workshops by functional area, fit-gap against the platform standard, customisation decisions, integration design, data-migration strategy. The output is a solution design document and a customisation backlog.
Configuration and customisation (8–24 weeks). System configuration, customisation development, integration build, report development. The longest single phase. Runs in parallel with data preparation and training development.
Data migration and integration testing (4–10 weeks). Master-data extraction, cleansing, transformation and load; integration testing; performance testing. Often the phase where timeline slip becomes visible.
User acceptance testing (4–8 weeks). End-to-end testing on the production-like environment with the business's own scenarios and master data. The phase where unresolved process questions surface, often forcing late configuration changes.
Training and cutover (3–6 weeks). User training delivery, final data migration, cutover-weekend execution, parallel-running period if applicable, go-live decision.
Hypercare and stabilisation (4–12 weeks post-go-live). Intensive support, daily issue triage, rapid fix deployment, transition from project mode to operations. Closes formally when issue volumes return to operational baseline.

Total elapsed time runs 6 to 18 months for typical Mid-Market implementations, longer for multi-site or multi-country roll-outs. Compressing below this range almost always sacrifices either process design or testing, both of which surface as problems within three months of go-live.

Big bang vs phased rollout

The choice between big-bang and phased rollout is one of the few implementation decisions that genuinely shapes the project. The trade-offs:

Big bang

All modules, all locations, all users go live on the same date. Advantages: shorter overall timeline, lower integration complexity (no need to maintain interfaces between old and new systems during transition), cleaner architecture from day one. Disadvantages: higher risk concentration on one date, larger training and change-management effort in one window, less room for course correction. Best fit: small to mid-sized companies with limited site count, strong project discipline, and tolerance for cutover-weekend operational risk.

Phased by module

Financials first, then sales, then purchasing, then production. Each phase 3 to 9 months apart. Advantages: lower risk per phase, ability to learn from earlier phases, easier change management. Disadvantages: temporary integrations between old and new systems carry operational and audit risk; longer overall timeline; transition periods when the business runs on two systems simultaneously. Best fit: larger mid-market and enterprise implementations where the cutover risk of a true big bang is unacceptable.

Phased by location

Pilot location goes live first; lessons learned applied to subsequent waves; remaining locations roll out over 6 to 18 months. Advantages: pilot validates the design before scale-up, change-management lessons transferable. Disadvantages: heterogeneous estate during the rollout window, potential pilot bias if the pilot site is unrepresentative. Best fit: multi-site companies and groups with multiple operating entities.

Hybrid: phased by module within a phased by location

Common in enterprise rollouts. Pilot site goes live with the full module footprint; subsequent sites roll out by module wave. Highest complexity but lowest risk concentration. Used when the implementation runs 18 to 36 months across multiple countries.

Critical success factors

Eight factors recur in successful implementations and are missing in failed ones. Internal project managers and steering committees should treat these as a checklist to revisit monthly:

Active executive sponsorship. A sponsor at managing-director or board level who actually attends steering meetings, makes scope decisions, and confronts internal resistance. Nominal sponsorship without operational engagement is the most common failure mode.
Empowered project manager on the buyer side. Full-time allocation, authority to make scope and resource decisions, direct reporting line to the sponsor. Part-time project managers handling implementation as a side project fail predictably.
Process owners with capacity to engage. Functional process owners (finance, sales, operations) released from operational duties to engage with the implementation. The 20 per cent backfill cost is the single highest-return implementation investment.
Realistic data-migration plan. Master-data quality assessment in the first six weeks, dedicated data-migration workstream, multiple migration rehearsals before go-live. Most cutover-weekend failures trace to data, not to software.
Discipline on customisation. A clear rule that customisation requires explicit business-case justification, not implementation-team default. Each customisation adds testing scope, upgrade friction and operational cost for the life of the system.
Genuine end-to-end testing. Testing with real business scenarios, the buyer's own master data, and real users — not vendor-led smoke testing. UAT failures caught here cost a fraction of the same failures caught post-go-live.
Investment in change management. 10 to 15 per cent of implementation budget allocated to communication, training and adoption support. Companies that under-invest here consistently see lower user adoption and longer time-to-value.
Hypercare staffing model. A dedicated hypercare team for the first 4 to 8 weeks post-go-live, with daily triage and rapid fix deployment. Hypercare that shares staff with new-project work fails to give users the response they need in the most fragile period.

Common implementation pitfalls

Six pitfalls account for most public ERP project failures. Each is well-documented and predictable; each remains common:

Pitfall 1: scoping the project around the software rather than around the business processes. The implementation becomes a series of configuration tasks rather than a process-improvement exercise. The result is an automated version of the old way of working, with all its inefficiencies preserved.

Pitfall 2: under-resourcing the buyer side. Implementation consultants outnumber internal staff three-to-one; internal staff are part-time on the project; process owners stay full-time in operational roles. The implementation finishes nominally but operational ownership is shaky from day one.

Pitfall 3: customising to preserve unique processes that turn out to be merely habitual. Most “unique processes” in mid-market companies are local variations on standard patterns. Customisation built to preserve them adds cost permanently while delivering value only to the people who do not want to change.

Pitfall 4: deferring data cleansing until after go-live. Migrating dirty data is fast; living with dirty data in the production system is slow and expensive. Data cleansing should happen during implementation, not after.

Pitfall 5: skipping the cutover-weekend dress rehearsal. The cutover sequence (final extracts, transformations, loads, reconciliations, opening balances) has enough steps and dependencies that a real-time rehearsal is essential. Implementations that skip rehearsal regularly discover cutover-weekend blockers at 2am on a Saturday.

Pitfall 6: declaring go-live successful too early. A go-live that processes the first day's orders is not stable. Stability comes from running cleanly through month-end close, quarter-end close, and the first inventory count. Hypercare should formally end only after these milestones, not after the first week.

Cutover weekend mechanics

The cutover weekend — the 48 to 72 hours when the old system is closed, data is migrated, and the new system opens for business — is the most intense operational moment of any ERP implementation. A typical sequence:

Friday close (T-0). Final transactions in the legacy system. Inventory snapshot. Open-order extraction. Open-receivable and open-payable extraction. Trial balance reconciliation. Sign-off from finance.
Friday evening to Saturday morning (T+0 to T+12 hours). Master-data and transactional-data extracts from the legacy system. Transformation according to the migration ruleset. Initial loads into the new system. Reconciliation checkpoint 1: master-data counts.
Saturday (T+12 to T+24 hours). Open-transaction loads (orders, receivables, payables, inventory). Reconciliation checkpoint 2: financial trial balance reconciles to the legacy. Reconciliation checkpoint 3: inventory totals reconcile.
Sunday (T+24 to T+48 hours). Spot checks on critical master data and transactions. Integration testing against external systems (banking, e-commerce, EDI). Reconciliation checkpoint 4: end-to-end scenario tests. Go/no-go decision in late afternoon.
Sunday evening (T+48 hours). Final cutover decision. Communication to users. Opening of the new system for Monday operations.

The cutover sequence should be rehearsed at least twice on a production-like environment before the real weekend. The rehearsals reliably surface 10 to 30 issues per run, each of which would otherwise become a cutover-weekend incident. Rehearsals are not optional for any project above 500,000 EUR.

Hypercare — the first eight weeks post-go-live

Hypercare is the formal intensive-support period that follows go-live. Typical structure:

Week 1: daily issue triage, rapid fix deployment, dedicated floor-walker support, real-time monitoring of key transactions. Issue volume usually peaks here.
Weeks 2–4: daily triage continues, fix deployment moves to scheduled releases, monitoring continues. Issue volume falls but persistent issues become visible.
Weeks 5–8: twice-weekly triage, weekly release cadence, formal incident reporting. The first month-end close happens in this window and exposes finance-specific issues.
Exit criteria for hypercare: issue volume returned to operational baseline, month-end close completed without unresolved issues, knowledge handover complete from implementation team to operations team.

Hypercare staffing is typically 50 to 70 per cent of implementation-team headcount, including buyer-side and partner-side. Companies that demobilise the implementation team at go-live consistently see longer hypercare periods and higher residual issues. Companies that retain a strong hypercare team typically exit hypercare cleanly within 6 to 10 weeks.

Frequently Asked Questions

How long does a typical mid-market ERP implementation take?

For a Mittelstand company of 50 to 250 staff on a Tier-2 platform, the implementation phase (excluding selection) typically runs 6 to 12 months. Selection adds a further 4 to 6 months upstream; hypercare and stabilisation add 3 to 6 months downstream. Total elapsed time from selection kickoff to operational stability is 12 to 24 months. Larger mid-market implementations (250 to 1,000 staff) regularly run 18 to 36 months. Enterprise transformations exceed three years.

What does an ERP implementation cost?

Implementation services typically cost two to three times the first-year software licence. For a Mittelstand company of 50 to 250 staff, implementation services run 250,000 to 800,000 EUR. Add integration, data migration, training, infrastructure, internal staff cost and contingency and the total project cost lands at 500,000 to 1,500,000 EUR. Upper Mittelstand projects (250 to 1,000 staff) run 1,500,000 to 4,000,000 EUR. Enterprise transformations exceed 10,000,000 EUR.

What is the right ratio of consultants to internal staff?

For most mid-market projects, the ratio runs 1:1 to 2:1 (one to two consultants per internal team member). Heavier on consultants signals that internal capacity is too thin, which becomes a problem at go-live and afterwards. Heavier on internal staff signals that the buyer is funding a learning curve that slows the project. The right answer depends on what the internal team can sustain after go-live, not what looks affordable during the project.

Should we choose big bang or phased rollout?

For small to mid-sized companies (under 500 staff) with limited site count and strong project discipline, big bang usually delivers the cleanest outcome. For larger mid-market and enterprise implementations, phased rollout reduces risk concentration but requires investment in temporary integrations between old and new systems. The choice is partly cultural: organisations with high tolerance for cutover-weekend operational risk go big bang; those without phase the rollout.

What is the most common reason ERP implementations fail?

The most common visible failures trace to scope creep and customisation; the most common underlying failures trace to under-resourced internal teams. Implementations where process owners stay full-time in operational roles and engage with the project only at workshops consistently produce systems that do not match the business. Implementations with dedicated, empowered internal resources produce systems that fit.