Migrate from Oracle Manufacturing Cloud to Odoo ERP

Oracle Work Orders map to Odoo Manufacturing Orders. The Oracle work order status (Pending, In Progress, On Hold, Closed) maps to Odoo's mrp.production states with material availability and production availability checked on import. We resolve the parent item reference to the Odoo product.id, the work center assignments to Odoo mrp.workcenter.id, and the scheduled start and end dates to Odoo's date_start and date_finished fields. Work order operations routing maps to Odoo Work Order Components within the MO.

Oracle Work Definitions define the routing steps for manufacturing an item and map to Odoo Manufacturing Routings. Each operation in the work definition (operation sequence, work center assignment, step duration) maps to mrp.routing.workcenter records. A migration-critical issue: the work definition start date must equal or precede the cost scenario effective date in Oracle, and we resolve this date-alignment mismatch during transformation before any routing data lands in Odoo to prevent silent cost rollup failures in the destination.

Oracle Items map to Odoo Products with careful handling of the make-or-buy flag. Items with make-or-buy set to Make become Odoo products with the manuf attribute set and linked to a BOM. Items set to Buy become Odoo products with the vendor list and purchase route configured. Oracle's item numbering convention must match Odoo's product reference field for BOM line resolution to succeed. We flag any item with a missing or mismatched UOM and apply Odoo's UoM conversion rules at import time.

Oracle Manufacturing Plants map to Odoo Warehouses and their child Locations. Each plant's organizational hierarchy becomes a warehouse with its associated sub-locations for work-in-progress, storage, and shipping. The plant's manufacturing calendar reference maps to Odoo's shift and working hours configuration on the warehouse. We flag multi-plant Oracle environments where separate Odoo warehouses are needed and configure inter-warehouse transfer rules if the customer runs WIP between plants.

Oracle Work Centers represent production resources (machines, labor pools, departments) and map directly to Odoo mrp.workcenter. We export capacity, availability rules, and UOM overrides from Oracle and configure them on the Odoo Work Center. Time efficiency and capacity factors map to Odoo's work center efficiency fields. The work center must be created in Odoo before the Routing that references it is activated, so we sequence work center import ahead of routing import.

Oracle Manufacturing Calendars define plant working times and shift patterns and map to Odoo Resource Calendars. The calendar must be imported and activated before the Manufacturing Plant or Work Center that references it in Odoo, because Odoo computes capacity and scheduling based on working hours at the moment of Work Order scheduling. We export the calendar definition and its shift assignments and flag any Oracle calendar-to-shift assignments that require additional shift pattern definitions to be provisioned in Odoo first.

Oracle Cost Scenarios define material, resource, and overhead costs and map to Odoo's cost history via the product's standard price configuration after migration. The effective date on the cost scenario must equal or follow the work definition start date in Oracle; we identify every record where this constraint is violated during the mapping phase and flag it for explicit correction before import to prevent silent cost rollup failures in Odoo. We export cost element mappings but note that Odoo does not have an equivalent multi-scenario cost structure and typically uses a single active standard cost per product.

Oracle BOMs define the component structure for each item and map to Odoo mrp.bom. We export multi-level BOM hierarchies including co-products and by-products, with each BOM line resolved to the corresponding Odoo product.id. The destination must have the same item structure for BOM lines to resolve correctly; we flag any BOM line referencing a component that does not exist in the migrated product catalog. Co-product and by-product routing data requires explicit configuration in Odoo at the BOM level and is one of the most common remapping points in Oracle-to-Odoo manufacturing migrations.

Oracle Smart Operations Configurations include UOM defaults at plant level, work center UOM overrides, reason codes, operator assignment rules, and target metrics (plan adherence, OEE). These map to Odoo Quality App checks (reason codes), Maintenance App (equipment and preventive maintenance linked to work centers), and Odoo IoT module (sensor integration for OEE). OEE dashboards in Oracle have no direct Odoo native equivalent and require configuration using Odoo's reporting tools or a custom dashboard. We document the mapping and flag gaps for manual configuration post-migration.

Oracle Custom Objects created via Application Composer are environment-specific and map to Odoo custom models via the Studio module or direct model definition. We export the custom object definition and data, but a key limitation: if the same custom object has been manually provisioned in the Odoo destination, re-importing can cause metadata inconsistency. We only migrate custom object data into clean destination environments where the model has been pre-created from the migration definition, not manually provisioned by the customer. Custom object lookup relationships to standard objects (Items, Work Orders) map to Odoo many2one fields on the custom model.

Oracle Production Sequences govern the order of operations execution and map to Odoo Routing operations with explicit sequence ordering. Mixed-mode production environments where Oracle runs co-product and by-product routing require explicit mapping configuration in Odoo at the BOM level using the By-Products tab on the mrp.bom form. We flag every production sequence with mixed-mode routing and document the Odoo configuration steps required to reproduce the same operation sequencing in the destination.

Oracle Departments represent organizational cost and responsibility centers and map to Odoo hr.department records. Departments must exist in the destination before work centers can be associated with cost accounting in Odoo. We export department definitions and their association to work centers and provision the department structure in Odoo before the work center migration phase begins. Note that Odoo's department model is HR-centric and not identical to Oracle's cost-center hierarchy; we flag any Oracle departments with cost-accounting roles that may require additional configuration in Odoo's analytic accounting.

Oracle Reason Codes are used at workstations to explain production variances and exceptions and map to Odoo Quality Reason records via the Quality App. We export the reason code set and its usage context (work order scrap, rework, yield variance). Reason codes are environment-specific and must be imported via Odoo's configuration data import before the first production order is opened. We flag any Oracle reason codes that reference Smart Operations IoT triggers, as these require rebuild in Odoo IoT module.

Attachments associated with work orders, items, and work definitions in Oracle export via Oracle's document management and map to Odoo ir.attachment records linked via res_model and res_id to the corresponding production order, product, or work center. File type, size limits, and the attachment association metadata require explicit mapping during the transformation phase. We flag any attachments exceeding Odoo's default 25MB file size limit and document them for the customer to handle separately or configure Odoo's document management settings to accommodate.