ERP migration
Field-level mapping, validation, and rollback between JiBe and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
JiBe
Source
Epicor Prophet 21
Destination
Compatibility
7 of 12
objects map 1:1 between JiBe and Epicor Prophet 21.
Complexity
BStandard
Timeline
6-8 weeks
Overview
JiBe and Epicor ERP occupy different industry verticals, which makes this migration a cross-domain data restructuring rather than a platform upgrade. JiBe structures its data around maritime operations—vessels, PMS location hierarchies, chartering agreements, crew certifications, and insurance policies—while Epicor ERP is built for discrete manufacturing and distribution with core entities around Part Numbers, BOMs, Work Orders, and Suppliers. We extract data from JiBe through professional services coordination (JiBe publishes no public API), profile each vessel's custom PMS structure, and load vessel master records, maintenance jobs, spare parts, procurement records, crew accounts, and commercial data into Epicor's Part Master, Work Order, Inventory, and HR modules. Chartering agreements, insurance policies, and incident records map to custom Epicor objects or require manual rebuild depending on the customer's configuration. BI reports and dashboards do not migrate; we deliver the underlying data so the destination platform can rebuild equivalent reporting from scratch.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a JiBe object lands in Epicor Prophet 21, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
JiBe
Vessel
Epicor Prophet 21
Part (Asset-linked)
1:1JiBe Vessel master records (name, IMO number, flag state, vessel type, fleet hierarchy parent) map to Epicor Part records with a custom asset linkage. We create an Epicor Part record per vessel using the vessel's IMO number as the Part Number, vessel name as the Part Description, and vessel type as a UDF. The fleet parent relationship maps to an Epicor Job or BOM structure if the customer uses Epicor's project or contract manufacturing module to represent fleet-level grouping. Vessel-to-fleet groupings require customer confirmation during scoping because Epicor's native asset hierarchy is site-centric rather than fleet-centric.
JiBe
PMS Location
Epicor Prophet 21
Part/BOM Component (custom hierarchy)
1:manyJiBe PMS location hierarchies define machinery and component structures per vessel. Because JiBe allows custom PMS hierarchies per vessel, the same machinery type may model differently across ships. We profile each vessel's PMS structure during discovery, normalize component names against a shared taxonomy where possible, and create Epicor Part records or BOM components for each unique location node. Vessels with deeply nested custom hierarchies may require multi-level BOM structures in Epicor that the customer's engineering team validates before production migration.
JiBe
Maintenance Job
Epicor Prophet 21
Work Order
1:1JiBe maintenance jobs (status, priority, work order data, linked PMS location, historical completion records) map to Epicor Work Order Header and Work Order Detail records. Open jobs migrate with current status flags (Open, In Progress, Overdue) mapped to Epicor Job status values. Completed historical jobs migrate as closed Work Orders with the original completion date preserved in the JobHead.JobCompleteDate field. JiBe's incident-to-job linkage migrates as a Work Order character field reference rather than a native Epicor link.
JiBe
Spare Part
Epicor Prophet 21
Part (Inventory)
1:1JiBe spare parts (part numbers, stock levels, reorder points, supplier links, custom part number formats) map to Epicor Part and PartBin records. We normalize custom JiBe part number formats into Epicor-standard Part.PartNum during transformation. Stock levels migrate to PartBin.OnhandQty per site and warehouse. Reorder points migrate to PartReplenishment or as a UDF depending on the customer's Epicor inventory configuration. Supplier links map to PartXRefVend records in Epicor, preserving the vendor-to-part linkage across the procurement workflow.
JiBe
Procurement Record (Purchase Order)
Epicor Prophet 21
PO Header + PO Release
1:1JiBe purchase orders and requisitions (vendor, vessel-level procurement needs, line items, status) map to Epicor PO Header and PO Release records. Open POs migrate by status (Open, Released, Pending) and preserve the vendor-to-part linkage. Closed POs migrate as historical records for audit continuity. JiBe custom fields for rate structures or approval chains become Epicor PO character fields or require a post-migration configuration review with the customer's procurement admin.
JiBe
Chartering Agreement
Epicor Prophet 21
Custom Object (Contract/Quote)
lossyJiBe chartering records contain contract terms, counterparty details, voyage data, rate structures, and port itineraries. Epicor ERP does not have a native chartering module. We map chartering agreements to Epicor Quote (for voyage rate quotes) or a custom Contract object built in Epicor's customization framework. Counterparty details map to Epicor Customer or Supplier records depending on charter type. Custom fields for rate structures and itineraries require customer-specific configuration during scoping and may require post-migration admin rebuild for full functional parity.
JiBe
Crew Account
Epicor Prophet 21
Employee (HR)
1:1JiBe crew records (personal details, rank, certifications, payroll associations, vessel assignment, certification expiry dates) map to Epicor Employee records. Rank maps to a Job Role or Department code in Epicor HR. Certifications and expiry dates migrate as custom HR fields or as Employee competency records depending on whether the customer licenses Epicor MES or HR module. Crew-to-vessel assignments migrate as Employee Ship/Asset assignments via a custom field or Epicor's project or work force management module. Certification expiry dates are preserved for compliance continuity.
JiBe
Insurance Policy
Epicor Prophet 21
Custom Object (Policy)
lossyJiBe insurance records per vessel carry coverage types, policy numbers, carrier details, and in some deployments linked incident claims. Epicor ERP does not have a native insurance policy module. We create a custom InsurancePolicy object in Epicor with fields for policy number, carrier, coverage type, effective dates, and linked asset (vessel Part record). Claims linked to incidents map as separate Claim records linked to the InsurancePolicy custom object. This is a configuration-heavy mapping that requires customer-specific schema design during discovery.
JiBe
Incident / Defect
Epicor Prophet 21
ECO/Change Request or Custom Object
lossyJiBe incident reports link to PMS locations and can trigger maintenance jobs with associated costs. Epicor handles equipment failures through its MES, Maintenance, or Quality modules depending on the Epicor Kinetic edition licensed. We map incidents to Epicor ECO (Engineering Change Order) for defect-driven changes or to a custom Incident object. Incident-to-job linkage migrates as a character field reference. Cost data from incidents migrates to Epicor PartCost or JobOper records where applicable. The customer confirms the destination module during scoping.
JiBe
Commercial Record
Epicor Prophet 21
Sales Order / Invoice / Customer
1:1JiBe commercial records (freight revenue, voyage settlement, commercial KPIs) map to Epicor Sales Order, Invoice, or AR Invoice records depending on the customer's Epicor financials configuration. Counterparty details migrate to Epicor Customer records. Voyage settlement data maps to Epicor Project or Contract records if the customer licenses Epicor Project Management. Commercial KPIs migrate as numeric UDFs on the relevant document headers. The customer confirms the financial module configuration during discovery.
JiBe
Fleet Hierarchy
Epicor Prophet 21
Site / Business Unit
lossyJiBe fleet hierarchies group vessels under parent fleet structures. Epicor's organizational model uses Sites and Business Units. We map JiBe fleet parents to Epicor Site records or Business Unit codes, with vessel-level records linked to the appropriate Site. Multi-fleet organizations requiring hierarchical reporting above the Site level use Epicor's Company or Division structure if licensed. This mapping requires customer-specific organizational design during scoping.
JiBe
Business Intelligence Report
Epicor Prophet 21
None
1:1JiBe BI reports and dashboards are configuration artifacts built from the platform's internal data model. Epicor Kinetic dashboards and BAQ reports must be rebuilt from migrated data. We extract the underlying data—maintenance records, performance metrics, parts consumption, crew hours, commercial KPIs—and deliver it in structured CSV and JSON formats that the customer's Epicor admin uses to rebuild equivalent reports in Epicor BAQ, Kinetic dashboards, or a connected BI tool such as Power BI or Tableau.
| JiBe | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Vessel | Part (Asset-linked)1:1 | Fully supported | |
| PMS Location | Part/BOM Component (custom hierarchy)1:many | Fully supported | |
| Maintenance Job | Work Order1:1 | Fully supported | |
| Spare Part | Part (Inventory)1:1 | Fully supported | |
| Procurement Record (Purchase Order) | PO Header + PO Release1:1 | Fully supported | |
| Chartering Agreement | Custom Object (Contract/Quote)lossy | Fully supported | |
| Crew Account | Employee (HR)1:1 | Fully supported | |
| Insurance Policy | Custom Object (Policy)lossy | Fully supported | |
| Incident / Defect | ECO/Change Request or Custom Objectlossy | Fully supported | |
| Commercial Record | Sales Order / Invoice / Customer1:1 | Fully supported | |
| Fleet Hierarchy | Site / Business Unitlossy | Fully supported | |
| Business Intelligence Report | None1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
JiBe gotchas
No publicly documented public API for data export
Business Intelligence reports are not migratable data
PMS location hierarchies vary by vessel configuration
Epicor Prophet 21 gotchas
Third-party bolt-on integrations complicate migration scope
Dirty data without standardized processes compounds migration risk
SDK customizations and BPMs may not survive platform upgrades
Report-based export only for non-technical users
Per-user pricing model requires accurate user count before migration planning
Pair-specific challenges
Migration approach
JiBe professional services coordination and data export
We engage JiBe professional services on the customer's behalf to request structured data exports. The export scope covers vessel master records, fleet hierarchy, PMS location hierarchies (per vessel), maintenance job history and open jobs, spare parts inventory and supplier links, purchase orders and requisitions, crew accounts with certifications, chartering agreements, insurance policies, incident records, and commercial KPIs. We define the export format (CSV, JSON, or database dump) with JiBe technical contacts and validate the export completeness against the scoped record counts before accepting the dataset. JiBe professional services fees are billed separately by JiBe and sit outside the FlitStack AI migration fee.
Discovery and Epicor edition assessment
We profile the JiBe data exports for record counts, custom fields, PMS hierarchy depth per vessel, parts inventory volume, crew roster size, and open procurement and commercial record volumes. We simultaneously assess the customer's Epicor environment: which Epicor Kinetic edition or on-premise version is licensed, which modules are active (Financials, MES, HR, Project Management), and what existing Part, Supplier, Customer, and Employee records already exist in Epicor. The discovery output is a written migration scope, data quality report, and Epicor configuration checklist for the customer's admin to complete before schema design begins.
Epicor schema design and custom object creation
We design the destination Epicor schema: Part records for vessels and spare parts, BOM structures for PMS location hierarchies, Work Order templates for maintenance jobs, custom InsurancePolicy and CharteringContract objects, Employee records for crew, and PartXRefVend records for supplier links. We deploy schema changes to a Sandbox org first for validation. For each vessel we create a Part record linked to the appropriate Site. For each PMS location node we create BOM components or Part records depending on whether the component represents a replaceable part or a location grouping. Custom UDFs are created for JiBe-specific fields that have no Epicor standard equivalent.
Data quality remediation and transformation
We run JiBe data through a quality pipeline: duplicate vessel detection (by IMO number), PMS location name normalization across vessels, parts-with-missing-supplier-flagging, crew certification expiry date validation, open PO completeness check, and custom field format validation against Epicor's part number rules. Each quality issue is logged in a remediation report with owner and due date. We do not modify source data without customer authorization; quality issues that require source correction return to the customer's JiBe admin for remediation before transformation begins.
Sandbox migration and reconciliation
We run a full migration into an Epicor Sandbox using production-like data volume. The customer's operations lead reconciles record counts (Vessels in, Parts in, Work Orders in, Inventory in, Employees in), spot-checks twenty to thirty random records against the JiBe source, and validates that maintenance job linkages resolve correctly in Epicor. Any mapping corrections, missing fields, or data quality issues surfacing in Sandbox are resolved here before production migration begins. Chartering and insurance custom object configurations are validated in Sandbox before committing to production.
Production migration and BI data delivery
We run production migration in dependency order: vessel Part records (first, as the root entity), fleet hierarchy mapping, spare parts inventory, PMS BOM structures, maintenance Work Orders, open purchase orders, crew Employee records, custom chartering and insurance records, and commercial data. We use Epicor's REST API or data import tools depending on volume. Each phase emits a reconciliation report before the next phase begins. We deliver the underlying JiBe BI data (maintenance logs, performance metrics, parts consumption, crew hours, commercial KPIs) as structured CSV and JSON files for the customer's Epicor admin to rebuild equivalent reports in Epicor BAQ or a connected BI tool.
Cutover, validation, and rebuild handoff
We freeze JiBe writes during cutover, run a final delta migration of any records modified during the window, then enable Epicor as the system of record. We deliver a chartering and insurance rebuild guide describing how to configure Epicor's custom objects for maritime contract management. We deliver the BI data package and a BAQ template for the customer's Epicor admin to rebuild fleet performance reports. We support a one-week hypercare window for reconciliation issues. We do not rebuild JiBe workflows, chartering automation, or crew scheduling logic inside the migration scope; these require a separate Epicor configuration engagement.
Platform deep dives
JiBe
Source
Strengths
Weaknesses
Epicor Prophet 21
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across JiBe and Epicor Prophet 21.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
JiBe: Governed by iCIMS API limits — not separately published for Jibe components..
Data volume sensitivity
JiBe exposes a bulk API — large-volume migrations stream efficiently.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during JiBe to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your JiBe to Epicor Prophet 21 migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave JiBe
Other ways to arrive at Epicor Prophet 21
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.