Migrate from Ostendo to Epicor Prophet 21

Ostendo Customer records in the CUSTOMER MASTER table export via the Data Exporting function as CSV or Excel. We map to Epicor Customer (or CustCnt contact records) using customer code as the dedupe key. If the customer uses Ostendo's Contact sub-records, these map to Epicor CustCnt contact entries with the parent Customer linkage preserved. Address structures from CUSTOMER MASTER export as Customer address records in Epicor.

ITEMMASTER holds all item records including Primary Supplier linkage, unit cost, and stock levels. We export the full item record and map to Epicor Part by part number as the dedupe key. The Ostendo supplier linkage maps to Epicor's Vendor table cross-reference so that Part-vendor relationships are preserved. Stocking type (make, buy, blank) maps to TypeCode in Epicor Part.

Ostendo tracks stock quantities per stock location, bin reference, and serial number. Multi-site records require denormalisation into Epicor's PartLot table (which holds lot number, serial number, and quantity) and WarehseBin (warehouse-bin location). Each unique combination of item, site, warehouse, and bin in Ostendo becomes a separate PartLot record in Epicor. Serial number tracking per location maps to the PartLot SerialNumber field.

Ostendo Service Zones group assets geographically for field service deployment. We map these to Epicor Site records for the manufacturing or distribution entity, Warehouse records for each physical location, and Territory records for service dispatch geography. The mapping depends on whether the customer runs single-site or multi-site operations in Ostendo.

Ostendo Sales Orders export with header and line-level detail, including Order Style, quantities, pricing, and status. We map to Epicor Sales Order with line items and SORels (release) structure. If Ostendo POS generated orders, these require flagging during scoping as POS-order headers may carry non-standard status values. Order dates, ship dates, and due dates migrate as OrderRel dates in Epicor.

Purchase Orders export from Ostendo with line items, quantities, supplier linkage, and order status. We map to Epicor PO Header with linked POLine records. Supplier code resolves to the Epicor Vendor record created from the ITEMMASTER Primary Supplier mapping. PO release dates migrate to Epicor's PO Release dates if the customer uses scheduled receipt functionality.

Work Orders in Ostendo include job details, routing, and multi-level BOM references. Multi-level BOMs require flattening during transformation: each BOM level in Ostendo becomes a separate JobMtl record in Epicor with the parent assembly linked via JobMtl.ParentMtlSeq. Routing operations map to JobOper with work centre and estimated run time. We flag any non-standard Work Order statuses for customer review before loading.

Ostendo BOMs are stored per item with nested assembly levels. We extract all BOM levels, denormalise into PartMtl records with PartMtl.ParentPart and PartMtl.MtlPart linking, and map assembly operations to PartOpr. Epicor BOM revisions are versioned; if Ostendo uses revision control, each revision maps to a separate Epicor PartRev record. The customer identifies the active BOM revision during scoping.

Asset records are linked to Service Zones and carry meter readings, equipment checks, and maintenance history. We export asset master data including current status, location (Service Zone), and maintenance history lines. In Epicor, assets map to the Asset register with AssetLoc records holding the site/warehouse location and MeterReadings linked to the asset for preventive maintenance tracking.

Timesheet records linked to Work Orders and Jobs export from Ostendo with clock-in, clock-out, work centre, and materials issued. We map to Epicor laborHdr (header) and laborDtl (detail) records, resolving the employee reference to the Epicor Employee table. GPS data from Freeway Mobile entries cannot migrate to Epicor's standard Labour module; we flag GPS-bearing entries for customer review and document the source location for manual reference.

Ostendo user records export from User Security and Options, but the licensing model is concurrent users (simultaneous logins), not named users. We export the full user record set and present a named-user equivalent count during scoping. Migration into Epicor requires provisioning named User accounts; the customer's admin creates Epicor User records and we validate Owner references on imported records against the resolved User table.

Ostendo Freeway Mobile templates create user-defined fields per object including checklists, compliance forms, and QA inspections. These are stored per-object without a standard export format. We flag all custom template field definitions during discovery, create explicit field mappings for each one, and pre-create Epicor UD fields (using UD Service Designer in Kinetic or extended table columns in On Prem) before data load. Fields that cannot hold equivalent data (for example, GPS coordinates on non-geographic objects) are flagged for manual recreation in Epicor.

Ostendo SQL Report Writer creates saved reports, inquiries, and pivot tables referencing Ostendo-specific table structures. These have no direct equivalent in Epicor ERP and do not migrate. We deliver a written inventory of every Ostendo report and saved query with its table references and logic, plus a recommended Epicor BAQ equivalent for the customer's admin or Epicor partner to rebuild post-migration.

If Ostendo Quotes are generated as Sales Order-style records with an order style of Quote, we export them and map to Epicor Quote. Quote headers, lines, and pricing migrate as Epicor Quote records. Signed or accepted quote status does not automatically advance the Quote to Order in Epicor; the customer reviews Quote-to-Order conversion after migration.