Migrate from Digit to Dolibarr ERP

DIGIT's Citizen records from the PGR module map to Dolibarr Third Parties. We extract citizen name, mobile number, email, address, and the Citizen UUID as a custom external reference field (Ref_External) for reconciliation. Cross-module linkages (Citizen to Property in PT, Citizen to Trade Licence in TL) are preserved as notes on the Dolibarr Third Party record and documented in the handoff report. Citizens with no organisational identity (individual residents) are created as Dolibarr Contacts under a parent Third Party representing the citizen category.

DIGIT Property records contain owner details, assessment values, property boundaries, and billing histories. The property owner maps to a Dolibarr Third Party (same as the Citizen mapping above if the owner is also a DIGIT Citizen). The property assessment and billing registers map to Dolibarr Products representing demand types (property tax demand, water charge, etc.) and Invoice records for historical payment data. Active billing cycles can be represented as Dolibarr recurring invoices or as Project entries with billing milestones depending on the customer's post-migration workflow preference.

DIGIT Trade Licence records include business name, category, application status, and issuance history. The licence holder maps to a Dolibarr Third Party. The licence category and status map to Dolibarr Product (or service product) entries representing the licence type, with Contract records capturing issuance, renewal dates, and status history. Active licences map to open Contracts; expired licences map to closed Contracts with a note on the reason.

DIGIT PGR complaint records with workflow states, department assignments, and resolution tracking map to Dolibarr Projects (one Project per citizen complaint) with Task entries for each workflow step. The complaint status and department assignment map to the Project and Task status fields respectively. Attachments to complaints migrate as Dolibarr Project document attachments. Closed complaints become closed Projects with a Task timeline preserved for audit.

DIGIT FSM service requests (sanitation, drainage, desludging) map to Dolibarr Projects with Tasks representing each service step, routing action, and completion milestone. FSM assignment to employees maps to Dolibarr Task assignment to the corresponding User (mapped from DIGIT HRMS employee records). Vehicle and asset associations from FSM migrate as Project-level notes. Open FSM requests become active Dolibarr Projects; completed requests become closed Projects.

DIGIT HRMS employee records map to Dolibarr Users. We extract name, email, role designation, department, and leave balances. Role-permission mappings are deployment-specific in DIGIT and require manual validation in Dolibarr after migration because Dolibarr's permission model (module-level activation per user) differs from DIGIT's role-based access. Leave balance data migrates as a note on the User record; full HR module configuration (leave types, accrual rules) is documented for the customer's admin to configure in Dolibarr HR module.

DIGIT demand registers from PT (property tax billing) and FSM (service invoices) map to Dolibarr Invoice records. Each demand record becomes an Invoice with the demand type as the Invoice line description, the demand amount as the line amount, and the payment status mapped from DIGIT's demand status flag. Paid demands become Paid invoices; pending demands become Draft or Unpaid invoices. Historical demand records spanning multiple years migrate with their original billing period preserved in the Invoice description field.

DIGIT localisation files contain region-specific labels, business rule configurations, and module-specific settings. These do not have a direct Dolibarr equivalent. We extract and inventory every localisation file, document its purpose and contents, and provide a written configuration guide for the customer's admin to apply equivalent settings in Dolibarr's language pack system, document templates, and module configuration. Region-specific business rules (fee schedules, exemption criteria, boundary definitions) are documented for manual re-implementation in Dolibarr.

DIGIT PT module stores boundary definitions for jurisdictional areas, revenue circles, and administrative divisions. These are region-specific spatial and administrative records that Dolibarr does not natively model. We export boundary definitions as a reference dataset in the migration handoff package. The customer's admin configures equivalent administrative divisions using Dolibarr's address region fields and the CRM module's territory configuration if required.

DIGIT payment records linked to demand notices map to Dolibarr Bank Account entries with transaction lines recording the payment against the corresponding Invoice. The original demand notice reference becomes the Dolibarr transaction label for audit tracing. Payment mode, transaction date, and amount migrate directly. Cash, cheque, and online payment modes map to Dolibarr's payment method types.

DIGIT stores documents (property documents, licence certificates, complaint attachments, FSM photos) as file references in its document store. We export these files and attach them to the corresponding Dolibarr record using Dolibarr's native document management system. File naming preserves the DIGIT document reference so that the customer's team can trace any document back to its source. Large file batches are organised by module and record type in the export directory.

DIGIT property records carry boundary and administrative division references that determine jurisdiction for billing and service delivery. These are mapped to Dolibarr's Third Party address fields and Category tags. The customer's admin configures a Category taxonomy in Dolibarr representing the administrative hierarchy (state, district, circle, ward) so that reporting by jurisdiction remains possible in Dolibarr's reporting module.