Go-live is over. Teams have celebrated, the integration partner has signed the acceptance report, and leadership has received a reassuring slide deck. Three weeks later, the accounts payable clerk is still using a spreadsheet for invoice reconciliation, sales reps are entering orders twice, and IT is fielding 40 support tickets a day.
This is not an implementation failure. It is a post go-live management gap. Cutover is not the end of an ERP project — it is the beginning of real-world use. The first 90 days determine whether your ERP investment delivers results in 12 months or in three years.
This guide gives you a phased methodology and an operational checklist to navigate this critical window.
Why the First 90 Days Are the Real Test of an ERP Project
Most project managers measure ERP deployment success by the go-live date. That is the wrong metric. What matters is actual user adoption three months after cutover.
The distinction between “successful go-live” and “ERP truly adopted” is fundamental. A successful go-live means the system is technically live, data has been migrated, and users have been trained. An adopted ERP means that business processes genuinely run through the tool, data is reliable, and teams no longer rely on parallel workarounds.
Between those two states lie 90 days of intensive work.
The majority of adoption problems surface in the first 30 days: users discover the gap between classroom training and operational reality, real-world transaction volumes expose performance issues that went undetected in UAT, and edge cases — the ones not covered during acceptance testing — come flooding in. This is the highest-risk period, and the one most often left without a structured plan.
Phase 1 (Days 0–30): Hypercare and Critical Incident Management
Define the Hypercare Team Before Go-Live
Hypercare is the period of intensified integrator presence immediately after cutover. It typically lasts two to four weeks. Its effectiveness depends entirely on what was agreed before go-live.
The hypercare arrangement must be defined precisely in your post-implementation support contract:
- Named people, not roles. “One senior functional consultant available Monday–Friday, 08:00–18:00” is an enforceable clause. “Support available as needed” is not.
- Escalation channels. Define a clear P1/P2/P3 circuit with contractual response SLAs at each severity level.
- Duration and exit criteria. The hypercare cell closes when measurable thresholds are met — not when the calendar says so. Example: P1 ticket volume below a defined threshold for two consecutive weeks, and daily active login rate above a defined percentage.
Without this contractual grounding, the integrator leaves after two weeks “as planned” and you are left with a ticket queue your internal team cannot absorb.
KPIs to Monitor Daily in Days 1–30
During hypercare, track four categories of metrics every day:
| KPI | Frequency | Alert threshold |
|---|---|---|
| Open P1 tickets | Daily | > 3 simultaneous |
| Unresolved P2 tickets > 48 h | Daily | > 10 tickets |
| Login rate per module (% active users) | Daily | < 80 % of target |
| % of transactions processed outside ERP | Daily | > 15 % |
| Average P1 resolution time | Weekly | > 8 business hours |
| User satisfaction (pulse survey) | Weekly | Score < 3/5 |
The last metric — transactions outside the ERP — is the most important and the hardest to measure. It means detecting users who continue processing operations outside the system, whether from habit or because the ERP does not yet meet their need. You detect it by reconciliation: if the order volume in the ERP is 20 % lower than actual business volume, there is a leak somewhere.
Days 1–7 Checklist: 10 Non-Negotiable Checks
In the first seven days after go-live, systematically validate these points:
- User access. 100 % of accounts activated, initial passwords distributed, profiles and permissions verified.
- System performance. Response times on key transactions measured and compared against contractual SLAs.
- Active interfaces. All integrations with third-party systems (banking, logistics, e-commerce) confirmed operational.
- Backup and recovery. First production backup executed and restoration tested.
- Migrated data. Consistency check on accounting balances, inventory levels, and open customer balances.
- Approval workflows. Purchase order and invoice approval workflows operational and tested by department managers.
- Print and EDI. Legal documents (invoices, delivery notes) compliant with regulatory requirements.
- Internal helpline. Key users have a dedicated contact channel and a clear escalation path.
- Team communication. Leadership message reaffirming support for the project and available help channels.
- Incident log. A centralised tracking tool (ticketing system or shared file) is live and capturing all reported issues.
Phase 2 (Days 31–60): Stabilisation and Skills Development
Detect Shadow IT Before It Becomes the Norm
ERP shadow IT — the parallel practices users develop to work around the new system — is the most reliable indicator of an adoption problem. It takes several forms:
- Shared spreadsheets in Teams or SharePoint that “centralise” data that should live in the ERP
- Power BI dashboards connected to manual data extracts rather than the ERP’s APIs
- Email-based approvals for transactions that should flow through ERP workflows
To detect these, do not rely on voluntary reports — users rarely admit to circumventing the tool. Use three techniques instead:
Login log analysis. If a module shows a login rate below 60 % of target users at Day 45, the module has an adoption problem, not just a learning curve.
Unreconciled accounting entries. If ERP accounting balances do not match bank data without manual intervention, transactions are still flowing outside the system.
One-on-one interviews with key users. Ask directly: “Are there any processes you still manage outside the ERP?” Key users will answer honestly if you make clear that the goal is to fix the problem, not to sanction anyone.
Close Hypercare Contractually
The end of hypercare must be formalised, not tacitly assumed. Before reducing integrator presence, confirm that:
- P1 ticket volume has been stable below your alert threshold for at least two weeks.
- Your internal key users are autonomous on standard use cases.
- Level-1 support procedures are documented and your team can execute them.
- The post-hypercare support scope is signed (see our guide on negotiating support contracts).
Do not allow the integrator to “wind down” gradually without a formal handover. Each reduction in availability must be agreed in writing and tied to measurable criteria.
Managing Configuration Corrections Through a Lightweight Process
The Days 31–60 window systematically surfaces needs for corrections: a workflow that is too rigid, a calculation rule that does not match your operational reality, a report that is unavailable for a frequent use case. These corrections are legitimate and expected — no ERP configuration is perfect at go-live.
The risk is handling them chaotically. Put a minimal process in place:
- Single intake channel. Every correction request comes through one channel (a dedicated email alias or a ticketing tool).
- Weekly triage. Key users and the project manager qualify requests together — bug fix, enhancement request, or missing training.
- Business-impact prioritisation. P1 (blocking), P2 (workaround exists), P3 (improvement).
- No production change without sign-off. Even “minor” configuration changes go through a test environment and formal approval.
This is not bureaucracy. It is what allows you, 18 months later, to explain why your ERP behaves differently from its original configuration — and to replicate those corrections in your documentation.
Phase 3 (Days 61–90): Optimisation and Industrialisation
First Monthly Close Under the ERP: Budget Double the Time
The first monthly close after go-live is the moment of truth for finance and accounting teams. Without preparation, you risk a close that takes twice as long as expected, at a point when teams are already exhausted.
Prepare this event one week in advance:
- Finance briefing. A dedicated work session to walk through the new close procedures in the ERP and identify every step that differs from the previous system.
- Documented fallback plan. If a critical close function does not behave as expected, what is the workaround procedure? It must exist on paper before the problem occurs.
- Consultant availability. Contractually secure a functional consultant’s presence for the first close, even if hypercare has formally ended.
- Extended timeline. Communicate to leadership upfront that first-month close times will exceed the normal baseline — do not discover this on the last working day of the month.
Identify 3–5 Visible Functional Quick Wins
Between Days 60 and 90, teams have absorbed the initial shocks and are beginning to stabilise their practices. This is the right moment to demonstrate ERP value to internal sceptics.
Identify three to five quick improvements that were impossible with the legacy system and can be delivered without heavy development:
- A new automated dashboard replacing a weekly Excel report
- An automatic stock alert on critical SKUs
- A one-click customer overdue report
- A digitised purchase order approval eliminating an email chain
These quick wins serve two purposes. First, they motivate teams who invested in the transition and were beginning to question the return on investment. Second, they convert sceptics into advocates — nothing persuades like a concrete improvement on someone’s own workstation.
Prepare the Post-Project Review and ERP Life Plan
At Day 90, run a formal project review with key stakeholders: executive leadership, business unit heads, CIO, and the integration partner. This review covers:
- 90-day retrospective. Critical incidents encountered, decisions made, variances from the original plan.
- Actual adoption rate by module. Factual usage data, not estimates.
- Delivered vs. planned functional scope. What is in production, what was deferred, and why.
- ERP life plan. The priority roadmap for the next 12 months, the update cadence, and the change governance model.
This last point is often skipped. Formalising the ERP life plan at the end of the 90-day window prevents the system from becoming a frozen snapshot of its initial configuration, disconnected from your business as it evolves.
The 10 Metrics to Monitor for 90 Days
| KPI | Frequency | Owner | Alert threshold |
|---|---|---|---|
| Open P1 tickets | Daily | Project Manager | > 3 simultaneous |
| P2 tickets > 48 h unresolved | Daily | IT Director | > 10 tickets |
| Login rate (% active users) | Daily | IT Director | < 80 % of target |
| % transactions outside ERP | Weekly | Key users | > 15 % |
| User satisfaction (score /5) | Weekly | Project Manager | < 3/5 |
| Average P1 resolution time | Weekly | Integrator | > 8 business hours |
| Qualified correction requests open | Weekly | Project Manager | > 20 unactioned |
| Accounting reconciliation gap | Monthly | CFO | Any gap > 1 % |
| Monthly close time vs baseline | Monthly | CFO | > 2× baseline |
| Internal user NPS | D30, D60, D90 | Project Manager | Score < 6/10 |
The 5 Most Common Post Go-Live Mistakes
1. Disbanding the project team too early
With go-live signed off, the project manager is pulled to other assignments and key users return to full-time operational duties. The post go-live phase has no pilot. Countermeasure: keep a dedicated project manager at a minimum of 50 % for the first 60 days, and run formal weekly reviews for 90 days.
2. Not contractualising hypercare exit criteria
The integrator leaves “as planned” without defined exit criteria having been set. You discover your team is not ready. Countermeasure: include measurable exit criteria for hypercare closure in your support contract (see the section above).
3. Accepting corrections “in the next release”
Functional issues identified in Days 1–30 are regularly deferred to the “next delivery” by the integrator. Three months later, nothing has changed and users have built their own workarounds. Countermeasure: require a dated correction plan for every qualified P1 and P2 issue.
4. Neglecting communication with non-technical teams
Business teams know the ERP launched, but they do not understand why certain features are not yet available, and they interpret problems as permanent failures. Countermeasure: send a brief weekly update (five lines, no technical jargon) stating system status, fixes in progress, and upcoming improvements.
5. Not documenting procedures as you go
Configuration corrections and new business procedures go undocumented “because there is no time.” Six months later, a team member leaves and no one knows how a given process works. Countermeasure: enforce a simple rule — every validated correction is documented within 48 hours, without exception.
Weekly Executive Reporting Template
This five-metric format covers the essentials without burying the executive team in operational detail:
| # | Metric | This week | Last week | Trend |
|---|---|---|---|---|
| 1 | ERP transaction volume | X entries | Y entries | ↑ / ↓ |
| 2 | % active users | X % | Y % | ↑ / ↓ |
| 3 | Incidents opened / closed | X / Y | A / B | ↑ / ↓ |
| 4 | User satisfaction (pulse survey) | X / 5 | Y / 5 | ↑ / ↓ |
| 5 | Corrective actions in progress | N actions | M actions | ↑ / ↓ |
Add two context lines below the table: “Key highlights this week” and “Decisions required from leadership.” This format takes 30 minutes to prepare and gives leadership a clear read without requiring any technical background.
To go deeper on the two topics that most determine post go-live success, read our guide to ERP change management — in particular the sections on identifying resistance and measuring adoption — and our full guide to negotiating a post-implementation support contract, which gives you the contractual clauses to secure before go-live to protect your post-deployment support.
