Migrate from Azuga Fleet to Pipedrive

Azuga vehicles map directly to Pipedrive Organizations. The Organization's Name field receives the Azuga vehicle_name. VIN, license plate, and vehicle status become custom fields on the Organization. Drivers assigned to the vehicle link to this Organization via the Person record's primary Organization relationship.

Azuga drivers map to Pipedrive People. The Person's Name, Email, and Phone fields pull from the driver's first name, last name, and contact details. Driver license number and safety score become custom fields on the Person record. The Person is linked to its primary Organization (the vehicle it drives most) via Pipedrive's Organization relationship.

Azuga trip records — structured events with start location, end location, distance, duration, fuel consumed, and driver score — map to Pipedrive Activities. Trip name and trip identifier become the Activity Subject. Start and end locations become custom fields; distance, duration, and fuel consumed are custom fields. The Activity is linked to the Driver (Person) and Vehicle (Organization) records. Pipedrive Activities support tasks, calls, meetings, and to-dos — trips use a custom Activity type designation.

Azuga alerts — speeding events, geofence violations, maintenance reminders, panic alerts — map to Pipedrive Activities with a custom 'alert' type designation. Alert type, severity level, trigger timestamp, and location coordinates become custom fields on the Activity. Each alert is linked to the relevant Vehicle (Organization) and, where a driver is assigned, the Driver (Person) record. Alert rules themselves cannot migrate and must be rebuilt as Pipedrive automations if needed.

Fuel purchase records from Azuga's fuel card integration become Pipedrive Activities attached to the Vehicle Organization. Fields mapped include transaction timestamp, fuel type, quantity, cost, and odometer at time of fill. These appear as Activity records on the vehicle's Organization timeline. The fuel card integration itself — connection to the card provider — does not migrate and must be re-established with Pipedrive's integration ecosystem or a middleware tool.

Azuga geofence definitions — name, polygon or radius coordinates, address, and active/inactive status — store as custom fields on the Vehicle Organization record. Geofence entry/exit events are captured as timestamped Activities linked to the Organization. Since Pipedrive has no native geofence model, the geofence polygon coordinates are stored as text fields; the boundary logic must be rebuilt in Pipedrive Automations or a mapping tool if geofence compliance is a business requirement.

Azuga vehicle properties that have no direct Pipedrive equivalent — vehicle_make, vehicle_model, vehicle_year, and VIN — require Pipedrive custom text fields on the Organization object before import. These fields are created during the pre-migration schema setup step. The VIN is stored as a custom text field for traceability and maintenance lookup. Year and make/model also map to custom text fields since Pipedrive Organizations have no native vehicle-specific fields.

Azuga driver safety scores — numeric or letter-grade assessments of driving behavior — migrate as a custom numeric field (Driver_Safety_Score__c) on the Person record in Pipedrive. Historical score trend data is preserved as a JSON-encoded string in a secondary custom field if Azuga exposes score history via the API. Pipedrive's reporting can then surface driver safety as a dimension on Person-level dashboards. Safety score thresholds and alerting rules do not migrate — those are fleet automation logic that must be rebuilt in Pipedrive Automations.

Azuga maintenance records — service type, date, cost, odometer at service, and notes — split across two Pipedrive constructs. The maintenance event becomes a completed Activity (type: task) on the Vehicle Organization's timeline, with service type and cost as custom fields. The current odometer reading updates a custom field (Current_Odometer__c) on the Organization so service-interval automations can trigger in Pipedrive. Maintenance schedules and automated reminders do not migrate — those require Pipedrive Automations to rebuild.

Azuga users and owners (fleet managers, dispatchers, admin users) are resolved by email match against Pipedrive user accounts. FlitStack AI flags any Azuga owner whose email has no corresponding Pipedrive user before migration commits — your team either creates the Pipedrive user first or assigns those records to a fallback Pipedrive user. No record lands without an assigned Pipedrive owner.

Azuga vehicle groups and driver tags map to Pipedrive Labels on Organization (for vehicles) and Person (for drivers) records. Labels are color-coded tags that exist independently per entity type in Pipedrive. A vehicle group named 'Service Fleet' becomes a Pipedrive Label 'Service Fleet' applied to the relevant Organization records. Label hierarchy and group membership rules do not migrate — those require manual recreation in Pipedrive.

Azuga reports and dashboards — safety score reports, fuel consumption reports, fleet utilization summaries — do not migrate to Pipedrive because Pipedrive's native reporting is designed for sales pipeline metrics, not fleet telematics. The underlying data (mileage, fuel, driver scores) is present in custom fields on Organization and Person records, and Pipedrive's custom reporting can reconstruct basic summaries. Complex Azuga reports with custom date ranges, vehicle group filters, and trend charts must be rebuilt as Pipedrive custom reports or exported to a BI tool.