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.
Project duration depends heavily on company size and complexity: small and medium-sized enterprises opting for a close-to-standard cloud solution are usually live within three to nine months, while classic mid-market projects stretch over six to 18 months. Large enterprises and corporate groups with multiple sites, legacy-system replacement and deep integration realistically take 18 to 36 months. Industry statistics show that only about half of all projects stay within the planned timeframe and roughly a third takes somewhat longer than expected, which is why generous buffers for testing and data migration are advisable.
How much does an ERP implementation cost?
A common rule of thumb says that implementation amounts to one to three times the pure licence or subscription costs, since customising, interfaces, data migration and training account for the bulk of the effort. Licence or subscription fees often make up only about 20 to 35 percent of total project costs over the full term, with the far larger remainder going to services, internal staffing and operations. For a mid-sized company with around 200 employees, total budgets in the rough range of 200,000 to 600,000 euros are a plausible order of magnitude depending on complexity, although individual cases can deviate considerably. It is important to plan for hidden costs such as data cleansing, change management and additional licences from the outset, as budget overruns are common in practice.
Who leads an ERP implementation?
In the proven project setup there are two central roles: a dedicated internal project lead at the implementing company and a project manager on the side of the implementation partner. Strategically, the project is steered by a steering committee involving executive management, which decides on budget, scope and go/no-go. Operationally, the project is carried by so-called key users from the business departments, since they know their processes in detail, contribute requirements and later act as multipliers during training. It is critical to success that the internal project lead is given sufficient dedicated time and does not act merely on the side, because unclear responsibilities and lacking management commitment are among the most common causes of failure.
Why do so many ERP projects fail?
Industry analyses put the share of ERP projects that miss their targets in terms of time, budget or scope at around 55 to 75 percent depending on the source and sector, with only about 30 percent completed fully within the planned time and budget. The main reasons are rarely technical: inadequate change management and lacking user acceptance, poor master data quality, missing top-management commitment as well as unclear objectives and scope creep rank at the top. Studies show that human and organisational factors influence project success far more strongly than the software deployed. Those who invest early in data cleansing, professional change management and a clear requirements document reduce the risk considerably.
Big bang or phased rollout – which is better?
With the big-bang approach, the entire system goes live on a single cutover date (usually over a weekend), which avoids duplicate data maintenance and delivers value quickly, but carries a high risk because errors only become visible in live operation and fallback options are limited. The phased approach introduces modules, sites or legal entities one after another, allowing risks to be controlled and lessons learned to be applied early, but it entails months of duplicate maintenance and temporary interfaces between the legacy and the new system. As a rough guideline for the mid-market: big bang suits straightforward single-site projects with high organisational maturity and a cloud-first strategy, while complex multi-site initiatives usually fare better with the lower-risk phased approach. Running the legacy and the new system in parallel for a short period can additionally safeguard both variants.
How much effort does data migration involve in an ERP implementation?
Data migration is one of the most frequently underestimated work packages and, depending on the source and data quality, accounts for roughly 15 to 25 percent of total project costs — in complex cases even more. It comprises analysing the existing data, cleansing duplicates and outdated records, specifying the mapping between old and new fields, and several test migrations ahead of the actual cutover. At least three complete trial runs with subsequent validation via spot checks and totals reconciliation are recommended, so that there are no nasty surprises on the go-live weekend. Since data migration problems are among the most common triggers of delays and extra costs, additional time for cleansing is almost always a better investment than corrective work in live operation.
