ERP migration
Field-level mapping, validation, and rollback between FUJITSU GLOVIA G2 and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
FUJITSU GLOVIA G2
Source
Dolibarr ERP
Destination
Compatibility
9 of 13
objects map 1:1 between FUJITSU GLOVIA G2 and Dolibarr ERP.
Complexity
BStandard
Timeline
4-8 weeks
Overview
Moving from FUJITSU GLOVIA G2 to Dolibarr is a manufacturing-to-business-suite migration. GLOVIA G2 runs 70+ optional modules for discrete manufacturing environments and is typically deployed on-premise behind a customer firewall; Dolibarr is an open-source modular ERP and CRM built for small-to-mid-market businesses that activates only the modules a team needs. The architectural difference is significant: GLOVIA G2 is a purpose-built manufacturing ERP with deep BOM and shop-floor control, while Dolibarr covers financials, inventory, and CRM with a lighter manufacturing module. We begin every migration by enumerating every active GLOVIA G2 module and any developer-added custom fields, because no two installations share the same schema. We extract data via direct SQL access or Application Adapter file export, normalize GLOVIA G2 naming conventions, and load into Dolibarr's corresponding module structure. We flag open Work Orders and production orders as Dolibarr's manufacturing module does not replicate the full work-order lifecycle GLOVIA G2 provides. Workflows, Bus and Task Developer configurations, and RPA setups do not migrate; we deliver a written inventory of these for the customer's admin to rebuild in Dolibarr.
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 Dolibarr ERP, 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 / Product
Dolibarr ERP
Product
1:1GLOVIA G2 Item master records (part numbers, descriptions, UM, cost, revision levels) map to Dolibarr Product. The source item_type (M=mfg, P=purchased, S=stock) maps to Dolibarr type (0=product, 1=service). We extract cost from the Item Cost record and assign to Dolibarr's cost_price field; sell_price migrates from the Item Price table. Lot and serial number tracking migrates if Dolibarr's lot serial module is activated.
FUJITSU GLOVIA G2
Bill of Materials (BOM)
Dolibarr ERP
BOM (if manufacturing module active)
lossyMulti-level GLOVIA G2 BOMs (parent assemblies, components, by-products, co-products) map to Dolibarr BOM records with multi-level explosion done at migration time. We sequence BOMs top-down to preserve parent-child relationships; phantom BOMs flatten into their parent. If Dolibarr's manufacturing module is not activated, BOMs are exported as a structured CSV attached to the Product record and documented for manual configuration. Phantom and negative-quantity BOM lines require explicit notes in the migration map.
FUJITSU GLOVIA G2
Work Order / Production Order
Dolibarr ERP
Project or Manufacturing Order (if module active)
lossyOpen GLOVIA G2 Work Orders map to Dolibarr Project records with type=0 (internal project) when the manufacturing module is inactive. Closed work orders migrate as historical records with status=closed and operation history preserved as notes. Work order operation sequences, labor hours, and material allocations are exported as line-level detail and attached as structured notes to the Project because Dolibarr's manufacturing module does not natively replicate the full work-order routing found in GLOVIA G2. Customers requiring full work-order fidelity should evaluate Dolibarr's MRP module scope during scoping.
FUJITSU GLOVIA G2
Customer / Account
Dolibarr ERP
Third Party (type=customer)
1:1GLOVIA G2 Customer records (ship-to, bill-to addresses, credit limits, payment terms) map to Dolibarr Third Party with code prefix CUST. The customer name maps to nom, addresses map to address fields, and payment terms map to cond_reglement and mode_reglement. Credit limits migrate as references and are noted as manual thresholds to configure post-migration. Contact sub-records migrate as Dolibarr Contact objects linked via fk_soc.
FUJITSU GLOVIA G2
Vendor / Supplier
Dolibarr ERP
Third Party (type=supplier)
1:1GLOVIA G2 Vendor records (procurement terms, lead times, approved supplier lists) map to Dolibarr Third Party with code prefix SUPP. Multi-plant vendor assignments are stored as multiple Third Party records with a shared supplier group reference. ASN data migrates as notes on the Third Party record because Dolibarr does not have a native ASN module.
FUJITSU GLOVIA G2
Sales Order
Dolibarr ERP
Order (llx_commande)
1:1Open GLOVIA G2 Sales Orders migrate to Dolibarr Order with line items mapped from order detail records. Pricing, discounts, and scheduled ship dates transfer directly. GLOVIA G2 custom order fields map to Dolibarr extrafields where configured, or to structured notes for manual entry. Order status from GLOVIA G2 (DRAFT, OPEN, SHIPPED, CLOSED) maps to Dolibarr status (0,1,2,3). Closed orders migrate as historical records; cancellation reasons preserve as notes.
FUJITSU GLOVIA G2
Purchase Order
Dolibarr ERP
Supplier Order (llx_commande_fournisseur)
1:1Open GLOVIA G2 Purchase Orders map to Dolibarr Supplier Order with vendor resolved via the Third Party mapping. Line pricing, lead times, and delivery schedules transfer. GLOVIA G2 blanket PO structures split into individual Dolibarr Supplier Order lines at migration time. Closed POs migrate as historical records only; no re-posting is performed.
FUJITSU GLOVIA G2
General Ledger / Chart of Accounts
Dolibarr ERP
Accounting Account (llx_accounting_account)
1:1GLOVIA G2 Chart of Accounts structures migrate to Dolibarr Accounting. Account numbers, descriptions, and account types (A=asset, L=liability, R=revenue, E=expense) map directly. Sub-ledger control accounts link to the corresponding Third Party and Product records via fk_pcg_version. Closed fiscal period balances migrate as read-only period summary records; actual journal entry detail migrates only for open periods because locked periods cannot be re-posted in GLOVIA G2.
FUJITSU GLOVIA G2
Journal Entries / AP / AR
Dolibarr ERP
Bank Statement, Supplier Invoice, Customer Invoice
1:manyOpen AP and AR from GLOVIA G2 sub-ledgers migrate as Dolibarr Supplier Invoices and Customer Invoices respectively, with amounts, due dates, and payment terms preserved. Historical journal entries for open periods migrate as General Ledger entries; locked-period entries export as read-only reference records. Payment history migrates as payment records attached to the corresponding invoice.
FUJITSU GLOVIA G2
Inventory / Stock
Dolibarr ERP
Stock (llx_product_stock)
1:1On-hand quantities, warehouse locations, and lot/serial assignments migrate to Dolibarr Stock. FIFO and lot costing values preserve at the stock record level. Multi-warehouse configurations map to multiple warehouse records in Dolibarr with quantity allocated per warehouse. Inventory valuation migrates as a stock movement reference for audit.
FUJITSU GLOVIA G2
Document / Attachment
Dolibarr ERP
Document (linked to Product, Third Party, Order)
1:1GLOVIA G2 documents attached to Items, Work Orders, and Orders export via the Application Adapter file export or direct database retrieval. We reattach files to the corresponding Dolibarr records using the document management API. Unsupported attachment types (non-file-based attachments, links to external systems) are listed in the migration gap document for manual re-association.
FUJITSU GLOVIA G2
Custom Objects / Developer Fields
Dolibarr ERP
Extra fields (extrafields) per module
lossyEvery non-standard GLOVIA G2 field added via Bus and Task Developer is identified during discovery and documented. We create corresponding Dolibarr extrafields (text, int, datetime, select, checkbox types matched to GLOVIA G2 field types) in the appropriate Dolibarr module before migration. Complex GLOVIA G2 developer objects with cross-references map to Dolibarr Projects with structured data attached as notes when no native equivalent exists.
FUJITSU GLOVIA G2
Owner / User
Dolibarr ERP
User
1:1GLOVIA G2 users referenced on records (Orders, Work Orders, Contacts) map to Dolibarr User by login name or email match. We resolve fk_user_author and fk_user_modif references at migration time. Any GLOVIA G2 user without a matching Dolibarr User goes to a reconciliation queue for the customer's admin to provision before record import completes.
| FUJITSU GLOVIA G2 | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Item / Product | Product1:1 | Fully supported | |
| Bill of Materials (BOM) | BOM (if manufacturing module active)lossy | Fully supported | |
| Work Order / Production Order | Project or Manufacturing Order (if module active)lossy | Fully supported | |
| Customer / Account | Third Party (type=customer)1:1 | Fully supported | |
| Vendor / Supplier | Third Party (type=supplier)1:1 | Fully supported | |
| Sales Order | Order (llx_commande)1:1 | Fully supported | |
| Purchase Order | Supplier Order (llx_commande_fournisseur)1:1 | Fully supported | |
| General Ledger / Chart of Accounts | Accounting Account (llx_accounting_account)1:1 | Fully supported | |
| Journal Entries / AP / AR | Bank Statement, Supplier Invoice, Customer Invoice1:many | Fully supported | |
| Inventory / Stock | Stock (llx_product_stock)1:1 | Fully supported | |
| Document / Attachment | Document (linked to Product, Third Party, Order)1:1 | Fully supported | |
| Custom Objects / Developer Fields | Extra fields (extrafields) per modulelossy | Mapping required | |
| Owner / User | User1: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.
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
Dolibarr ERP gotchas
Foreign key constraint errors on cross-distribution database restore
SQL injection vulnerabilities in version 9.0.1
Custom fields stored as JSON in extraoptions require field-by-field deserialization
Decimal precision and rounding configuration affects price fields
No native iOS/Android app forces reliance on browser
Pair-specific challenges
Migration approach
Discovery and module enumeration
We audit the source GLOVIA G2 instance via Application Adapter documentation review, direct SQL schema inspection, and a customer interview covering which of the 70+ modules are active. We enumerate all custom objects and developer fields added via Bus and Task Developer, map them to Dolibarr equivalents, and identify any manufacturing capabilities (work orders, routing, co-products) that have no Dolibarr native equivalent. The discovery output is a written scope document, migration map, and a gap analysis listing records or functionality that will not migrate automatically.
Access provisioning and data extraction plan
We coordinate with the customer's IT team to establish secure read-only SQL access to the GLOVIA G2 database (SQL Server or Oracle) or to configure an Application Adapter file export run. For on-premise deployments behind a firewall, we use a time-boxed VPN connection and read-only database credentials scoped to the migration. We extract the full data set in parallel across module boundaries: Item master, BOM, Work Order, Customer, Vendor, Sales Order, Purchase Order, GL, Inventory, and custom objects. Extracted data is staged in an encrypted migration workspace.
Dolibarr configuration and schema deployment
We configure the destination Dolibarr instance: activate the required modules (Third Party, Product, BOM, Stock, Facture, Order, Supplier Order, Accounting, Project), create extrafields matching each non-standard GLOVIA G2 field, and set up warehouse and accounting chart structures. Multi-level BOMs and custom objects are set up before any record import because parent-child dependencies require the destination schema to be in place first. Dolibarr is deployed in a staging environment for validation before production.
Sandbox migration and reconciliation
We run a full migration into the Dolibarr staging instance using production-equivalent data volume. The customer's operations lead reconciles record counts against the GLOVIA G2 source (Items in, BOMs in, Work Orders in, Customers in, Vendors in, Orders in, Stock in, GL balances in) and spot-checks 25-50 records for field-level accuracy. Any mapping corrections, extrafield additions, or BOM sequencing issues are resolved in staging. Sign-off on the sandbox reconciliation is required before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order: Accounting Chart of Accounts (for account references), Third Parties (Customers then Vendors), Products with BOMs (Products first, BOMs second for parent reference), Stock snapshots, Sales Orders and Purchase Orders (with Third Party lookups resolved), Work Orders (as Project or Manufacturing Order records), GL open balances and AP/AR, and custom objects last. Each phase emits a row-count reconciliation report before the next phase begins. Delta runs capture any records modified during the migration window before cutover.
Cutover, validation, and inventory handoff
We freeze writes to GLOVIA G2 during cutover, run a final delta migration, then designate Dolibarr as the system of record. We validate GL trial balance reconciliation between GLOVIA G2 and Dolibarr, confirm open order and work order counts match, and verify inventory quantities at the warehouse level. We deliver the Bus and Task Developer configuration inventory and custom field gap document to the customer's admin. We support a one-week hypercare window for reconciliation issues. Workflows, RPA configurations, and Bus and Task Developer automations do not migrate; these require a separate admin rebuild or partner engagement.
Platform deep dives
FUJITSU GLOVIA G2
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. All 8 core objects map 1:1 between FUJITSU GLOVIA G2 and Dolibarr ERP.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across FUJITSU GLOVIA G2 and Dolibarr ERP.
Object compatibility
All 8 core objects map 1:1 between FUJITSU GLOVIA G2 and Dolibarr ERP.
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 Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your FUJITSU GLOVIA G2 to Dolibarr ERP 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 Dolibarr ERP
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.