Migrate from Vortex Field Software to Odoo CRM

Vortex stores customer contacts with name, email, phone, and address fields. Odoo's res.partner model handles both contact and company roles via the type field. Migrated as type='contact' with the source Vortex contact_id preserved in a custom x_source_vortex_id Char field for traceability. The original create date is stored in x_original_create_date datetime to preserve the exact timestamp from Vortex.

Vortex companies (organizations with multiple sites and contacts) map directly to res.partner with type='company'. The parent_id field on child contacts references the migrated company record. If Vortex stores a company hierarchy, parent_company_id maps to Odoo's parent_id on res.partner. All original company identifiers are preserved in x_source_vortex_company_id for reference.

Vortex work orders are the central entity — linking a technician, an asset, a site/location, and a service type. Odoo has no field-service work order object; project.task is the closest fit. We create a project per Vortex service category (or a single 'Field Service' project) and map each work order to a task. A custom Work_Order_Number__c field preserves the original Vortex identifier.

Vortex assets store serial number, model, install location, and customer link. Odoo's maintenance.equipment model holds name, serial_no, maintenance_team_id, and location. A custom Asset_ID__c field references the original Vortex asset ID for traceability. The equipment is linked to the migrated res.partner (customer) via the partner_id field.

Vortex technicians (service staff) map to Odoo res.users as system logins, with hr.employee records for HR-specific data like department and manager. Owner resolution on work orders uses the email match between Vortex technician email and the migrated res.users email field. Unmatched technicians are flagged before migration.

Vortex stores completed work order history with timestamps, descriptions, and parts used. Odoo maintenance.request models a maintenance ticket or service log on an equipment record. Each service history entry becomes a maintenance.request linked to the migrated maintenance.equipment and the customer res.partner.

Vortex sites or locations store physical addresses linked to companies and assets. In Odoo, addresses are stored on res.partner records (the contact or company record) rather than as separate objects. The site name becomes a contact name on the parent company partner with type='delivery' or 'other'.

Vortex custom properties on work orders — such as service type codes, priority tiers, or billing flags — require Odoo Studio configuration or direct x_ field creation on project.task. FlitStack delivers a field creation plan with the exact field names, types, and pick-list values derived from the Vortex schema export.

Vortex asset custom fields (warranty period, contract type, installation date) need equivalent custom fields on maintenance.equipment in Odoo. Custom field creation is scoped to the Custom plan or direct database x_ field addition — FlitStack specifies the exact field definitions in the migration plan.

Vortex file attachments on work orders and assets are downloaded and re-uploaded to Odoo's ir.attachment table, linked to the migrated project.task or maintenance.equipment record. File size limits follow Odoo's document attachment limits; large files may require Odoo document storage configuration.

Vortex dispatch board logic — route optimization, time-slot assignment, technician availability windows — has no native Odoo equivalent in the standard CRM or Project modules. This logic cannot migrate. FlitStack exports the scheduling parameters (time windows, territory assignments) as a CSV rebuild reference for Odoo Project resource calendars or a third-party scheduling add-on.