• Months of requirements.
• Weeks of configuration.
• Data migration.
• Custom modules.
• Integrations.
• User acceptance testing.
• Training.

And then someone finally says:

“We're going live tomorrow.”

That sentence changes the mood of an Odoo project surprisingly quickly.

Go-live is where an ERP stops being a project environment and becomes the system people depend on to:

• create quotations
• confirm sales orders
• receive inventory
• manufacture products
• raise purchase orders
• generate invoices
• process payments
• manage customers
• run reports

A button that didn't work correctly in UAT was a bug.

The same button failing tomorrow morning might stop someone from shipping an order.

That's why a good Odoo go live checklist isn't just a list of technical deployment tasks.

It is a controlled transition from:

OLD SYSTEM
     ↓
   CUTOVER
     ↓
ODOO PRODUCTION

And the interesting part is what actually happens inside that middle section.

This is how I think about Odoo go-live day.

Go-Live Actually Starts Before Go-Live Day

If your team begins planning the production cutover on launch morning, you're already late.

The real preparation starts days or weeks earlier.

By the time we reach go-live, several things should already be true:

✓ Core workflows tested
✓ Critical defects resolved
✓ Integrations tested
✓ Users trained
✓ Permissions reviewed
✓ Migration rehearsed
✓ Production infrastructure ready
✓ Cutover responsibilities assigned
✓ Rollback criteria agreed
✓ Support team available

The keyword here is rehearsed.

A production migration should not be the first time you've executed the migration procedure.

Official Odoo guidance similarly recommends testing before production changes and, for upgrades, fully rehearsing the upgrade process before the production database is upgraded.

Go-live should therefore feel less like improvisation and more like running a procedure the team has already practiced.

T-24 Hours: The Go/No-Go Meeting

Before touching production, we make one decision:

GO
or
NO-GO

Not:

"We're probably ready."

The go/no-go meeting should include representatives from:

Project Management
Functional Team
Technical Team
Data Migration Team
Infrastructure
Business Owners
Key Users
Support

The discussion is simple.

Are there unresolved critical defects?

If users cannot:

confirm orders
receive stock
post invoices
process critical workflows

that's probably not a launch-day inconvenience.

It's a launch blocker.

Has UAT actually been signed off?

There's a big difference between:

“Users tested it.”

and:

“Business owners approved these workflows for production.”

For example:

Sales
✓ Lead → Opportunity
✓ Quotation → Sales Order
✓ Delivery
✓ Invoice

Purchase
✓ RFQ → Purchase Order
✓ Receipt
✓ Vendor Bill

Inventory
✓ Receipt
✓ Internal Transfer
✓ Delivery
✓ Returns

Accounting
✓ Customer Invoice
✓ Vendor Bill
✓ Payment
✓ Reconciliation

What matters depends on your implementation.

But critical business processes need explicit ownership.

T-12 Hours: Freeze the Moving Target

One of the hardest parts of ERP migration is that the old system keeps changing.

Imagine we migrated customers on Monday.

Then on Tuesday someone:

creates 12 customers
updates 8 addresses
posts 40 invoices
receives inventory
changes product pricing

Now our migrated database is already stale.

So most cutovers need some form of data freeze.

Conceptually:

Legacy System
     ↓
Normal Operations
     ↓
DATA FREEZE
     ↓
Final Delta Migration
     ↓
Validation
     ↓
Odoo Production

The freeze doesn't necessarily mean shutting down the entire company.

It means defining exactly which transactions can still occur and how they'll be captured.

For example:

After 8:00 PM:

No new sales orders
No inventory adjustments
No new customers
No invoice posting
No product master changes

Or the business may continue operating with a documented process for recording transactions that occur during the cutover window.

The important part is avoiding invisible changes.

Take the Final Backup

Before changing production state, create a recoverable checkpoint.

Depending on your hosting architecture, that may include:

Database
Filestore
Custom modules
Configuration
Integration settings
Deployment version

For Odoo.sh, production backups include the database dump and filestore along with other project data.

The broader principle is straightforward:

Never begin an irreversible production cutover without knowing what state you can return to.

And don't merely ask:

"Do we have a backup?"

Ask:

"Can we restore it?"

A backup you've never tested is partly an assumption.

Run the Final Migration

This is often where the quiet part of go-live begins.

Users may see nothing happening.

Behind the scenes:

Legacy ERP
    ↓
Extract
    ↓
Clean
    ↓
Transform
    ↓
Map
    ↓
Import
    ↓
Validate
    ↓
Odoo

Typical migration objects might include:

Customers
Vendors
Products
Chart of Accounts
Opening Balances
Open Receivables
Open Payables
Inventory
Sales Orders
Purchase Orders
Manufacturing Data
Employees

Not every implementation migrates complete historical transactional data.

Sometimes the smarter boundary is:

Legacy ERP
→ Historical reference

Odoo
→ Opening balances + active transactions + master data

That decision should have been made long before go-live.

Migration Success Is Not “Import Completed”

This message:

Import successful.

doesn't mean the migration succeeded.

It only means Odoo accepted the data.

We still need reconciliation.

For example:

Legacy customers: 12,842
Odoo customers:   12,842

Good start.

But counts alone aren't enough.

We also check values.

Accounts Receivable
Legacy:  ₹X
Odoo:    ₹X

Accounts Payable
Legacy:  ₹Y
Odoo:    ₹Y

Inventory Valuation
Legacy:  ₹Z
Odoo:    ₹Z

Then sample individual records.

Customer A
✓ Address
✓ Tax information
✓ Currency
✓ Payment terms
✓ Outstanding invoices

Product B
✓ SKU
✓ UoM
✓ Cost
✓ Sales price
✓ Tax
✓ Stock quantity

The goal isn't:

DATA EXISTS

It's:

DATA IS TRUSTWORTHY

That difference matters enormously after launch.

Now Check Production-Specific Configuration

Testing environments and production environments should not behave identically.

Odoo's neutralized databases deliberately disable or neutralize several production effects so teams can test safely.

That can include areas such as:

Outgoing email
Scheduled actions
Payment providers
Bank synchronization
Delivery methods
Website visibility

Which creates an important go-live question:

What was intentionally disabled during testing that now needs to work in production?

This is easy to miss.

Your workflow might have passed UAT precisely because staging prevented a real external action.

Production changes that.

Email Is One of the First Things We Test

ERP email failures create strange symptoms.

Users say:

“Odoo isn't working.”

But the actual issue might be:

Quotation created ✓
Email generated ✓
Email delivery ✗

So we test real production communication.

Quotation email
Invoice email
Password/reset email
Notification
Inbound reply/alias if used

Depending on the hosting setup, email configuration differs.

Odoo Online and Odoo.sh provide managed email capabilities, while on-premise deployments may require additional outgoing/incoming mail configuration.

Either way, go-live is not the time to discover that:

sales@company.com

cannot send quotations.

Verify Scheduled Actions

Automations are another category that can behave differently after launch.

Think about:

Subscription invoicing
Email reminders
Automated follow-ups
Scheduled synchronization
Recurring operations
Custom cron jobs

During testing, some may have been disabled deliberately.

Once production starts, they can become active.

So we review:

Which scheduled jobs should run?

When will they first run?

What records will they affect?

Could they process migrated historical records accidentally?

That last question matters.

Imagine a reminder automation suddenly sees 20,000 migrated invoices.

You don't want go-live morning to become:

20,000 unexpected emails sent.

Test Integrations From Production

An integration that worked from staging hasn't necessarily been proven in production.

Production may use different:

API credentials
IP restrictions
webhook URLs
domains
certificates
firewall rules
rate limits
company IDs
database IDs

So we perform controlled smoke tests.

For example:

Odoo
 │
 ├── Payment Gateway ✓
 ├── Shipping API ✓
 ├── eCommerce ✓
 ├── Banking ✓
 ├── Accounting Integration ✓
 ├── External CRM ✓
 └── Custom API ✓

Not every integration should be exercised with a real financial transaction.

But each critical connection needs an appropriate production verification.

Check User Access Before Users Arrive

One of the most common ERP launch problems isn't technically sophisticated at all.

A user logs in and says:

“I can't see Inventory.”

Or worse:

“Why can I see Payroll?”

Odoo access is role-sensitive, so user and group configuration deserves deliberate review before launch.

A useful matrix looks like:

Your matrix will obviously differ.

The point is to test access by business role, not only by administrator account.

Admins can accidentally hide permission problems because admins can see almost everything.

The First Production Smoke Test

Before opening Odoo to the full organization, run a short set of critical workflows.

Not every edge case.

Just enough to answer:

Can the business operate?

For example:

LOGIN
  ↓
Create Customer
  ↓
Create Quotation
  ↓
Confirm Order
  ↓
Reserve Stock
  ↓
Deliver
  ↓
Create Invoice
  ↓
Post Invoice

Then:

Create RFQ
  ↓
Confirm Purchase Order
  ↓
Receive Product
  ↓
Create Vendor Bill

And if manufacturing is involved:

Manufacturing Order
  ↓
Reserve Components
  ↓
Produce
  ↓
Complete

The exact smoke test depends on your business.

But it should follow real transactions, not technical endpoints.

Then Comes the Actual Cutover

At some point, the project manager says:

“Production is open.”

That's the moment everyone thinks go-live happened.

Technically, yes.

Operationally, we're only halfway there.

Users begin logging in.

08:00 → Sales
08:15 → Warehouse
08:30 → Purchasing
09:00 → Accounting

And almost immediately, tickets start appearing.

This is normal.

Go-Live Issues Are Not All Bugs

One of the biggest mistakes during hypercare is treating every report as a software defect.

A user might say:

“The system won't let me confirm this order.”

Possible causes:

Actual bug
Configuration issue
Missing permission
Incorrect master data
Missing required field
User training gap
Intentional business rule
Integration failure

Those require very different responses.

So every issue should be triaged.

User Reports Problem
        ↓
   Reproduce
        ↓
   Classify
        ↓
┌────────┬────────┬────────┬────────┐
Bug    Data     Access   Training  Config

That classification prevents developers from “fixing” correct behavior.

Use Severity Levels

Not every go-live ticket should interrupt the technical team.

A practical severity model might be:

P1 — Business Stopped

Cannot process orders
Cannot invoice
Production unavailable
Critical integration down
Major data corruption

Immediate response.

P2 — Major Workflow Impaired

Important workflow broken
Workaround exists but is difficult
Multiple users affected

High priority.

P3 — Limited Issue

One user affected
Minor report issue
Small configuration problem

Normal support queue.

P4 — Improvement

"Can we move this field?"
"Can this report show another column?"

Not a go-live emergency.

That last category is important.

Go-live creates a lot of:

“Now that we're using it, wouldn't it be nice if…”

Capture those ideas.

Don't necessarily deploy them on day one.

Avoid Emergency Customization

The first few hours of production generate pressure.

A user says:

“We need this changed immediately.”

Sometimes they do.

But uncontrolled production changes during hypercare create a dangerous cycle:

Issue
 ↓
Quick Fix
 ↓
No Regression Test
 ↓
New Issue
 ↓
Another Quick Fix

Instead:

Issue
 ↓
Assess Severity
 ↓
Reproduce
 ↓
Fix
 ↓
Test
 ↓
Approve
 ↓
Deploy
 ↓
Verify

Production urgency doesn't remove the need for engineering discipline.

It increases it.

This is where having a defined implementation process helps. A structured Odoo implementation timeline should treat deployment, data freeze, final configuration, go-live validation, and post-launch support as explicit project phases rather than treating launch as a single button press.

The Odoo Go Live Checklist I Actually Care About

Here's the condensed version.

Business Readiness

□ UAT formally approved
□ Critical workflows tested
□ Key users available
□ End users trained
□ Process owners identified
□ Support process communicated

Data

□ Data freeze communicated
□ Final extraction completed
□ Master data migrated
□ Open transactions migrated
□ Opening balances validated
□ Inventory reconciled
□ Record counts checked
□ Financial totals reconciled
□ Sample records manually verified

Production

□ Production database ready
□ Final backup/checkpoint available
□ Correct release deployed
□ Custom modules verified
□ Production domain working
□ SSL/network configuration verified
□ Performance smoke-tested

Users & Security

□ Production users created
□ Roles assigned
□ Access rights tested
□ Admin access restricted appropriately
□ Former/test accounts reviewed
□ Sensitive modules checked

External Services

□ Outgoing email tested
□ Incoming email/aliases tested if used
□ Payment integration tested
□ Shipping integration tested
□ Banking integration checked
□ Webhooks verified
□ External APIs verified
□ Production credentials confirmed

Automation

□ Scheduled actions reviewed
□ Cron jobs reviewed
□ Automated emails reviewed
□ Recurring transactions checked
□ First-run behavior understood

Cutover

□ Cutover owner identified
□ Start time agreed
□ Legacy-system freeze active
□ Final migration completed
□ Reconciliation completed
□ Smoke tests passed
□ Business owner gives GO

Recovery

□ Backup available
□ Restore procedure understood
□ Rollback decision owner identified
□ Rollback criteria defined
□ Integration rollback considered

Hypercare

□ Support channel active
□ Functional consultants available
□ Developers available
□ Issues severity-ranked
□ Production changes controlled
□ Logs monitored
□ Integration failures monitored
□ User questions tracked separately from bugs

That's much closer to a real Odoo go live checklist than:

□ Deploy Odoo
□ Tell users
□ Done

Define Rollback Before You Need It

Nobody likes discussing rollback before launch.

It sounds pessimistic.

It isn't.

It's risk management.

Before production starts, define what would cause us to stop.

For example:

Critical financial mismatch
Critical data corruption
Core order processing unavailable
Irrecoverable integration failure
Production instability

Then define:

WHO can call rollback?
WHEN is rollback still possible?
WHAT data needs preserving?
HOW do users return to the previous process?

The worst time to design a rollback plan is during a P1 incident.

But Rollback Gets Harder After Transactions Start

This is something people underestimate.

At 08:00:

Odoo goes live.

By 11:00:

83 orders created
17 invoices posted
41 stock movements
9 purchase orders
3 manufacturing orders

Now “restore last night's database” isn't a simple rollback.

You would lose legitimate production activity.

So the rollback window shrinks as real-world transactions accumulate.

This is why early smoke testing matters so much.

Find catastrophic problems before transaction volume builds.

Go-Live Isn't Finished at 5 PM

If day one went well, that's excellent.

But ERP stabilization continues.

The next phase is usually hypercare.

Think:

GO-LIVE
   ↓
Hypercare
   ↓
Stabilization
   ↓
Optimization
   ↓
Normal Support

During hypercare we monitor:

Critical tickets
Integration errors
User adoption
Performance
Data inconsistencies
Scheduled jobs
Email delivery
Permission issues
Workflow bottlenecks

We also look for repeated user questions.

If ten people ask:

“How do I create a return?”

that's probably not ten user problems.

It's a training or UX problem.

Separate Stabilization From Optimization

Immediately after launch, users will discover dozens of improvements.

That's useful feedback.

But don't mix:

SYSTEM MUST WORK

with:

SYSTEM COULD BE BETTER

We normally think about them as two queues.

HYPERCARE
│
├── Bugs
├── Data problems
├── Access problems
├── Integration failures
└── Critical configuration

BACKLOG
│
├── UI improvements
├── New reports
├── Workflow enhancements
├── New automation
└── Additional modules

Stabilize first.

Optimize second.

For implementations with custom modules, that discipline extends beyond launch: staging review, permissions testing, deployment notes, handover, and post-launch refinements should remain part of the engineering lifecycle. This is particularly relevant when an implementation includes significant custom Odoo development alongside standard ERP configuration.

What a Good Go-Live Day Actually Feels Like

People sometimes expect successful ERP launches to be dramatic.

They shouldn't be.

A good go-live can actually feel boring.

Migration completed.
Totals match.
Smoke tests pass.
Users log in.
Orders process.
Inventory moves.
Invoices post.
Integrations respond.
Minor tickets arrive.
Support resolves them.

No heroic all-night debugging.

No surprise migration script.

No developer manually changing production records while fifteen people watch a screen share.

That's not luck.

That's preparation.

The Real Goal Isn't Zero Issues

Every implementation has issues.

Trying to promise:

ZERO ISSUES ON GO-LIVE

sets the wrong expectation.

The better objective is:

No unknown critical risks
+
No unreconciled critical data
+
No untested critical workflows
+
Fast detection
+
Clear ownership
+
Controlled recovery

You cannot guarantee that nothing will go wrong.

You can make sure the team knows what to do when something does.

Final Takeaway

An Odoo go-live isn't:

Deploy → Done

It's closer to:

Rehearse
   ↓
Approve
   ↓
Freeze
   ↓
Backup
   ↓
Migrate
   ↓
Reconcile
   ↓
Configure Production
   ↓
Verify Integrations
   ↓
Smoke Test
   ↓
Open to Users
   ↓
Triage
   ↓
Hypercare
   ↓
Stabilize

The biggest lesson is simple:

Go-live day should contain as few surprises as possible.

• Your migration has already been rehearsed.
• Your users have already tested their workflows.
• Your permissions have already been reviewed.
• Your integrations have already been exercised.
• Your rollback conditions have already been agreed.
• Your support team already knows who owns each type of problem.

When that preparation is done properly, clicking over to production isn't the risky part.

The risky decisions were made or avoided weeks earlier.

That's what a useful Odoo go live checklist is really for.

Not to make launch day perfect.

To make launch day predictable.