ERP Implementation Checklist — The First 90 Days

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.
• Month 15+: Continuous improvement. Phase-2 modules, additional integrations, ongoing optimisation.

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.

Related Topics

• ERP migration playbook
• ERP TCO calculator
• ERP for 50 to 100 employees