Go-Live Checklist: The 72-Hour Rule (2026)

What is the 72-Hour Rule?

The go-live moment requires coordinated effort from all teams

Go-live cannot be compressed into a single moment. Successful transitions are ensured through a systematic preparation and follow-up cycle. The 72-Hour Rule divides the transition into three timeframes:

• 72 hours before (-72 to 0): Final checks, data validation, and team preparation
• Go-live moment (0 to +24 hours): Technical cutover, initial transactions, and real-time support
• 72 hours after (+24 to +72): Stabilization, performance monitoring, and user feedback

This approach accounts for situations frequently encountered in regional markets: weekend cutovers, internet connectivity issues, coordination challenges in multi-branch structures, and pressure during audit periods.

Companies applying this rule in ERP consulting projects significantly reduce the critical error rate after go-live (representative measurement: 60-70% reduction).

Pre-Go-Live Preparation

Detailed checks in the final 72 hours are of critical importance

Tasks for the Final 72 Hours

Go-live preparation is one of the most intensive periods of the project. Focus on the following areas during the final 72 hours:

Data Preparation

• Has master data (customer, product, supplier) been validated one last time?
• Have open orders, pending invoices, and work-in-progress inventories been migrated?
• Is the distinction between test data and live data clear?

Technical Infrastructure

• Have server capacity and performance tests been completed?
• Is the backup system operational, and has a restoration test been performed?
• Have integrations (banking, e-invoicing, logistics) been checked one last time?

People and Organization

• Have access permissions been defined for all users?
• Has the support team shift schedule been created?
• Has contact information for critical users (super users) been updated?

For more information, you can review our consulting approach on the about us page.

The Go-Live Moment: The Critical 24 Hours

The first 24 hours require all teams to be accessible 24/7

Zero Hour

The system transition checklist requires speed and accuracy at the moment of cutover. During the first 24 hours:

Technical Cutover Steps

• Set the legacy system to read-only mode
• Start the final data migration
• Run data integrity checks
• Activate the new system
• Perform initial transactions (test order, test invoice)

Communication and Coordination

• Send the go-live notification to all branches/departments
• Activate the support line (phone, email, instant messaging)
• Execute the mechanism for immediate reporting of critical errors

Initial Validation

• Can users log into the system?
• Are core processes (orders, invoices, stock movements) working?
• Are reports pulling accurate data?

Post-Go-Live Stabilization

Performance metrics must be continuously monitored after the transition

Between 24 and 72 Hours

The post-transition follow-up is the most critical part of the go-live checklist, though often the most overlooked. During this period:

Performance Monitoring

• Are system response times within acceptable ranges?
• What is the error rate in integrations?
• How does the system behave during peak hours (e.g., 09:00-10:00)?

User Support

• Which questions are frequently repeated?
• Which processes are challenging for users?
• Are there training gaps?

Data Validation

• Do stock balances match?
• Are accounting records consistent?
• Has the status of open orders and invoices been checked?

Field Example: Manufacturing Firm Go-Live

Real Case (Unbranded)

Situation

A textile manufacturing firm with 85 employees. 2 production facilities, 1 head office, 12 dealerships. Legacy system: desktop accounting + Excel production tracking. New system: cloud-based ERP.

Implementation of the 72-Hour Rule

1. -72 hours: Final data check; 847 customer records and 2,340 product cards validated
2. -48 hours: All user passwords reset; authorization matrix approved one last time
3. -24 hours: Integrations tested; backup completed
4. 0 hour (Saturday 06:00): Legacy system locked; data transfer started
5. +4 hours: New system active; first test orders entered
6. +24 hours: All branches active; 23 support requests resolved
7. +72 hours: Stabilization completed; transitioned to normal operations

Results (Representative)

• Total downtime: 4 hours (target: 8 hours)
• Number of critical errors: 0
• Medium priority errors: 7 (all resolved within 72 hours)
• User satisfaction: 87% (first-week survey)

7 Most Common Mistakes in Go-Live

1. Making Last-Minute Changes

The urge to make a “small fix” in the final 48 hours. These fixes are usually untested and lead to chain-reaction errors.

2. Not Preparing a Rollback Plan

Failing to plan for a rollback based on the assumption that “everything will go well.” If it is unknown what to do in case of a critical error, panic decisions are made.

3. Insufficient Support Staff

Inadequate support personnel during the first 72 hours. If users cannot find quick solutions when they encounter problems, their trust in the system is shaken.

4. Skipping Data Validation

Going live without checking the accuracy of migrated data. Incorrect stock, customer, or price data locks down operations.

5. Not Testing Integrations

Failing to test banking, e-invoice, or shipping integrations in the production environment. An integration that works in a demo environment may behave differently in live production.

6. Delaying User Communication

Not communicating the go-live date and expectations until the last minute. Users are caught off guard, and resistance increases.

7. Shortening the Stabilization Period

Disbanding the support team with the mindset that “we went live, the project is over.” Intensive support is required for the first 2-4 weeks.

Being prepared prevents errors

Go-Live Success Metrics

The following metrics can be used to evaluate the success of the go-live process (representative values):

Go-Live Checklist (25+ Items)

This list can be expanded specifically for your project by reaching out via the contact page.

Go/No-Go Decision Mechanism

Proceed or Postpone?

The most critical decision point in go-live preparation is the Go/No-Go meeting. The following criteria are evaluated in this meeting:

Go (Proceed) Criteria:

• All blocker errors closed
• Data migration validation reports show 99%+ match
• Training completion rate above target (representative: 95%+)
• Support team ready and accessible
• Backup/restoration tests successful

No-Go (Postpone) Triggers:

• Unresolved error in critical integration
• Master data validation rate below acceptance threshold
• Key users have not received training
• Rollback plan not tested
• Senior management support uncertain

The decision should be made not by the project manager, but through the joint approval of the project sponsor and business units.

Rollback Plan

Preparing for the Worst-Case Scenario

Every go-live checklist must include a rollback plan. The rollback plan covers:

Triggering Criteria

• Within how many hours must a critical error be resolved before rolling back? (Representative: 4-8 hours)
• Which error types trigger an automatic rollback?
• Who makes the rollback decision?

Technical Steps

• New system is shut down
• Legacy system is restored from backup
• Data entered during the transition is manually migrated to the legacy system
• Notification sent to users

Communication Plan

• What will be said to customers, suppliers, and stakeholders?
• How will the postponement period and new schedule be announced?

A rollback is not a failure; it is professional risk management.

Frequently Asked Questions (FAQ)