Migrate from Giva eHelpDesk to Odoo CRM

Giva customers map directly to Odoo res.partner records. The partner's type field (company vs. individual) determines whether it is created as a company or individual contact. Giva contact records with no associated customer require a separate res.partner of type 'individual'.

Giva service requests become Odoo crm.lead records. The Giva status field determines the Odoo lead_type: 'New' and 'Open' requests land as type 'lead'; 'Resolved' or 'Closed' requests with a linked customer become type 'opportunity'. Priority, request type, and category are stored as custom fields on crm.lead.

Giva priority levels (Low, Medium, High, Critical) have no native Odoo equivalent on crm.lead. We create a selection custom field (Priority__c) in Odoo Studio before import and preserve exact Giva priority values. The custom field uses the same selection options as Giva to maintain triage continuity in Odoo's lead list view.

Giva request types (Incident, Service Request, Problem) are preserved as a custom selection field on crm.lead (Request_Type__c) since Odoo's default crm.lead model does not carry a request-type property. This ensures the original categorization survives the migration and remains available for filtering and reporting in Odoo.

Giva request categories translate to Odoo tags on crm.lead. Each unique Giva category becomes a tag in Odoo. Tags are created during the pre-migration schema setup phase and linked during import. This mapping allows your team to filter leads by the original Giva category without requiring custom field creation.

Odoo has no native knowledge-base article model in the base CRM module. Articles are migrated as Odoo Documents records (documents.document) with title, content, and source URL preserved. Access-control lists from Giva cannot be translated directly and require manual Odoo permission-group assignment post-migration.

Giva file attachments on service requests are imported as ir_attachment records linked to the corresponding crm.lead via res_model and res_id. Large files are chunked to respect Odoo's attachment size limits. Original filenames and MIME types are preserved. Binary content is decoded from base64 during import to populate Odoo's datas field directly.

Giva custom fields (SLA timers, health scores, compliance flags) are created in Odoo Studio as matching field types before import. Selection-type custom fields in Giva become Odoo selection fields; numeric fields become float or integer; text fields become char or text.

Giva users are resolved against Odoo res.users by email address match. Unmatched technicians are flagged pre-migration — you either create their Odoo user account first or assign their records to a fallback user. Deactivated Giva users are preserved as a custom lookup field rather than active Odoo users.

Odoo Community lacks a native SLA tracking module for CRM. SLA agreement names, response-time targets, and breach flags from Giva are stored as custom fields on crm.lead (SLA_Name__c, SLA_Response_Hours__c). Odoo Enterprise add-ons can provide native SLA tracking if you upgrade.

Giva parent-child company relationships map to res.partner.parent_id in Odoo. Parent companies must be migrated first to avoid circular-reference errors. FlitStack flags any circular hierarchy in the Giva data before import order is finalized. This ensures parent_id links resolve correctly during the res.partner batch import phase.

Giva health-score ratings have no Odoo CRM equivalent. The score is stored as a custom float field (Health_Score__c) on res.partner so it remains visible in Odoo's partner form view. The scoring model itself needs to be re-implemented in Odoo's automation or custom logic post-migration.