The first 90 days of an ERP implementation set the trajectory for the whole project. Mid-market ERP rollouts that go wrong rarely fail in cutover; they fail in the first three months when the charter is unclear, the sponsor is disengaged, the data-cleansing kick-off is delayed and scope creep begins. By the time the project reaches the realisation phase, the patterns that determine success or failure are largely locked in.
This checklist is structured around three windows — days 1–30, days 31–60, days 61–90 — with a clear set of deliverables, milestones and warning signs for each. It is written for projects in the DACH Mid-Market at 50–500 employees, where the project team is small, the sponsor is the CFO or COO, and the partner does most of the technical heavy lifting. The numbers and observations come from typical mid-market projects; the editorial line is neutral.
Days 1–30: project setup and foundation
The first month is about getting the project on solid procedural ground. The deliverables here are unglamorous — charters, governance documents, communication plans, meeting cadences — but every project that skipped them later wished it had not.
Week 1 (days 1–7)
Kickoff workshop with the steering committee, project team, key users and the partner. One full day, in person if possible, with a clear agenda covering scope, success criteria, risks and the next 90 days.
Project charter signed off by the executive sponsor and the steering committee. The charter names the sponsor, the scope, the success criteria, the budget envelope and the high-level timeline. Charters that are never signed off become projects without anchors.
Project tooling stood up: project plan in MS Project, Smartsheet, Jira or equivalent; document repository with clear folder structure; communication channels (Teams or Slack).
Weeks 2–3 (days 8–21)
As-is process documentation begins for the strategic processes — not all processes, just the 8–15 that matter. Aim for one-page process maps with the key handoffs, decisions and current pain points marked.
Role assignments confirmed: project manager (full-time), business analyst (full or part-time), key users by module (typically 30–60 % of their time for the project duration), technical lead from the partner, executive sponsor with a weekly slot.
Steering committee cadence established: every 4–6 weeks for go/no-go decisions, escalations and budget tracking. Avoid weekly steering — it dilutes the meeting and the sponsor disengages.
First sandbox environment provisioned by the partner so that the project team can start exploring the system.
Week 4 (days 22–30)
First fit-gap workshops kick off, typically one half-day per module (finance, procurement, sales, warehouse, production where relevant). The partner presents the standard, the key users describe the actual process, and gaps are documented.
Initial data-migration scoping: which entities (customer master, supplier master, item master, open transactions, history) need to migrate, in what volumes, from which source systems?
End-of-month-1 review: charter signed, plan agreed, team in place, sandbox available, first fit-gap workshops complete. Sponsor confirms green light to continue.
Data migration: start early, not at the end
Data migration is the single most common cause of failed or delayed ERP projects. The standard mistake is to treat it as a cutover-weekend activity rather than a project-long workstream. In a well-run 90-day window, data migration is already in progress by week six, not week sixteen.
The data-migration workstream in the first 90 days should produce:
Source-system inventory: a documented list of every system holding data that will migrate — the legacy ERP, the standalone CRM, the warehouse spreadsheet, the supplier Excel file maintained by purchasing — with the data volumes and quality status for each.
Field-level mapping document: for each entity (customer, supplier, item, open order, posted transaction), every source field mapped to the corresponding target field with transformation rules where needed. This document is iterative; the first version is wrong but it has to exist.
Cleansing plan and kickoff: the master-data cleansing effort is almost always longer than the project team expects (typically 3–6 months of dedicated effort) and has to start in parallel with fit-gap, not afterwards. Identify the dedicated data-quality lead by day 45 at the latest.
First test migration: by day 75–90, the first end-to-end test migration of a meaningful subset of customer and supplier master into the sandbox, with reconciliation against source.
The signature warning sign of a project heading for trouble: by day 60 nobody is named as the data-cleansing owner, and the assumption is “we'll sort the data closer to go-live”. Projects that say that always slip cutover by 4–8 weeks. See our ERP migration playbook for the structured approach.
Days 31–60: configuration, customisation and early testing
The second month moves from foundation to substance. Fit-gap concludes, customisation scope is locked, and the test approach is defined.
Weeks 5–6 (days 31–42)
Fit-gap workshops conclude. Each module owner produces a fit-gap document listing which processes fit the standard (no action), which need configuration (parameter changes within the standard) and which need customisation (code or extension development).
Customisation specification: for every gap that requires development, a written specification with functional requirements, technical approach and effort estimate. The partner produces these; the business signs them off. Specifications that are not signed off become the source of the standard scope-creep argument later.
Customisation budget locked. The total customisation effort gets compared to the original budget. Almost always the first pass exceeds the budget — the steering committee makes the call on what stays, what is deferred to phase 2 and what is dropped entirely.
Weeks 7–8 (days 43–56)
Configuration of the development environment begins. The partner configures the system to the agreed standard plus configurations; customisation development starts in parallel for items that can be specified.
Interface design: every integration to a third-party system (e-commerce platform, EDI partners, payroll, banking, BI) gets a written design document — protocol, data exchange format, error handling, retry logic, monitoring. Interfaces are the second most common cause of cutover slippage after data migration.
Test strategy defined: which test cycles (unit, module, integration, UAT, performance, end-to-end), who runs them, what passes and what fails. Without a documented test strategy, testing always under-runs.
Key-user training plan: the partner produces a training plan covering when key users get trained (typically months 4–6 of the project), in what format, with what materials. Key-user training is a force multiplier for end-user training later.
Weeks 9 (days 57–60)
Mid-project review: scope, schedule, budget and risk register all reviewed by the steering committee. Red/amber/green status on each. Adjustments made if needed.
End-of-month-2 milestone: fit-gap complete and signed off, customisation specifications signed off, interface designs complete, test strategy documented, training plan in place. Data migration in progress.
Training and change management
Training and change management are not month-three activities tacked on at the end — they need explicit attention in the first 90 days even though most of the actual training happens later. The reason: change-management strategy and the structure of the training programme have to be set early to be effective.
What the first 90 days should produce on the change-management side:
Stakeholder map: who in the organisation is affected, how, and what their current attitude is (champion, supporter, neutral, sceptic, blocker). Update this every quarter through the project.
Communication plan: the rhythm of project updates to the wider business — monthly newsletter, quarterly town hall, manager briefings. The first communication goes out by day 30 at the latest, not at go-live.
Key-user network: 1 key user per 10–15 end users, named, briefed and given protected time. Key users are the multipliers for end-user training and the local trouble-shooters during hypercare.
Training format decision: classroom, e-learning, hands-on workshop, train-the-trainer? The right mix depends on user population — production line operators learn differently from finance team members. Decide the mix by day 75.
Works council (Betriebsrat) engagement: for any new system that touches HR data, time tracking, or productivity monitoring, the German Works Constitution Act (Betriebsverfassungsgesetz) requires formal co-determination. Engage the works council by day 30, with a formal information meeting by day 60.
Projects that defer change-management to the last two months almost always have a productivity collapse in week one of go-live — not because the software is broken, but because the users have not been brought along. This is the single biggest avoidable failure mode in ERP projects.
Days 61–90: configuration progress and the day-90 review
The third month consolidates what has been built and prepares for the move into realisation phase. Most mid-market projects do not go live in the first 90 days — the realistic horizon is 9–18 months total — but the day-90 milestone is the explicit go/no-go for moving from design into build.
Weeks 10–11 (days 61–77)
Configuration of the test environment substantially complete. The first integrated end-to-end scenarios run through the system — create a quote, convert to sales order, allocate stock, ship, invoice, post to ledger, reconcile to bank.
Interface development progresses on the priority integrations. By day 75, at least the financial-system, banking and core EDI interfaces have a working draft in the test environment.
Master-data cleansing visibly in progress. The data-quality lead provides a weekly status: customer master at 78 % clean, supplier master at 65 % clean, item master at 52 % clean. If those numbers are not measurable by day 75, the data migration is in trouble.
Change-management communications begin in earnest. The first general-employee newsletter, the first manager briefings, the first FAQ document.
Weeks 12–13 (days 78–90)
Detailed test plan ready. Test cases written for each module (typically 30–100 cases per module), with expected results and pass/fail criteria. UAT scripts drafted for key business processes.
Integration test plan ready: which end-to-end scenarios get tested, in what sequence, with what dependencies between modules.
Day-90 go/no-go review. The steering committee reviews progress against the original plan, the open risks, the budget consumption and the realistic projected go-live date. Honest projects accept slippage at this point if it is real; dishonest projects pretend the original date still holds and pay for it later.
The day-90 review is the most important governance moment in the project. By this point, the project team knows whether the original plan is realistic or fantasy. A steering committee that uses day 90 for honest replanning rather than performative reassurance gives the project the best chance of landing well.
Risks and typical pitfalls in the first 90 days
Five failure modes dominate the first-90-days statistics for mid-market ERP projects in the DACH region.
Charter not signed off. The most common foundational failure. Without an executive-signed charter, the project drifts — scope expands silently, success criteria shift, the sponsor disengages. The fix: refuse to start substantive work until the charter is signed.
Sponsor disengagement. The CFO or COO is enthusiastic in week one and absent by week eight. Steering meetings become operational rather than directional, hard decisions get deferred, scope creep accelerates. The fix: 30-minute weekly sponsor check-ins, with explicit decisions documented from each.
Scope creep starting in week three. Once key users see the new system, they start asking for additions — “while we're at it, could we also…”. Each ask is reasonable on its own and together they double the project. The fix: a formal change-request process from day one, with steering-committee sign-off for any addition.
Data-cleansing kicked too late. If by day 45 nobody has been named as the data-quality lead, the data migration is already in trouble. Cleansing is always longer than expected and always discovers issues that need business-side decisions (which customer record is the right one, which item should be retired). The fix: name the data-quality lead by day 30.
Partner over-promising in the kickoff. A partner that promises a 9-month implementation for a scope that realistically takes 14 months sets the project up to fail at the day-90 review. The fix: a partner challenge during selection — ask them to walk through similar projects with reference customers, with realistic timelines.
Compliance and regulatory requirements
Compliance work in the first 90 days is mainly about documenting what the system needs to support, not implementing it. The major DACH-specific topics:
GoBD (Principles for the orderly maintenance and retention of books): the German principles for proper accounting and document retention. The new ERP must support immutable accounting records, audit trails for every posting, and 10-year retention. Document the system's GoBD certification or self-declaration in the project file by day 60.
DATEV integration: nearly every German mid-market company uses a tax advisor (Steuerberater) on DATEV. The new ERP must export postings in DATEV format. Specify the integration mode by day 60 — XML, native DATEV-Connect, file-based.
E-invoicing readiness:ZUGFeRD/Factur-X for hybrid PDF/XML invoices in B2B, XRechnung for B2G. Germany now requires B2B e-invoicing as of 2025/2026 in a staged rollout. The new ERP must produce compliant outbound and receive compliant inbound. Confirm vendor capability by day 60.
GDPR and BDSG (Bundesdatenschutzgesetz, the German Data Protection Act that layers onto GDPR): data-processing register entries for the new system, deletion concepts for personal data (especially employee data), consent mechanisms where needed.
Industry-specific: BaFin for financial-services subsidiaries, MaRisk for risk management, KRITIS for critical-infrastructure operators, GMP for pharma manufacturing, HACCP for food.
The compliance workstream in the first 90 days should produce a written compliance register listing each requirement, the responsible person, the deadline and the evidence to be produced. Without this register, compliance issues surface during cutover and force last-minute scrambling.
Beyond day 90: how the project continues
Day 90 marks the transition from design phase to realisation phase. The deliverables of the first 90 days — signed charter, completed fit-gap, locked customisation scope, interface designs, test strategy, training plan, data-migration design — become the inputs to the next 6–12 months of build, test and cutover. The high-level shape of the rest of the project for a typical mid-market implementation:
Months 4–6: Build. Customisation development complete, interfaces functioning in test, master-data cleansing 80–90 % complete, key-user training delivered.
Months 7–9: Test. Module test, integration test, user acceptance test, performance test. End-user training delivered in waves. First test migration of the full data scope.
Months 10–11: Cutover preparation. Cutover plan finalised, dress-rehearsal migrations, communication intensifies, hypercare model agreed with the partner.
Month 12: Cutover. Go-live weekend, intensive support week 1, stabilisation through month 2.
Months 13–15: Hypercare. Intensive support, bugfixing, gradual handover to line operations.
The most important governance moment after day 90 is the cutover go/no-go decision, typically 4–6 weeks before planned go-live. By that point the test results, data-migration dress rehearsals and training completion all give a clear signal whether the go-live date is achievable or whether a 4–6 week delay is the responsible choice. Projects that pushed through a no-go signal almost always paid for it in extended hypercare.
How many internal person-days do we need to plan for the first 90 days?
For a mid-market project with around 80 users, 250 to 400 internal person-days are realistic for the first 90 days. Of that, roughly 60 days go to the project manager, around 120 days to the key users, and the remainder to IT, data cleansing and testing. This order of magnitude is an empirical value, not a fixed norm; the exact distribution varies with industry, size class and the customization depth of the specific ERP setup. Above all, it is important to make these internal efforts visible early and protect them against day-to-day business, as underestimated internal workload is among the most common project risks.
Who should provide the project manager – us or the implementation partner?
In practice, a dual setup works best: an internal project manager who holds functional leadership and decision-making authority, complemented by a project manager on the implementation partner's side for external coordination. A purely externally staffed project lead is considered risky, because internal acceptance, knowledge transfer and ownership suffer as a result. The internal project manager should be sufficiently released from operational duties and have a clear mandate from the steering committee. The optimal constellation depends on company size, process complexity and the strategic IT roadmap.
When should data migration and master-data cleansing start?
No later than in the first two project weeks — clearly within the first 30 days and not shortly before cutover. Master-data cleansing almost always takes longer than planned and otherwise blocks the entire migration on the critical path. Define data owners in the business departments early, hand cleansing responsibility over to them and establish a weekly measurement of data quality. Also plan at least three migration dry runs with validation by the business departments, because experience shows that data quality is rarely as good as initially assumed.
How long does a mid-market ERP implementation take overall until go-live?
The 90-day checklist described here covers only the foundation, configuration and initial testing phases; the actual go-live typically follows another 90 to 180 days later. The total duration of a mid-market ERP implementation usually ranges between six and eighteen months, depending on complexity, customization depth and data migration. Cloud or SaaS implementations shorten the timeline noticeably and are sometimes completed in three to nine months, while heavily customized on-premise projects can run considerably longer. The key is to consistently maintain the pace after the first 90 days through weekly steering and monthly steering-committee meetings.
Which regulatory obligations – such as GoBD and e-invoicing – do we need to consider during implementation?
Regulatory topics belong in the first 30 days, not at the end of the project. The GoBD require audit-proof process documentation, the immutability of posted records and traceable change histories, while the GDPR demands permission and deletion concepts as well as data processing agreements with cloud providers. For electronic invoicing: receiving structured e-invoices in domestic B2B transactions has been mandatory in Germany since January 1, 2025, while transition periods apply to sending — from 2027 initially for companies with more than 800,000 euros in prior-year revenue and from 2028 at the latest for all domestic B2B companies. Regulated industries such as pharmaceuticals or the food industry have additional requirements including GxP validation, batch traceability and audit trails, which must feed into the configuration early on.
Do we have to involve the works council in the ERP implementation?
If a works council exists, early involvement within the first 30 days is strongly recommended. Under German labor law, ERP systems regularly qualify as technical equipment within the meaning of § 87 (1) No. 6 BetrVG, because they are capable of monitoring employees' performance and behavior — this creates a co-determination right that extends across the entire implementation process up to go-live. It is common and sensible to conclude a works agreement that governs the permissible scope of analyses, the permissions concept and changed workflows. If the works council is involved too late, formal objections and considerable delays loom; a specific legal assessment should always be made with your own HR or legal department.
What should we do if the project is off track after 90 days?
Escalate early and transparently instead of sitting it out. Convene the steering committee, communicate the status honestly and deliberately adjust one of the three levers — scope, time or budget — rather than letting all three slip at once. The background is that a considerable share of ERP projects miss their budget or schedule targets, often due to underestimated effort, technology needed after the fact or organizational problems. An independent selection advisory or an external project audit often helps identify blind spots and define effective countermeasures before minor deviations escalate into a failed go-live.
