What to scope before managed Odoo hosting

The server is the easy part of an Odoo project. What decides whether Odoo works for a business is the scoping done before anything is installed: who will use it, which apps, which data comes across, what it must connect to and what has to be built. This checklist covers the nine things to settle before you host Odoo Community, and the question to answer for each. It is the first piece in our Odoo series, which starts from why we choose Odoo ERP.

1. Users and roles

Start with people, not modules. Count the named users, and then the number likely to be working in Odoo at the same time, because that is what sizes the server. Odoo's own deployment guide gives a rule of thumb of one worker process for about six concurrent users, with each worker needing memory and processor time of its own.

Then list the departments and what each needs to see. Odoo sets access rights by user and by group, and only an administrator can change them, so decide early who that administrator is in your business.

The question: how many people, how many at once, and who decides what each may see?

2. Which apps, and which edition

Odoo Community, the free and open-source edition under the GNU Lesser General Public License version 3, includes invoicing and accounting, stock, purchasing, sales, CRM, website, online shop and point of sale, with fuller financial reporting available as community modules. Odoo Enterprise is built on Community and adds more apps and services.

Go through each need and check whether Community covers it. Automatic bank synchronisation, for example, is an Enterprise service; on Community, bank statements are imported and reconciled through modules from the Odoo Community Association (OCA). Most needs fall clearly on one side, and the few that do not are worth deciding now rather than after go-live.

The question: which standard apps will you use from day one, and does any need require Enterprise?

3. Data migration

Decide what comes across from the old system and what stays behind as an archive. The usual candidates are contacts, products and prices, opening balances, open invoices and open orders. Odoo imports data from spreadsheet files into almost any record, and provides templates for the common ones.

Two points from Odoo's documentation shape the plan. Imports cannot be undone, so every import is tested on a copy first. And keeping the old system's reference numbers as external IDs lets related records link up and lets a file be imported again without creating duplicates.

The question: which records come across, from which system, and who checks them?

4. Integrations

List everything Odoo must talk to: payment gateways, the bank, couriers, an existing online shop, and payroll. Odoo has an external API, and community modules already connect South African payment gateways such as Yoco and Ozow.

Some things belong outside Odoo. South African payroll is best left with a specialist that carries the SARS compliance updates, connected so that totals post to the Odoo ledger. Decide for each connector who owns it, because a connector is code that has to be kept working through every upgrade.

The question: what must Odoo send and receive, and who looks after each connection?

5. Custom modules

Write down what is genuinely unique to the business. Then check whether the OCA, a non-profit that publishes thousands of open-source Odoo modules, has already solved it. Only what is left needs building.

Custom work on Odoo is written as Python modules that belong to you and run on Community and Enterprise alike. The cost to plan for is not only the build. Odoo's upgrade documentation is clear that a database with custom modules cannot move to a new major version until those modules have been ported to it.

The question: what does the business do that no standard or OCA module does?

6. Reporting and localisation

For a South African company, Odoo's South African accounting module provides a generic chart of accounts and a VAT-ready structure of tax tags and a tax report. Set the localisation before any entry is posted, because it cannot be changed afterwards.

If the group has more than one legal entity, decide whether each is a company in the same database or a branch. Odoo's documentation says entities in different countries should be separate companies, because branches follow their parent's localisation. Then list the management reports people actually use today, so the first month-end in Odoo produces them.

The question: how many entities, which reports, and who signs off the chart of accounts?

7. Version and where it runs

Odoo releases a new major version once a year and gives each one three years of standard support, with security fixes only during that time. A new project should start on a version with most of that window left, and plan its next move before the window closes. Odoo 19 needs Python 3.10 and PostgreSQL 13 or later; Odoo 20 raises those to Python 3.12 and PostgreSQL 16.

Self-hosting gives you a choice that Odoo's own hosted service does not: Odoo Online does not allow custom modules or modules from the Odoo Apps Store. Decide who administers the server.

The question: which version, on which server, and when is the next upgrade?

8. Backups and recovery

An ERP holds the working record of the business, so the backup plan is part of scoping, not an afterthought. Settle how often the database and its file store are backed up, where the copies are kept, how long they are kept, and how a restore is tested. Odoo's deployment guide recommends that database operations, backups included, are run by the system administrator rather than through Odoo's own database manager on an internet-facing system.

The question: what is backed up, how often, and when was a restore last tested?

9. Support and who does what

Finally, write down the line between the people who run Odoo and the people who use it. Updates, server care and recovery are one kind of work. Business set-up, data entry and deciding how a process should run are another.

The question: who do staff call when something breaks, and who decides how Odoo is set up?

The scoping checklist

How Noiz splits the work

At Noiz, running Odoo and building it are priced separately, so the monthly line stays predictable.

Managed Odoo is Odoo Community run on infrastructure Noiz controls: a Noiz Cloud server, a Noiz dedicated server, or hardware at your premises that Noiz administers. It covers the server underneath, updates and fixes within your installed version, a backup of the database and file store before every change, checks of logins, key flows and scheduled actions after every change, and recovery from the most recent usable backup. Your business configuration, users, data and custom modules stay with you.

Implementation, custom modules, integrations and moves to a new major version are quoted as projects, from the scoping above. If you would rather administer Odoo yourselves, you can run it on a Noiz Cloud server on your own terms.

To start, open a ticket with the answers to the nine questions you have so far, and we will tell you what is standard, what would need building and which server would fit.

Sources

Checked 19 October 2026.

Odoo

• Odoo 19 documentation: database management and editions
• Odoo Online
• Standard and extended support
• Upgrade
• Installing from source, Odoo 19 and Odoo 20
• System configuration and deployment
• Multi-company
• Fiscal localisations
• South Africa accounting module (l10n_za) manifest
• Export and import data
• Access rights
• Odoo Enterprise Subscription Agreement

Odoo Community Association

• About the OCA
• OCA on GitHub

Noiz

• Managed Odoo
• Why we choose Odoo ERP

Note: while some of this content was produced with the help of AI, the final editing has been done by a real human being.