Odoo for manufacturers: why the build starts with the shop floor
A discrete manufacturer often keeps production planning in one tool, quality records in spreadsheets or a separate system, and stock counts in the accounting package. Odoo's manufacturing apps can cover discrete and make-to-order production, but the build starts on the shop floor, with routings, work centers and traceability mapped before any configuration begins. Consider an illustrative fabrication shop that cuts, welds and paints parts to order. Its planners know how long the welding cell actually takes, while the system holds only a standard estimate, so the first task is agreeing on which numbers the system should trust.
For planners, the routing is the core decision. A routing lists the operations a product passes through, the work center that performs each one and the expected time. Work centers carry capacity, availability and cost, so they determine whether a schedule is feasible. Ask planners which times are measured and which are estimated, which cells can run each product, and whether operators will confirm steps in Shop Floor or on paper. Make-to-order work adds another question: whether each sales order needs its own bill of materials variant, or whether options can be handled through attributes on a shared product.
Quality staff need the checks and the traceability design settled early. Quality checks can be attached to specific operations, and in Odoo these are documented as part of the Enterprise edition, so confirm the edition before you plan around them. Decide which checks require a recorded measurement, which trigger a hold on the work order, and who can release it. For traceability, define when lot or serial numbers are captured, from receipt through consumption in work orders to delivery. If records must meet electronic record requirements such as 21 CFR Part 11, confirm whether that scope applies to your products before the design is fixed.
Finance feels the change when operations are recorded. Material consumption, labor, overhead and scrap all flow into work-in-progress and product cost, so the routing map sets how the cost roll-up behaves. The Metal Fabricator and Custom Industrial Equipment packages give you preconfigured starting points, not finished solutions. Review their defaults against your routings, work centers and traceability design, and plan the changes they will need. Custom modules and Odoo Studio are available only on the Custom plan, which can also be hosted on Odoo.sh or on-premise, so confirm the plan and hosting type with Odoo before you commit to a design.
Which industry requirements shape a manufacturing build
This table lists the industry requirements that most often change how an Odoo for manufacturers build is designed, with the source of each and the design decision it affects. Read each row as a question to answer before configuration starts, such as which network zone a system belongs to, what an audit trail must show, or whether a signature can be attributed to one person. The main takeaway is that OT and machine connectivity rules apply to the boundary around Odoo, so they shape where the ERP connects as well as what it stores.
| Requirement | Source | What it means for the Odoo build |
|---|---|---|
| NIS2 critical sector | Directive (EU) 2022/2555, Annex II | Divisions 26 to 30 and medical or IVD device makers may be in scope. Confirm your entity status before design. |
| NIS2 incident reporting | Directive (EU) 2022/2555, Article 23(4) | Early warning within 24 hours, notification within 72 hours, final report within one month. Export Odoo and PostgreSQL logs to a central store. |
| IEC 62443 zones and conduits | ISA/IEC 62443 series; ANSI/ISA-62443-3-2-2020 | Place Odoo in the business zone and route shop-floor data through a defined conduit with documented rules and logging. |
| OT security for PLCs and SCADA | NIST SP 800-82 Rev. 3 (September 2023) | Keep Odoo off the control network. Route machine data through a segmented gateway so control does not depend on Odoo availability. |
| Machinery connection requirement | Regulation (EU) 2023/1230, Annex III, 1.1.9, applies from 14 January 2027 | Connected devices and remote access must not create hazards. Review any Odoo write-back to machine settings within the safety assessment. |
| Regulated quality records | 21 CFR Part 11, electronic records and signatures | Quality checks and sign-offs need attributable users, audit trails and controlled signatures. Confirm which Odoo settings meet each control. |
Which Odoo edition manufacturers need for MRP, PLM and maintenance
Before a manufacturer writes its Odoo scope, it needs to know which edition carries the features it plans to use. Odoo publishes a Community edition under the LGPL-3.0 license, and a paid Enterprise edition with additional features and support. The Enterprise source code is not publicly available, so using Enterprise features means holding a subscription or working through partner access. For a make-to-order or discrete manufacturer, that difference can decide the architecture of the whole project.
PLM (product lifecycle management) and maintenance are Enterprise features. A manufacturer that needs engineering change orders, product versioning tied to manufacturing orders, or preventive maintenance requests against work centers and equipment should plan for an Enterprise subscription from the start. Manufacturing with work centers, bills of materials and quality checks is the part of the picture to confirm separately, because feature placement between editions can change between releases. Ask Odoo to confirm, for the specific version you intend to run, which MRP, Shop Floor, quality, subcontracting and traceability functions are included in Community and which require Enterprise.
Odoo's pricing page adds a second constraint. It lists three plans: One App Free, Standard and Custom. Only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. A manufacturer with several plants, a need for an integration to its MES, PLM or machine data, or custom reports tied to production will almost always fall into the Custom plan. A single-site shop that only needs Odoo Online may find the Standard plan covers its apps, but it gives up the hosting choice that matters for controlled environments.
Treat the pricing page as a snapshot. Plan names, included features and per-user prices can change, and a yearly discount applies to the published monthly rates. Before the scope is written, get the current edition comparison in writing from Odoo or an Odoo partner, and ask which module names map to Community, Enterprise and Custom. Record the answer alongside the version you intend to deploy, since the support window for that version (covered elsewhere on this page) depends on it.
Ask for a licensing position that lists each manufacturing app, each user role that will touch production or maintenance data, the number of companies and the hosting type. Also ask how the subscription is renewed and what happens to the database if it lapses. An on-premise Enterprise database is activated with a subscription code, so the subscription is part of the installation, not just a commercial item. Getting this written before the build starts prevents a late discovery that a required feature sits in a higher tier.
Which Odoo manufacturing modules and settings matter most
The manufacturing modules in Odoo share master data, so a choice made in one module often sets limits in another. The cards below name each module or setting, the design decision it forces, and the check to run before go-live.
MRP with work centers and bills of materials
Bills of materials define the components and operations behind each product, and work centers define where those operations run and at what capacity. Decide how granular routings should be: one operation per machine, per cell, or per process step. Finer routings improve scheduling and costing, but every product variant needs its own maintained structure. Check that component and routing data is clean before the first production order is released, because errors there carry into planning and costing.
Shop Floor operator workflow
Shop Floor is the operator-facing part of manufacturing in Odoo, where workers start, pause and complete work orders at work centers. Decide which work centers get a terminal or tablet, who can log time, and how scrap and rework are reported back. Confirm with Odoo which Shop Floor features your edition and version include before you fix the floor workflow. Test the workflow on the actual shop floor network and devices, since hardware and connectivity often determine whether the workflow runs at all.
Quality checks at defined inspection points
Quality control points in Odoo can be tied to operations and stock moves, so the core design question is where inspection happens. Decide the inspection points: incoming goods, in-process operations, and final test or shipment. For each point, define the pass criteria, who records the result, and what happens to a failed lot, such as holding stock or routing it to rework. Keep the set of checks small enough that operators complete them consistently, and test the failure path before go-live.
Lot and serial traceability
Lot and serial numbers link finished goods back to the materials, operations and inspections that produced them. Decide the numbering scheme first, since it must match how your customers, auditors or regulators will request records. Decide which products are tracked by lot, which by serial number, and at which operations numbers are assigned. Changing numbering after stock has moved is difficult to unwind, so run a full forward and backward trace on sample orders before production starts.
Edition and package scope
Some manufacturing capabilities depend on the edition and plan. Odoo documents PLM as part of its Enterprise edition, and only its Custom plan can be hosted on Odoo.sh or on-premise, the plan that includes custom modules. The Metal Fabricator and Custom Industrial Equipment packages are starting points that still need mapping to your bill of materials, routings and quality steps. Ask Odoo which apps and package contents your plan and version include, and confirm them in writing before the scope is fixed.
Identity integration with LDAP or Azure OAuth
Odoo documents user sign-in through LDAP, with optional user creation on first login from a template, and through Microsoft Azure OAuth. It also documents two-factor authentication. Decide which directory is the source of truth for accounts, how directory groups map to Odoo access rights, and whether accounts are created automatically or by an administrator. Test disabled-user handling and two-factor enrollment for shop floor users, who may not have a personal phone or a mailbox suited to that enrollment.
Where Odoo ends and the shop floor begins
The first design decision for an Odoo manufacturing rollout is where Odoo's responsibility ends and the plant's control network begins. Manufacturing orders, work center status, scrap counts and lot records all describe physical processes. Once they are exchanged with machines, the business system is connected to equipment that can stop a line or move material. ISA/IEC 62443 treats industrial automation and control systems as a family with their own security requirements, and NIST SP 800-82 Rev. 3, published in September 2023, covers PLCs, SCADA systems and DCS as systems that need protections designed around performance, reliability and safety. Neither standard expects an ERP platform to sit inside those control zones, so the boundary has to be drawn deliberately.
In the zone model used by ISA-62443-3-2-2020, a security risk assessment for system design, the plant is split into zones with similar security needs, and the communication paths between zones are called conduits. For an Odoo project, Odoo and its database normally belong to an enterprise zone, while controllers and SCADA servers belong to control zones. Any data path between them is a conduit that needs a written purpose, direction, protocol, owner and monitoring. Illustrative example: a machine publishes cycle counts to a gateway in a demilitarized zone, and only that gateway calls Odoo's external API. The conduit is documented before anyone writes code for it.
Three questions shape the design. The first is which machine data Odoo receives. Counts, good and scrap quantities, machine state and consumption usually serve planning and costing, while setpoints, recipes and direct control commands belong to the automation layer and should stay there. The second is the path: which broker, historian or gateway carries the data, who operates it, and how it authenticates. The third is ownership of the boundary: who approves a new tag, who patches the gateway, who responds when the feed stops, and whether plant engineering, IT or the equipment vendor holds each part. Decide early whether any path carries writes from Odoo back to equipment. A design that keeps data flowing inbound only, with no write path, is easier to defend to both IT security and plant safety reviewers.
Write this design before any integration is built, and record it as a short document that names each conduit, data item, owner and sign-off. According to Odoo's pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes external API access, so confirm the edition and hosting model your gateway will depend on before scoping. Connectors for specific PLC brands, protocols and SCADA products vary by equipment model and firmware, and Odoo's own apps may not cover your equipment at all. Confirm each connector against your actual machines and the vendor documentation for them. Then test with a read-only feed in a non-production database before any live data flows.
How a manufacturing rollout is sequenced
The sequence moves from mapping how your plant actually makes product to a pilot on one line or product family and then go-live, so that routings, BOMs, quality plans and machine and identity data are settled before they are loaded into Odoo. Phase count and depth depend on scope, and the final order is confirmed in the written scope before work starts.
Map routings, BOMs and quality plans
Walk the shop floor and engineering records with production, quality and planning staff to document how each product is built: bills of materials with their variants, routings with work centers and operation times, subcontracted steps, and the inspection points and quality plans that apply at each operation. Decide where Manufacturing, Shop Floor, Quality, Maintenance, PLM or Subcontracting fit, and which Odoo features need the Enterprise edition. Output: a signed-off process map that lists each product family, its routing and its checks, and the gaps where the current practice differs from the documented one.
Decide edition, hosting and the Custom plan
Choose the Odoo edition and hosting model before any configuration begins, because they determine which features and which upgrade obligations apply. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise and that only Custom includes multi-company, Odoo Studio, external API access and custom modules, so most plants with custom modules or machine integrations will evaluate that plan. Confirm the hosting location against your network and data rules, and record the support window of the chosen version. Output: a written decision record covering edition, plan, hosting and the upgrade path.
Cleanse master data and rehearse migration
Clean the item, supplier, customer, BOM, routing, work center and opening stock records, removing duplicates and retiring obsolete products before they are imported. Agree who owns each data set and how changes are approved after cutover. Load the cleansed data into a test database, run the migration at least once end to end, and reconcile counts and valuations against the source system. Odoo's on-premise documentation describes database duplication with neutralization for test copies, which is useful for repeated rehearsals. Output: a reconciliation report showing that the rehearsal matches the source for every agreed record type.
Configure modules and integrate identity and machine data
Configure work centers, routings, quality points, maintenance schedules, units of measure, lots and serial numbers, and reporting in line with the process map. Connect sign-in to your identity provider, such as LDAP, which Odoo documents with optional user creation on first login from a template, or the OAuth and two-factor options Odoo documents. Build the integrations to machine, MES or PLC data sources and to other systems on the agreed interfaces, with error handling, retries and an audit trail. Output: a configured test environment and an integration test log that shows each interface passing its agreed cases.
Pilot one line or product family in parallel
Run the configured system for one production line or one product family while the existing process continues, so that orders, shop floor confirmations, quality results and stock moves are recorded in both places. Compare outputs each shift or each batch, log every variance, and fix root causes in configuration, data or training before widening the scope. Agree the exit criteria in writing before the pilot starts, including which variances are acceptable. Output: a pilot report that states which exit criteria were met, what remains open, and the decision to proceed.
Go live and provide hypercare
Cut over all in-scope lines using the migration tested in rehearsal, freeze changes to master data during the cutover window, and confirm stock and open order balances against the reconciliation report. Stay on site or on call through a hypercare period agreed in the scope, reviewing tickets, data errors and integration failures daily and handing over runbooks, backup and restore steps, and the upgrade calendar to your operations team. Output: signed acceptance of the go-live checklist, a closed hypercare log and a handover pack your team can run without support.
Compliance questions a manufacturer must answer before go-live
Five regulatory regimes set conditions for a manufacturer running production on Odoo, and each one turns into configuration, access and record-keeping decisions before go-live. DeployOpen prepares the controls, configuration and evidence these regimes ask for, but independent auditors and certification bodies issue any audit report or certification.
NIS2 scope and reporting clock
NIS2 Annex II lists manufacturing as a critical sector, covering NACE Rev. 2 divisions 26 to 30 and medical and in vitro diagnostic devices. In-scope entities must send an early warning within 24 hours of a significant incident, a notification within 72 hours and a final report within one month. Important entities face fines of at least EUR 7 million or 1.4% of worldwide turnover. Confirm with counsel whether your entity is in scope, then check that the Odoo records needed to meet those three deadlines can be produced quickly.
Cyber Resilience Act product obligations
The Cyber Resilience Act, Regulation (EU) 2024/2847, applies to products with digital elements from 11 December 2027. Manufacturers' Article 14 duties to report actively exploited vulnerabilities and severe incidents have applied since 11 September 2026. Fines reach EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. Identify which of your products contain software or firmware, and confirm that vulnerability handling for them runs through a named owner with a reporting clock in Odoo's quality, maintenance or helpdesk workflows.
Machinery Regulation connection safeguards
The Machinery Regulation, Regulation (EU) 2023/1230, applies from 14 January 2027. Its essential requirement in Annex III, 1.1.9 requires that connecting another device or a remote device does not lead to a hazardous situation. Shop floor terminals, MES links, machine data feeds and remote service access all create such connections in an Odoo rollout. Review each integration path with your safety engineer before go-live, and keep the evidence that the safeguard is in place.
CMMC level for defense work
CMMC under 32 CFR Part 170 sets three levels for defense contractors. Level 1 covers the 15 FAR 52.204-21 safeguarding requirements, Level 2 covers the 110 requirements of NIST SP 800-171 Rev. 2 for CUI, and Level 3 adds 24 selected NIST SP 800-172 requirements. The Department of War suspended CMMC Phase II requirements on 13 July 2026. Confirm the level your contracts require and the current clause status with the contracting officer, then scope Odoo's engineering, PLM and document data to the CUI boundary.
21 CFR Part 11 electronic records
21 CFR Part 11 sets requirements for electronic records and electronic signatures in FDA-regulated production. In Odoo, this covers who can approve a quality check or batch step, whether changes leave an audit trail, and how each signature is tied to a named user. Test these controls in a validated copy of the database and document the results. Ask your quality unit to confirm which records count as Part 11 records before the first regulated batch is entered.
How Odoo support windows set the upgrade deadline
Odoo's support windows decide when a manufacturing database must move to a newer major version, so the end date belongs on the plant calendar before the build starts. Standard support for Odoo 19.0 runs until September 2028, and standard support for Odoo 18.0 runs until September 2027. Odoo 17.0 standard support ended in September 2026, so any plant still running it is outside the window that includes security patches. Security patches are only provided during standard support, which makes the end date a security decision as well as a feature decision. Confirm the current support table in Odoo's documentation before you fix a go-live date, because the dates are set by Odoo and can change the planning assumptions for your rollout.
The hosting type sets how strict the clock is. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, so a database cannot stay on an old release while the rest of the business moves on. Odoo Online also receives SaaS releases every two to three months. Small changes arrive continuously, so the settings for Manufacturing, work centers and Shop Floor screens should be rechecked against each release rather than only at upgrade time. For on-premise installations, confirm the upgrade obligation directly with Odoo's documentation and your subscription terms, but remember that the standard support end date still limits which security patches you receive. Your plant should set its own upgrade cadence against that date.
Odoo's upgrade service moves a database to a newer supported version by building an upgraded test database, and that test database is your first full rehearsal. Test it with production-like manufacturing flows: manufacturing orders, work order completion, quality checks, maintenance requests, subcontracting receipts and lot or serial traceability records. Compare the results with the source database and record any differences before anyone approves production cutover. On-premise use of the upgrade service requires an Enterprise subscription. The Community edition has no access to the upgrade service or its test database, so a Community manufacturing site needs a separate upgrade route with its own effort, testing and sign-off. Ask any partner to explain exactly how that route is tested.
Custom modules are the item most often missed in the upgrade budget. Work center logic, quality control rules, custom reports and integrations with PLM or other systems written for the old version may need porting before the upgrade test can pass. Plan that porting as a separate budget line with a named owner, test cases and acceptance criteria, not as an afterthought once the test database is built. Ask for an inventory of every custom module, where its source code lives, which business processes depend on it, and who must review each change. Keep that inventory current through every release cycle, because a module that works today may depend on a feature that changes in the next major version.
What manufacturers ask before hiring an Odoo partner
What drives the total cost of an Odoo manufacturing project?
The main drivers are edition and plan, the number of users, the apps and modules in scope, the integrations, the volume of data to migrate, and the number of custom modules. Subscription fees recur, and Odoo's pricing page lists per-user monthly prices with a yearly discount, so confirm current figures there. Implementation is one-time: it covers process mapping, configuration, custom work, migration, testing and training, and DeployOpen prices it from a written scope. Ask any partner for a quote that separates subscription, implementation, custom development, migration and ongoing support, so you can see which lines change if the scope changes.
How long does a discrete manufacturing Odoo implementation take?
Duration depends on the scope of the production model, not on the number of apps alone. The biggest drivers are bills of materials depth, work centers and routings, quality checkpoints, maintenance schedules, the number of integrations, data migration effort and the testing windows your operations can release. Shop floor devices and the time needed for hardware setup also add effort. A fixed-scope agreement sets phases, deliverables and dates in writing before work starts, so ask any partner to show how each phase depends on your master data and sign-offs.
What must our team provide during an Odoo manufacturing implementation?
Your team supplies the decisions and the data, and the project slows when either is missing. Process owners for production planning, purchasing, quality and maintenance must approve how work flows through the system. Master data such as products, bills of materials, work centers, routings, units of measure and suppliers needs to be reviewed and cleaned before migration. Shop floor access is needed for walkthroughs and for testing on the actual devices and stations. Test time requires named testers who can run realistic production orders during user acceptance testing and sign off before go-live.
Can our production planner or IT lead run an Odoo implementation internally?
A planner or IT lead can own the process decisions and the acceptance criteria, but building and maintaining the system needs specific technical skills. Internal teams usually need experience with Odoo's data model, its configuration and its custom module development in Python and XML, plus database administration on PostgreSQL. Upgrades need a tested upgraded database before production, so someone must own that cycle. Decide which tasks your team will carry, which you will hand to a partner under a written scope, and who will support the system after go-live.
How do Enterprise-only features change the Odoo project budget?
Several manufacturing capabilities are part of the paid Enterprise edition. Quality checks, maintenance and PLM are Enterprise features, and the Enterprise source code is not publicly available, so it requires a subscription or partner access. Enterprise also includes the upgrade service that on-premise deployments depend on, and Community users do not have that service. Budget for the Enterprise subscription as a recurring cost, and confirm which other features your processes need on the pricing page. If a feature is not needed at launch, you can phase it in later, which changes the scope and quote.
What changes for our Odoo manufacturing system at upgrade time?
On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years. Odoo's standard support covers the first three years after a major release, including security updates and bug fixes, and security patches are only provided during standard support. Odoo 19.0 is covered until September 2028 and Odoo 20.0 until September 2029. SaaS versions are released every two to three months and cannot use extended support. Each upgrade produces a test database that should be tested before production, and custom modules may need porting and retesting. Ask for the upgrade approach and the test effort in the written scope.
Which Odoo hosting option works for a manufacturer with its own infrastructure?
Odoo Online is the vendor-hosted option, and the pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise. Only the Custom plan includes multi-company, Odoo Studio, external API access and custom modules. If you need the system inside your own cloud accounts, data center or a restricted network, the Custom plan and an on-premise or self-managed deployment are the paths to check. DeployOpen implements and supports platforms inside the client's own infrastructure. Confirm plan entitlements against the current pricing page and set the hosting decision before the scope is written.
How DeployOpen scopes and delivers Odoo for manufacturers
DeployOpen plans, builds and supports Odoo for manufacturers inside infrastructure you control, whether that is your cloud account, your data center or an isolated network. Engagements are fixed-scope, so the manufacturing processes, apps, custom work and deliverables are agreed in writing before the build starts.
How we scope
- Map your production flow, bills of materials, work centers and shop floor steps before choosing apps or editions.
- Confirm which edition fits each need, since Enterprise features such as maintenance and PLM sit outside Community.
- Record the written scope, deliverables and timeline, and confirm the Odoo version and its standard support end date.
How we build
- Configure MRP, work centers, quality checks and traceability against the process maps agreed in scoping.
- Build and test custom modules, integrations and data migration in a staging database before any cutover.
- Validate that the Enterprise subscription, hosting type and user model match the planned production setup.
How we hand over
- Document configuration, custom modules, integrations and the test evidence produced during the build.
- Walk your administrators through production routines such as user access, quality checks and backup restores.
- Deliver an upgrade plan that covers the planned major version path and the test database steps before production.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, defined in writing.
- Plan regular upgrade tests on a copy of production, since Odoo Online and Odoo.sh require major upgrades every two years.
- Review version support windows with you so security patches stay within standard support.
