# ERP Go-Live Checklist: 40 Items Before You Switch On

> A comprehensive go-live checklist built from real ERP deployments — covering technical readiness, data validation, user readiness, rollback planning, and the first 48 hours.

URL: https://www.matthewswong.com/en/blog/erp-go-live-checklist/

- Author: Matthews Wong (https://www.matthewswong.com/en/about/)
- Published: 2025-06-10
- Updated: 2026-10-17
- Category: ERP

30% of ERP projects experience critical failures during go-live week, with the first 48 hours being the highest-risk period. I've been through several ERP go-live events as a freelance ERP consultant — some smooth, some terrifying — and the single biggest predictor of success is not the quality of the code. It's the completeness of the preparation. This checklist synthesizes what I've learned from both successful and failed go-lives into 40 actionable checkpoints organized by category. Run through this in the two weeks before your go-live date. If any item is red, you're not ready.

## Technical Readiness Checks

These are the infrastructure and system checks that confirm the environment is production-ready. Each must be verified in the production environment, not staging. 1. Production server provisioned and performance-tested under expected user load. 2. SSL certificates installed and valid for minimum 12 months. 3. Database backups configured and tested (restore a backup — don't just assume it works). 4. Monitoring and alerting set up (Grafana, UptimeRobot, or equivalent). 5. All environment variables and secrets confirmed in production config. 6. Application performance tested with realistic data volumes. 7. All third-party integrations (payment gateway, email, SMS) tested in production. 8. Rollback procedure documented and rehearsed.

### Data Readiness Checks

These confirm the migrated data is accurate and complete. 9. Final data migration dry run completed successfully. 10. Record counts validated (source = target for all entity types). 11. Financial balances validated (AR, AP, inventory values match last period close). 12. Spot check validation completed by business data stewards for 20+ records per entity. 13. Data cutover run book written and rehearsed. 14. Cutover migration window scheduled (weekend preferred). 15. Old system freeze date confirmed (no new transactions after this point). 16. Archive of old system data confirmed in secure, accessible storage.

### User Readiness Checks

These confirm users are trained and ready. 17. All users have login credentials and have successfully logged in to production. 18. Role-based permissions tested for every user role. 19. Training completed for 100% of users who will use the system on Day 1. 20. Training videos accessible and indexed in internal wiki. 21. Quick reference guides printed and distributed to key users. 22. Department champions confirmed and briefed on Day 1 support plan. 23. Support escalation path documented (who to call, in what order, for what type of issue).

> From my experience running ERP go-lives in my freelance ERP consulting work: run a go-live simulation the week before. Treat it exactly like the real go-live: execute the cutover run book, have all users log in and complete their Day 1 tasks, and time every step. Anything that fails in the simulation gives you one week to fix it. Anything that fails on actual go-live gives you a panic-filled weekend.

## Business Readiness Checks

These confirm the business is operationally ready for the transition. 24. All department heads have formally signed off on their UAT results. 25. Go-live date communicated to all staff including vendors and customers if applicable. 26. Customer-facing communications prepared if AR workflows change for customers. 27. Vendor-facing communications prepared if AP payment process changes. 28. Payroll calendar reviewed — confirm go-live doesn't conflict with payroll processing. 29. Month-end or year-end calendar reviewed — go-live should not be within 2 weeks of period close. 30. Executive sponsor has confirmed availability for go-live week.

> **The most dangerous words in ERP go-live: 'we'll fix it after'**

> I've heard 'we'll fix it after go-live' many times. It almost never happens. Post-go-live, the team is in firefighting mode, users are overwhelmed, and the implementation partner is wrapping up. Known defects that are accepted as 'post-go-live fixes' become permanent workarounds. Every item on your go-live checklist that you mark 'acceptable risk' should have a named owner, a specific deadline, and a defined impact if not fixed. Anything critical that cannot be fixed before go-live is a reason to delay go-live — not to proceed and hope.

## Go-Live Day Operations

These are the Day 1 execution steps. 31. War room or coordination channel established (Slack, Teams, or WhatsApp group with all key personnel). 32. Morning check-in call scheduled for 8:00 AM on go-live day. 33. First real transaction confirmed successful within first hour. 34. System performance dashboard visible to technical team throughout the day. 35. Issue log started — every reported problem logged immediately with severity, user, and timestamp.

## First 48 Hours: What to Monitor

The first 48 hours require dedicated technical coverage. Monitor: server CPU and memory under real user load (flag anything above 80% sustained), database query performance (slow queries will appear under real data volumes that staging didn't surface), error rates in application logs (anything above 1% of requests), email delivery success for any automated notifications, and user-reported issues through the support channel. Resolve P1 issues (system down, core process broken) within 2 hours. Resolve P2 issues (a workflow fails for a subset of users) within 24 hours.

## Hypercare: The 30 Days After Go-Live

Hypercare is the structured 30–90 day period after go-live where the implementation team provides intensive support. Plan for hypercare before you go live: who staffs it, what the support hours are, what the escalation path is, and when hypercare officially ends. In my freelance ERP consulting work, my standard hypercare covers 30 days of dedicated support with daily check-ins for the first 2 weeks and weekly reviews for weeks 3–4. Usage metrics, error rates, and user-reported issues are reviewed daily. Hypercare doesn't end at day 30 because the calendar says so — it ends when adoption metrics hit targets and the business is stable.

## Sources & Further Reading

- Panorama Consulting — ERP Hypercare Checklist and Post-Go-Live Support Plan — https://www.panorama-consulting.com/erp-hypercare-checklist/
- Microsoft Learn — Use the go-live checklist to make sure your solution is ready — https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/prepare-go-live-checklist
- Moxo — ERP go-live planning guide: Managing complex implementations gracefully — https://www.moxo.com/blog/erp-go-live-planning

> **Key takeaway:** Around 30 percent of ERP projects hit a critical failure during go-live week, and the first 48 hours carry the highest risk. A written checklist covering data reconciliation, access, cutover sequencing and rollback converts that window from improvisation into a rehearsed procedure.

## Source links

- https://www.panorama-consulting.com/erp-hypercare-checklist/
- https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/prepare-go-live-checklist
- https://www.moxo.com/blog/erp-go-live-planning

## FAQ

### Why are the first 48 hours after go-live considered the highest-risk period?

The first 48 hours expose issues that staging environments cannot surface — real user load, actual data volumes, and live integrations all behave differently than test conditions. Server CPU and memory, database query performance, error rates, and user-reported problems must be actively monitored during this window. Resolving P1 issues (system down, core process broken) within 2 hours and P2 issues within 24 hours is critical to keeping the business operational.

### What is a go-live simulation and why does the post recommend running one?

A go-live simulation is a full rehearsal run the week before the actual go-live, where the team executes the cutover run book, all users log in to production, and every step is timed exactly as it would happen on go-live day. Any failure found in the simulation leaves one week for fixes; the same failure on actual go-live day means a panic-filled weekend. It is one of the most effective ways to close gaps in preparation before they become real incidents.

### What does 'hypercare' mean and how long does it last after go-live?

Hypercare is a structured 30–90 day period after go-live during which the implementation team provides intensive, dedicated support. A typical hypercare plan covers 30 days with daily check-ins for the first two weeks and weekly reviews for weeks three and four. Hypercare does not end strictly at day 30 — it ends when adoption metrics hit their targets and the business is stable.

### What is the risk of accepting known defects as 'post-go-live fixes'?

Post-go-live, the implementation team is in firefighting mode, users are overwhelmed, and the implementation partner is wrapping up engagement. In practice, known defects accepted as post-go-live fixes rarely get resolved and instead become permanent workarounds. Every item marked 'acceptable risk' must have a named owner, a specific deadline, and a defined impact — and anything truly critical that cannot be fixed before go-live is a reason to delay, not proceed.

### What are the five main categories of readiness the 40-item checklist covers?

The checklist is organized into Technical Readiness (infrastructure, SSL, backups, monitoring, integrations, rollback), Data Readiness (migration dry run, record counts, financial balance validation, cutover run book), User Readiness (credentials, role permissions, training completion, support escalation), Business Readiness (UAT sign-offs, stakeholder communications, payroll and period-close conflicts, executive availability), and Go-Live Day Operations (war room setup, morning check-in, first transaction confirmation, issue logging).

---

- HTML version: https://www.matthewswong.com/en/blog/erp-go-live-checklist/
- Bahasa Indonesia: https://www.matthewswong.com/id/blog/erp-go-live-checklist/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json
