Migrate from Oracle Manufacturing Cloud to Microsoft Dynamics 365 Business Central

Work Orders are the primary production execution record in Oracle Manufacturing Cloud and map to D365 Production Orders. We export work order status, quantities, scheduled dates, and the full operations routing. D365 Production Order status lifecycle (Open Order, Released, Completed, Ended) maps from Oracle status codes. Scheduled start and end dates transfer to D365 Scheduled Start and Scheduled End. The production order BOM version and route version are resolved at migration time against the BOM and route mappings already landed.

Work Definitions define the routing steps for manufacturing an item—operation sequence, work center assignments, and step-level details. These map to D365 Route as route operations with operation number, work center reference (Operations Resource), and transit time. A migration-critical dependency: the work definition start date interacts with cost scenario effective dates. We flag any work definition where the start date is later than the associated cost scenario effective date during mapping and require explicit correction before import to prevent post-migration cost rollup failures.

Items are the master product records that drive BOMs and work definitions and map to D365 Released Products. We export item class, unit of measure, and the make-or-buy flag (manufacturing type). Oracle's item numbering convention must match D365 product number format; we validate length, character set, and uniqueness constraints during the transform phase. Items must be migrated before BOMs and work definitions because every BOM line and routing step references an item number that must already exist as a released product.

Manufacturing Plants define the organizational unit where production occurs and map to D365 Sites within a legal entity. We export plant hierarchy, calendar associations, and plant-level defaults. The Site must exist in D365 before any Work Centers (Operations Resources) or Production Orders can reference it. We load Sites before Work Centers and before Production Orders, and we flag any plant-level default UOM settings from Oracle Smart Operations Configurations for migration as site-level production parameters.

Work Centers represent production resources (machines, labor pools, departments) and map to D365 Operations Resources filtered by resource type of Machine or Labor. We export capacity, availability rules, and UOM overrides at the work center level. Operations Resources must land before Work Definitions (Routes) because route operations reference the resource. The resource group assignment in D365 maps from Oracle department-to-work-center associations.

Manufacturing Calendars define plant working times and shift patterns. They must be migrated before Manufacturing Plants because a plant references its calendar at activation. We export calendar definitions and shift assignments. D365 Production Calendar defines working days and shift patterns controlling scheduling and capacity planning. We extract calendar-to-shift pattern assignments and replicate them as Production Calendar working time templates in D365 with the same working hours and exception day patterns.

Cost Scenarios define material, resource, and overhead cost rollups and must be migrated after Work Definitions because the work definition start date constrains the cost scenario effective date. Dynamics 365 Costing Version holds the cost data per site and item. We export the cost element breakdown and load it into a costing version with an effective date equal to or later than the associated work definition start date. Any date mismatch is flagged for explicit correction before import to prevent silent cost rollup failures that surface only in production billing.

Smart Operations Configurations encompass UOM defaults at plant level, work center UOM overrides, reason codes, operator assignment rules, and target metrics like plan adherence and OEE. These are environment-specific configurations that must be imported via D365 Data Management after the core manufacturing setup is in place. Reason codes migrate as production reason code groups and production parameters. Metrics like OEE and plan adherence have no direct D365 standard equivalent; we document the source values and recommend Power BI reporting as the replacement.

BOMs define the component structure for each manufactured item and must be migrated after Items because every BOM line references an item number that must already exist in D365 as a released product. Oracle multi-level BOMs with co-products and by-products map to D365 BOM with a type of BOM or Formula depending on the manufacturing mode. We extract the full multi-level hierarchy and validate that the item structure matches before loading. Co-product and by-product routing data requires explicit remapping because D365 uses BOM line types rather than a separate routing sequence for co-product output.

Departments represent organizational cost and responsibility centers and map to D365 Operations Resources filtered by resource type of Department. Department associations to work centers migrate as resource group assignments. Departments must exist in D365 before cost accounting assignments on work orders can resolve, so we load Departments before Operations Resources and before the first Production Order import.

Custom Objects created via Oracle Application Composer are environment-specific and cannot be safely imported into a D365 target where the same object has been manually provisioned. Oracle explicitly warns that manually creating a custom object in the target environment and later running an export-based import of the same custom object causes metadata inconsistency beyond repair for some object types. We export the object definition and data, pre-create the D365 custom table schema with all custom fields and relationships, and load into a clean target environment only. Custom object metadata is documented for admin rebuild if the target was pre-populated.

Attachments associated with work orders, items, and work definitions are exported from Oracle document management. File type, size limits, and attachment association metadata are explicitly mapped to D365 SharePoint document storage or blob storage URLs. We do not migrate attachment bodies into D365 database records; they are stored in linked document management with a database record holding the reference. The attachment association (which work order or item owns the file) migrates as a SharePoint document location record.

Production Sequences govern the order of co-product and by-product output in mixed-mode production and must be mapped to D365 production order lines and picking route lines. Oracle co-product and by-product routing data requires explicit remapping in D365 because D365 uses a different model for co-products (as BOM lines of type By-product or Co-product) versus a separate routing sequence. We flag all mixed-mode production configurations during discovery and require the customer to confirm the target co-product BOM structure before migration.

Reason Codes are used at workstations to explain production variances and exceptions. We export the reason code set and its usage context. Reason codes are environment-specific and must be imported via D365 Data Management as production reason code groups. The mapping preserves the reason code ID, description, and applicable production transaction type so that variance reporting continuity is maintained after cutover.