CRM migration
Field-level mapping, validation, and rollback between Azuga Fleet and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Azuga Fleet
Source
Odoo CRM
Destination
Compatibility
11 of 11
objects map 1:1 between Azuga Fleet and Odoo CRM.
Complexity
BStandard
Timeline
48–72 hours
Overview
Azuga Fleet is a telematics-first platform built around vehicles, drivers, GPS trips, and safety scores. Its data model centers on physical assets and behavioral telemetry rather than traditional CRM concepts like leads or opportunities. Odoo CRM uses crm.lead (for both leads and opportunities), res.partner for contacts and companies, and fleet.vehicle for asset records, with no native driver-behavior scoring fields. FlitStack AI maps Azuga drivers to Odoo res.partner contacts with custom fields for safety scores and licensing, Azuga vehicles to Odoo fleet.vehicle records with trip history as activity logs, and Azuga geofence alerts to Odoo CRM activities linked to the relevant fleet vehicle. The migration runs via Azuga API v4 (OAuth 2.0, max 200 TPS) and Odoo's xmlrpc endpoint. Custom Azuga fields — such as driver score, fuel card ID, or SafetyCam status — are created as x_name custom fields on the corresponding Odoo model. Workflows, automations, driver rewards logic, and SafetyCam alert rules are not migrated; we export Azuga's rule definitions as JSON so your Odoo admin can rebuild them in Odoo's Studio automation tools. Activity timestamps, odometer readings, and geofence entry/exit times are preserved as custom datetime fields in Odoo for reporting continuity.
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 Azuga Fleet object lands in Odoo CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Azuga Fleet
Driver
Odoo CRM
res.partner (Contact)
1:1Azuga drivers map to Odoo res.partner contacts. Each driver's name, email, phone, license number, and driver_score migrate as standard fields plus custom fields. Multiple drivers per vehicle (common in commercial fleets) require res.partner records with a Many2many link back to the fleet.vehicle record.
Azuga Fleet
Vehicle
Odoo CRM
fleet.vehicle
1:1Azuga vehicles map directly to Odoo fleet.vehicle using license plate as the unique key. The odometer reading, vehicle make/model/year, and VIN migrate as standard fleet.vehicle fields. Current location (latitude/longitude) is stored as a custom char field since Odoo's default location field is text-based.
Azuga Fleet
Driver Score / Safety Score
Odoo CRM
fleet.vehicle (custom field Driver_Score__c)
1:1Azuga's driver_score is computed per driver per trip. We map the most-recent composite score to a custom float field on fleet.vehicle for quick dashboard visibility. Historical score progression is preserved as a JSON blob in a LongText custom field Score_History__c for compliance and trend reporting.
Azuga Fleet
Trip
Odoo CRM
crm.lead Activity + fleet.vehicle.log.services
1:1Azuga trips (start/end GPS points, distance, fuel consumed, idle time) are not native CRM activities. We map each trip as an Odoo crm.lead activity record with a custom Trip_Distance__c and Fuel_Used__c field, linked to the relevant fleet.vehicle. Long-trip vs short-trip classification is preserved as a stage name on the activity.
Azuga Fleet
Alert (speeding, hard braking, geofence)
Odoo CRM
crm.lead Activity
1:1Azuga alerts map to Odoo CRM activities with Type='Alert' and a custom Alert_Type__c picklist (speeding, hard_braking, geofence_entry, geofence_exit). Original alert timestamp and GPS coordinates are stored as custom datetime and char fields. Each alert activity is linked to the fleet.vehicle record so fleet managers see the full alert history on the vehicle form.
Azuga Fleet
Geofence
Odoo CRM
fleet.vehicle (custom geofence field) + crm.lead Activity
1:1Azuga geofences are geographic boundaries attached to vehicles. We create a custom geofence JSON field on fleet.vehicle storing name, polygon coordinates, and radius. Geofence entry/exit events migrate as Odoo CRM activities with type='geofence' so managers can filter and report on location events alongside other alerts.
Azuga Fleet
Equipment / Asset Tracker
Odoo CRM
stock.production.lot or product.product
1:1Azuga equipment trackers (non-vehicle assets) map to Odoo product.product as serialized inventory items. The tracker device ID, last-known GPS, and last-reported timestamp migrate as custom fields. If the Odoo Inventory app is not installed, equipment is stored as a custom model Azuga_Equipment with the same field structure.
Azuga Fleet
Fuel Card / Expense Log
Odoo CRM
fleet.vehicle (custom fields) + account.move.line
1:1Azuga fuel card transaction data is mapped as a custom fuel_log JSON field on fleet.vehicle for quick reference, and individual fuel expense lines are created in Odoo Accounting as account.move.line entries linked to the vehicle's analytic account for cost tracking.
Azuga Fleet
Maintenance / Service Record
Odoo CRM
fleet.vehicle.log.services
1:1Azuga maintenance records (service type, cost, date, provider) map directly to Odoo's fleet.vehicle.log.services model. Odometer at service time is preserved as the odometer field on the service log. If Azuga has multiple service records per vehicle, each creates a separate log.services entry in sequence.
Azuga Fleet
SafetyCam Status / Footage Reference
Odoo CRM
fleet.vehicle (custom fields)
1:1Azuga SafetyCam status (online, standby, offline) and last footage timestamp are stored as custom fields on fleet.vehicle (SafetyCam_Status__c, SafetyCam_Last_Footage_Date__c). The footage itself does not migrate — video files are outside Odoo's storage model. We provide a CSV export of SafetyCam footage references pointing to Azuga's CDN URLs for re-linkage if a custom video module is built.
Azuga Fleet
Group / Sub-Account
Odoo CRM
res.company
1:1Azuga supports multiple sub-accounts per organization. Each Azuga sub-account maps to an Odoo res.company record. Vehicle and driver assignments are scoped per company using Odoo's multi-company security rules. This mapping requires pre-migration confirmation of which Odoo companies correspond to which Azuga sub-accounts.
| Azuga Fleet | Odoo CRM | Compatibility | |
|---|---|---|---|
| Driver | res.partner (Contact)1:1 | Fully supported | |
| Vehicle | fleet.vehicle1:1 | Fully supported | |
| Driver Score / Safety Score | fleet.vehicle (custom field Driver_Score__c)1:1 | Fully supported | |
| Trip | crm.lead Activity + fleet.vehicle.log.services1:1 | Fully supported | |
| Alert (speeding, hard braking, geofence) | crm.lead Activity1:1 | Fully supported | |
| Geofence | fleet.vehicle (custom geofence field) + crm.lead Activity1:1 | Fully supported | |
| Equipment / Asset Tracker | stock.production.lot or product.product1:1 | Fully supported | |
| Fuel Card / Expense Log | fleet.vehicle (custom fields) + account.move.line1:1 | Fully supported | |
| Maintenance / Service Record | fleet.vehicle.log.services1:1 | Fully supported | |
| SafetyCam Status / Footage Reference | fleet.vehicle (custom fields)1:1 | Fully supported | |
| Group / Sub-Account | res.company1: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.
Azuga Fleet gotchas
API v1 deprecation with unannounced v4 sunset date
SafetyCam video files not accessible via API
Driver score algorithms differ across platforms
Per-vehicle pricing creates billing unit complexity
No documented bulk export for trip point logs
Odoo CRM gotchas
Odoo.sh version gating blocks assisted migrations from trial
Enterprise modules fail to install on Community after database restore
Custom module view inheritance breaks between Odoo major versions
Custom fields risk losing their application context on Community
API access for Community is gated behind the Custom Plan
Pair-specific challenges
Migration approach
Inventory Azuga API v4 objects and define Odoo custom field schema
We authenticate to Azuga API v4 using OAuth 2.0 credentials and run a discovery export across all accessible object types — vehicles, drivers, trips, alerts, equipment, and geofences — to capture record counts and field metadata. Simultaneously, we inspect the target Odoo database to identify existing fleet.vehicle fields, any installed OCA fleet extensions (field-service-fleet, fleet-maintenance), and the custom field slots available on res.partner and fleet.vehicle. We deliver a custom-field creation plan for Odoo before data begins moving so the schema is ready before first validation.
Resolve drivers to Odoo contacts and vehicles to fleet.vehicle records
We run a first-pass migration to create all fleet.vehicle records from Azuga vehicles using license_plate as the unique match key. Driver records resolve to res.partner contacts using email as the matching field — drivers without an email address in Azuga receive a generated placeholder email and are flagged for admin review. The driver-vehicle assignment table (driver_vehicle_map) is preserved in a custom junction model so no assignment history is lost. Vehicle-to-driver links are resolved after both object types exist to satisfy Odoo's Many2one foreign-key constraints.
Migrate trip history, alerts, and maintenance records in dependency order
Trip records require a valid fleet.vehicle ID before insertion, so trip migration runs after the vehicle pass. We chunk trip exports by vehicle using Azuga's API pagination (date range filters) and insert them as CRM lead activities linked to the resolved fleet.vehicle. Alert migration follows the same pattern — speeding, hard-braking, and geofence events become CRM activities with type='Alert' and custom fields for coordinates and severity. Maintenance records map to fleet.vehicle.log.services in a separate pass after the vehicle pass. Each pass is validated independently before the next begins.
Run a sample migration with field-level diff against a vehicle subset
A representative slice — typically 50–200 vehicles with their associated drivers, 90-day trip history, and the full alert set — migrates first. We generate a field-level diff comparing Azuga source values against the Odoo destination values for every mapped field including custom fields, alert types, and maintenance costs. You review the diff to confirm driver_score mapping, geofence coordinate formatting, and Odoo priority values before the full run commits. Any mapping corrections are applied to the migration script before the production pass.
Execute full migration with delta-pickup window and rollback readiness
The full migration runs against Odoo with a scoped read-access credential on Azuga — your team continues working in Azuga throughout the run. A delta-pickup window of 24–48 hours captures any new vehicles, drivers, trips, or alerts created or modified during the cutover. Our audit log records every insert, update, and skip operation. If reconciliation fails, one-click rollback reverts the Odoo database to its pre-migration state so the migration can be re-run with corrected mappings without data corruption.
Platform deep dives
Azuga Fleet
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. All 8 core objects map 1:1 between Azuga Fleet and Odoo CRM.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Azuga Fleet and Odoo CRM.
Object compatibility
All 8 core objects map 1:1 between Azuga Fleet and Odoo CRM.
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
Azuga Fleet: 200 TPS maximum (per-endpoint, per-module, and global limits documented).
Data volume sensitivity
Azuga Fleet doesn't expose a bulk API — REST + parallelization used for high-volume runs.
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 Azuga Fleet to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Azuga Fleet to Odoo CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Azuga Fleet
Other ways to arrive at Odoo CRM
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.