ERP migration
Field-level mapping, validation, and rollback between FUJITSU GLOVIA G2 and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
FUJITSU GLOVIA G2
Source
Epicor Prophet 21
Destination
Compatibility
10 of 12
objects map 1:1 between FUJITSU GLOVIA G2 and Epicor Prophet 21.
Complexity
BStandard
Timeline
6-10 weeks
Overview
FUJITSU GLOVIA G2 is a modular discrete manufacturing ERP with over 70 optional modules sold by CrescentOne under Constellation Software since Fujitsu's 2021 spin-off. Every GLOVIA G2 installation is unique depending on which modules were activated during implementation, so we begin discovery by enumerating every active module and any developer-added custom fields before we can build a migration map. Epicor ERP, and specifically Epicor Kinetic, is a cloud-native manufacturing ERP built for make-to-order and engineer-to-order environments with strong CPQ, production scheduling, and quality management. We migrate the transactional core: Item master and BOM structures, open and closed Work Orders, on-hand inventory with lot and serial data, open Sales and Purchase Orders, and Chart of Accounts with fiscal period balances. We do not migrate GLOVIA G2 workflows, automations, custom developer integrations, or IoT telemetry as these are non-portable platform configurations. Documents attached to GLOVIA G2 records migrate as file attachments to the corresponding Epicor records; custom developer fields require pre-creation in Epicor before any data loads.
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 FUJITSU GLOVIA G2 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.
FUJITSU GLOVIA G2
Item / Part
Epicor Prophet 21
Part
1:1GLOVIA G2 Item master records map to Epicor Part. The part number, description, unit of measure, and cost fields transfer directly. Revision levels in GLOVIA G2 correspond to Epicor PartRev records that we create during the Part import. On-hand quantity, lot numbers, and serial numbers migrate from GLOVIA G2 inventory records and land in Epicor PartBin with location-specific rows. If GLOVIA G2 uses lot costing or FIFO valuation, the lot cost values migrate as PartTran records rather than as a simple quantity update.
FUJITSU GLOVIA G2
Bill of Materials (BOM)
Epicor Prophet 21
PartRev + PartMtl
lossyGLOVIA G2 multi-level BOMs with by-products, co-products, and phantom BOMs map to Epicor PartRev (revision header) and PartMtl (material lines) tables. We sequence BOMs top-down by parent part number to preserve the multi-level structure during migration. Phantom BOMs require explicit PartRev.phantomBOMFlag configuration in Epicor. If GLOVIA G2 BOMs include alternate materials or alternate operations, we create corresponding PartMtl and PartOpr alternate records in Epicor. BOM revision dating from GLOVIA G2 migrates to Epicor PartRev with effective-from and effective-to dates set to preserve the revision history that manufacturing engineering relies on.
FUJITSU GLOVIA G2
Work Order / Production Order
Epicor Prophet 21
JobMtl + JobOper
1:1GLOVIA G2 Work Orders map to Epicor Jobs (JobHead, JobMtl, JobOper, PartTran). Open work orders migrate with full material allocations, operation sequences, labor hour estimates, and current status. We preserve the operation sequencing by mapping GLOVIA G2 operation steps to Epicor JobOper with the correct OpCode, LaborHrs, and BurdenHrs. Closed work orders migrate as Job records with a Closed status flag and complete PartTran history. Inspection results from GLOVIA G2 attach to Epicor JobOper inspection operation types.
FUJITSU GLOVIA G2
Customer / Account
Epicor Prophet 21
Customer
1:1GLOVIA G2 Customer records map to Epicor Customer with ship-to and bill-to addresses preserved as separate address records. Credit limits, payment terms, and sales territory assignments transfer to Epicor Customer fields. Contact sub-records migrate as Epicor Person records linked to the Customer. Where GLOVIA G2 co-installed CRM module is active, we also migrate communication history records as Epicor CustomerLog entries.
FUJITSU GLOVIA G2
Vendor / Supplier
Epicor Prophet 21
Supplier
1:1GLOVIA G2 Vendor records map to Epicor Supplier with procurement terms, lead times, approved supplier list assignments, and ASN data preserved. Multi-plant vendor assignments from GLOVIA G2 become separate SupplierPP records in Epicor per plant. Vendor contacts migrate as Epicor Person records linked to the Supplier.
FUJITSU GLOVIA G2
Sales Order
Epicor Prophet 21
OrderHed + OrderDtl
1:1Open Sales Orders from GLOVIA G2 migrate line-by-line to Epicor OrderHed (header) and OrderDtl (detail) records. We transfer pricing, discounts, scheduled ship dates, and order statuses. GLOVIA G2 custom order fields map to Epicor OrderHed character fields or UD columns, requiring pre-creation in Epicor before the order import. Released orders versus pending orders in GLOVIA G2 map to Epicor OrderHed.OrderHeld flag to preserve the release status that the warehouse team acts on.
FUJITSU GLOVIA G2
Purchase Order
Epicor Prophet 21
POHeader + PODetail
1:1Open Purchase Orders from GLOVIA G2 migrate to Epicor POHeader and PODetail. Vendor, order date, terms, and line items including part number, quantity, unit cost, and due date transfer directly. GLOVIA G2 custom PO fields require pre-creation of Epicor UD columns. Released versus pending status from GLOVIA G2 maps to Epicor POHeader APPROVED flag.
FUJITSU GLOVIA G2
General Ledger / Chart of Accounts
Epicor Prophet 21
GL Account + Ledger
1:1GLOVIA G2 Chart of Accounts structures map to Epicor GL Account with natural account segment preserved and any segment structures (company, division, department) mapped to Epicor's multi-segment account code format. Custom ledger types added by GLOVIA G2 developers require pre-creation of Epicor Ledger records before migration. Sub-ledger associations from GLOVIA G2 map to Epicor GL Account segments.
FUJITSU GLOVIA G2
Journal Entries / Fiscal Period Balances
Epicor Prophet 21
GLJrnDtl
1:1Open AP and AR sub-ledger records migrate as live Epicor GLJrnDtl entries. Closed fiscal periods in GLOVIA G2 are write-protected and cannot be re-posted; we extract the period balances as read-only historical records in Epicor GLJrnDtl with a closed period flag and deliver a reconciliation report for the customer's finance team to validate before the next fiscal period close. Custom journal entry types from GLOVIA G2 require pre-creation of Epicor Journal Codes.
FUJITSU GLOVIA G2
Inventory / Stock
Epicor Prophet 21
PartBin + PartLot
1:1On-hand quantities by location migrate from GLOVIA G2 to Epicor PartBin with the quantity, cost, and qty Bearing flags preserved. Lot numbers and serial numbers with FIFO or lot costing values transfer to Epicor PartLot records linked to the PartBin. If GLOVIA G2 tracks lot expiration dates, those migrate as PartLot.LotSuffixDate fields. Location assignments from GLOVIA G2 warehouse management module map to Epicor Warehse and Bin records with shelf and location codes preserved.
FUJITSU GLOVIA G2
Documents / Attachments
Epicor Prophet 21
DocumentReference
1:1GLOVIA G2 documents attached to items, work orders, and orders are exported via the Application Adapter file export and reattached to the corresponding Epicor records using Epicor's DocumentReference table. Document revision history and change descriptions transfer as DocumentRev records. We flag any unsupported attachment formats (non-standard GLOVIA G2 document types that Epicor cannot render) for manual retrieval from the GLOVIA G2 file store post-migration.
FUJITSU GLOVIA G2
Custom Objects / Developer Fields
Epicor Prophet 21
Custom Fields / UD Tables
lossyGLOVIA G2 implementations frequently add custom fields and developer objects via the Bus and Task Developer environment. We identify every non-standard field during discovery and pre-create corresponding Epicor Extended Properties or UD columns before any data load. Custom lookup relationships in GLOVIA G2 (such as a custom field linking an Order to a Project object) require Epicor UD table creation and foreign key configuration in Epicor's database. We deliver a written map of every custom field with its source GLOVIA G2 data type and the target Epicor field definition, for the customer's Epicor admin to review and confirm before import.
| FUJITSU GLOVIA G2 | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Item / Part | Part1:1 | Fully supported | |
| Bill of Materials (BOM) | PartRev + PartMtllossy | Fully supported | |
| Work Order / Production Order | JobMtl + JobOper1:1 | Fully supported | |
| Customer / Account | Customer1:1 | Fully supported | |
| Vendor / Supplier | Supplier1:1 | Fully supported | |
| Sales Order | OrderHed + OrderDtl1:1 | Fully supported | |
| Purchase Order | POHeader + PODetail1:1 | Fully supported | |
| General Ledger / Chart of Accounts | GL Account + Ledger1:1 | Fully supported | |
| Journal Entries / Fiscal Period Balances | GLJrnDtl1:1 | Fully supported | |
| Inventory / Stock | PartBin + PartLot1:1 | Fully supported | |
| Documents / Attachments | DocumentReference1:1 | Mapping required | |
| Custom Objects / Developer Fields | Custom Fields / UD Tableslossy | Mapping required |
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.
FUJITSU GLOVIA G2 gotchas
GLOVIA G2 rebranded to CrescentOne
Modular configuration creates unique per-instance schemas
On-premise deployments require direct database access
Historical closed periods are locked at migration time
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
Module and schema discovery
We audit the source GLOVIA G2 instance by enumerating every active module, all custom developer fields, the Chart of Accounts structure, open order volume, work order counts by status, inventory location count, and closed period date ranges. For on-premise GLOVIA G2 deployments behind the customer firewall, we coordinate secure read-only database access with the customer's IT team; for cloud-hosted instances, we use GLOVIA G2 Application Adapters and REST data endpoints. Discovery output is a written schema inventory that becomes the baseline for every subsequent mapping decision.
Epicor schema pre-creation
We provision the Epicor destination schema before any data migration begins. This includes creating PartRev revisions for all GLOVIA G2 items, setting PartRev.phantomBOMFlag and PartMtl alternate flags for phantom and alternate material BOMs, creating UD columns for GLOVIA G2 custom developer fields, provisioning GL Account structures matching the GLOVIA G2 Chart of Accounts segment layout, and creating Epicor Warehse and Bin records for every GLOVIA G2 inventory location. Epicor schema deployment runs in a Sandbox environment first for validation, then migrates to the production Epicor org.
BOM sequencing and parent-child resolution
We extract GLOVIA G2 multi-level BOMs top-down and sequence the parent-to-child relationships before any PartRev or PartMtl insert into Epicor. We build a dependency graph of all GLOVIA G2 items and BOMs so that parent revisions are created before material lines reference them. Phantom BOMs and alternate materials are flagged during extraction and set to the correct Epicor PartRev and PartMtl configuration flags during the Epicor load. BOM revision effective dates migrate as PartRev.EffectiveDate to preserve the engineering revision timeline.
Production migration in dependency order
We run production migration into Epicor in strict record-dependency order: GL Account and Ledger (foundational), Warehse and Bin (location infrastructure), Part (items without BOM materials first), PartBin and PartLot (inventory), Supplier and Customer (trading partners), PartRev and PartMtl (BOMs after Parts confirmed), JobHead with JobMtl and JobOper (work orders), POHeader and PODetail (purchase orders), OrderHed and OrderDtl (sales orders), then GLJrnDtl (journals and closed period balances as read-only). Documents attach after their parent records are confirmed in Epicor. Custom field data loads last, after UD columns are confirmed to exist.
GL reconciliation and closed period handoff
We deliver a GL reconciliation worksheet comparing GLOVIA G2 closed period balances to the archived Epicor GLJrnDtl records. Any unmatched account codes or balance discrepancies are flagged for the customer's finance team to investigate and post as correcting journal entries if needed. We do not modify locked closed periods in GLOVIA G2 or Epicor. We provide a written closed-period archive file from GLOVIA G2 in case the customer needs to reference the original closed-period data outside Epicor.
Cutover, document migration, and workflow inventory handoff
We freeze GLOVIA G2 write access during the final migration window, run a delta migration of any records modified during the window, then enable Epicor as the system of record. Document attachments from GLOVIA G2 are uploaded to Epicor DocumentReference against their parent records. We deliver a written inventory of every GLOVIA G2 workflow, automation, and custom integration that requires rebuild in Epicor. We support a one-week post-go-live window for reconciliation issues raised by the manufacturing and finance teams.
Platform deep dives
FUJITSU GLOVIA G2
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 FUJITSU GLOVIA G2 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
FUJITSU GLOVIA G2: Not publicly documented.
Data volume sensitivity
FUJITSU GLOVIA G2 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 FUJITSU GLOVIA G2 to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your FUJITSU GLOVIA G2 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 FUJITSU GLOVIA G2
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.