Migrate from Oracle Manufacturing Cloud to Epicor Prophet 21

Oracle Manufacturing Plants map to Epicor Kinetic Sites. Oracle's plant-level attributes including plant code, name, and organizational assignment transfer to the Site record. The plant's associated Manufacturing Calendar must land in Epicor before the Site is activated, because Epicor's Site Calendar assignment is validated at activation time. Oracle's multi-plant hierarchies (parent plant, child plant) may require flattening if the destination Epicor configuration uses a single-site model; we flag this during scoping.

Oracle Manufacturing Calendars map to Epicor Kinetic Calendar records. The calendar's shift pattern definitions transfer as Epicor shifts and shift patterns. Calendar-to-shift assignments are preserved during mapping so that shift exceptions and holiday rules carry forward. Oracle calendars reference plant-level defaults; Epicor calendars attach to Sites. We verify that the Oracle calendar definition covers the production week (Monday through Saturday, for example) before mapping to Epicor's day-of-week shift assignments.

Oracle Departments map to Epicor Kinetic Departments, which represent cost and responsibility centers. Department associations to Work Centers in Oracle transfer as Work Center assignments in Epicor. Departments must exist in Epicor before Work Centers import, because Work Centers require a Department reference at creation time.

Oracle Work Centers map to Epicor Kinetic Work Centers with capacity, availability rules, and UOM overrides preserved. Work Center type (machine, labor, department) maps from Oracle's resource type classification. UOM overrides at the work center level transfer to Epicor's UOM overrides on the Work Center record. Work Centers must import after Departments and before Work Definitions, because routing operations in Epicor reference both the Department and the Work Center.

Oracle Items map to Epicor Kinetic Part Master records. Item attributes including item class, UOM class, and the make-or-buy flag transfer to Epicor Part.Oracle's item numbering convention must be verified against Epicor's Part Number field before import to avoid duplicate or rejected records. The item's manufacturing type (phantom, standard, config) maps to Epicor's Type Code.

Oracle Work Definitions map to Epicor Kinetic Job records. The operation sequence, work center assignments, and step-level details transfer to JobHead (job header) and JobOper (job operation) records. Oracle's work definition start date is critical: it must equal or precede the cost scenario effective date for cost rollup to succeed. We flag all work definitions where the start date is later than the associated cost scenario effective date before Epicor import and require explicit correction. Mixed-mode production environments require explicit co-product and by-product routing mapping to Epicor's JobMtl records for secondary outputs.

Oracle Bills of Materials map to Epicor Kinetic BOM records linked via Part Number. The multi-level BOM hierarchy including co-products and by-products transfers to Epicor as ECOMtl records with the appropriate mtlType (stocked, non-stocked, phantom, co-product, by-product). The destination must have the same item structure for BOM lines to resolve correctly; we verify item existence in Epicor before BOM import begins. Co-product and by-product BOM lines require explicit mapping to Epicor's mtlType field because Oracle uses different flags.

Oracle Work Orders map to Epicor Kinetic Job records with status, quantities, scheduled dates, and operations routing preserved. The work order's associated plant (mapped to Site), item (mapped to Part), and work definition (mapped to Job routing) references must resolve before Job import. Oracle Work Order status (released, on hold, closed) maps to Epicor Job status. Open work orders with quantities in process transfer to Epicor Job as partially complete records with actual quantities and operations completed.

Oracle Cost Scenarios map to Epicor Kinetic PartCost and related cost detail records. The cost element mappings (material, resource, overhead) transfer to Epicor cost records with the cost type and effective date preserved. The effective date must equal or follow the work definition start date that Epicor uses for cost rollup. We perform date alignment remediation during the mapping phase: any Cost Scenario with an effective date later than the corresponding Work Definition start date is flagged and corrected before Epicor import to prevent silent cost rollup failures.

Oracle Smart Operations Configurations (UOM defaults at plant level, work center UOM overrides, reason codes, operator assignment rules, target metrics including OEE and plan adherence) do not have a direct Epicor equivalent. These configurations must be rebuilt as Epicor Kinetic MES Configuration records by the customer's Epicor admin post-migration. We deliver a written inventory of every Smart Operations configuration with its Oracle object path, current parameter values, and recommended Epicor MES Configuration equivalent. The rebuild is outside migration scope but the inventory is included in the handoff package.

Oracle Production Sequences governing the order of operations execution map to Epicor Kinetic Sequence records with their step associations. Mixed-mode production environments require explicit mapping of co-product and by-product sequence definitions because Oracle and Epicor use different flags for secondary output sequencing. We export sequence definitions and step associations from Oracle and map them to Epicor as Production Sequences linked to the relevant Part revision.

Oracle Custom Objects created via Application Composer map to Epicor Kinetic UD (User Defined) tables. We export the object definition and all data, but a key constraint applies: Epicor UD tables must be created in a clean target environment. We require the destination Epicor org to have no pre-existing UD table with the same logical name before migration. Oracle's environment-specific custom object metadata requires manual schema recreation in Epicor UD Designer before data import; we include the field definition map in the migration inventory.

Attachments associated with Work Orders, Items, and Work Definitions in Oracle export via Oracle's document management. File type, size limits, and the attachment association metadata map to Epicor's Document Management records with the document's association to the parent entity (Job, Part, or other). We verify file size compatibility against Epicor's document storage limits and flag any attachments that exceed the threshold for manual handling.

Oracle Reason Codes used at workstations for production variances and exceptions map to Epicor Kinetic Reason Codes. The reason code set and its usage context (variance reason, scheduling exception, completion reason) transfer to Epicor. Reason codes are environment-specific and must be imported before Work Orders because Epicor enforces reason code validation during transaction posting. We include reason code mapping in the master data import phase, before Job and transaction migration begins.