Sooner or later every Odoo team copies its production database. You need somewhere to rehearse a version upgrade, reproduce a bug a user reported, train new staff, or let a developer try a change before it ships. A copy is the right tool for all of that. The catch is that a copy of production is also a copy of everything production is configured to do, and Odoo is configured to talk to the outside world.
Left alone, a fresh copy can email your customers, pull messages out of your shared inbox, charge saved cards and send invoices to the tax authority. None of it raises an error, because from Odoo's point of view nothing is wrong. It is doing its normal job on the wrong database.
What a copy can do to the real world
Before deciding what to switch off, list what actually leaves the system. On a typical implementation in the region, that list looks like this:
- Outgoing email. Payment reminders, quotation follow-ups, subscription renewals and marketing campaigns go out through the configured mail server, to real customers.
- Incoming email. If the copy keeps the same incoming mail server, it fetches from the same mailbox. Odoo marks fetched messages as read or deletes them from the server, depending on the setup, so production may never see the replies the copy picked up first.
- Scheduled actions. Every cron job that runs in production starts running in the copy too: recurring invoices, reminders, data syncs, automated actions with time-based triggers.
- Payment providers. Live API keys travel with the database. A test checkout on the copy is a real charge, and a scheduled job that charges saved payment methods, such as a subscription renewal, can bill the same customer twice, once from each database.
- E-invoicing. If Odoo's official localization modules are connected to ZATCA in Saudi Arabia or the ETA in Egypt, an invoice posted on the copy can reach the authority as a real tax document. This is the hardest mistake on the list to undo, because fixing it goes through the authority's own process, not a deleted record.
- Other integrations. Shipping carriers that create real labels, bank synchronization, calendar sync with Google or Outlook, and automation rules that call external URLs (webhooks).
Odoo's built-in neutralization
Since version 16, Odoo includes a step designed for exactly this, called neutralization. You can run it from the command line with odoo-bin neutralize, and the database manager offers it as an option when you duplicate or restore a database.
Neutralization deactivates scheduled actions, disables the outgoing and incoming mail servers, switches live payment providers off, and shows a banner so everyone can see they are working on a neutralized copy. Each installed module can add its own rules on top, which is how some other connectors get covered as well.
Two caveats matter. First, coverage depends on the modules and the version you run, so treat neutralization as a strong default rather than a guarantee, and check the connectors you care about yourself. Second, timing. Scheduled actions can start running as soon as an Odoo server picks up the new database, before anyone has logged in. Neutralization has to happen before the copy is started, not after the first person logs in to tidy up.
A five-minute check on any copy
Whether the copy came from a script, the database manager or a hosting platform's staging feature, these checks take a few minutes and catch most surprises. Most of the screens sit under Settings with developer mode switched on.
- Outgoing mail servers: none active, or a single one that delivers to a test mailbox nobody outside the team reads.
- Incoming mail servers: none active.
- Scheduled actions: filter for the active ones and confirm nothing customer-facing is among them.
- Payment providers: disabled, or in test mode with the provider's test keys.
- E-invoicing: disconnected, or pointed at the authority's test environment where the localization module supports one.
- Shipping, bank sync and calendar sync: disconnected.
- The web.base.url system parameter: set to the copy's own address, so links in anything it generates lead back to the copy. If production uses web.base.url.freeze, the copy inherits it, so change the value by hand.
- Access: only the people who need the copy can log in. It holds the same customer and employee data as production and deserves the same care.
Switch things back on deliberately
Neutralization has a cost. A fully neutralized copy cannot test the flows that leave the system. You cannot check a new invoice email template, a payment page or a ZATCA submission while all three are switched off.
So re-enable only what a given test needs, one item at a time and in its safe form. Point outgoing mail at a test mailbox. Put the payment provider in test mode with its test keys. Connect e-invoicing to the authority's test environment instead of production. Then write down what you turned on, so the next person who uses the copy knows what it can still reach.
Where the copy lives matters too
A copy sitting on someone's laptop or a forgotten server keeps production data long after the test is over. Copies are safest when they are created where production lives, easy to refresh from current data, and easy to delete when the work is done.
That is why managed hosting includes staging and sandbox environments instead of leaving each team to build its own. Plemo managed hosting provides staging and sandbox environments alongside automated backups, point-in-time recovery and monitoring, and customizations built through Plemo are previewed in a sandbox before anything reaches production. Whichever platform you use, the checklist above is short enough to run on every copy you make.