Migrate from Azuga Fleet to Mailchimp

Each Azuga driver with a valid email address maps to one Mailchimp contact. Name, email, phone, and address fields transfer directly. Drivers without email addresses are flagged for manual reconciliation before migration — Mailchimp requires a valid email for contact creation.

Azuga group hierarchies (departments, teams, fleet groupings) map to Mailchimp audiences or tags depending on structure. Single-level groups become tags within one Mailchimp audience. Multi-level hierarchies are flattened into a tag namespace (e.g., 'Fleet:North/Region:California') to preserve hierarchy without creating multiple audiences.

Azuga vehicles have no Mailchimp equivalent. We map vehicle license plate, make, model, year, VIN, and registration expiry as custom merge fields on the contact record so each driver contact carries their assigned vehicle's static properties. Active vehicle assignments are stored as Current_Vehicle_Plate__c and Current_Vehicle_VIN__c merge fields.

Azuga's N:1 vehicle-to-driver assignment model (one vehicle assigned to one primary driver) becomes a 'PrimaryDriver: {plate}' tag on the vehicle's contact record. Secondary assignments are stored as merge fields. If the same driver operates multiple vehicles, each vehicle gets its own tag on the same contact.

Azuga's driver_score (0–100 scale) and safety_score are captured as numeric merge fields on the Mailchimp contact. These are static at migration time — Mailchimp has no live scoring equivalent. We store score_snapshot_date__c alongside the value so you know when the snapshot was taken.

license_number, license_state, and license_expiry from Azuga map to Driver_License_Number__c, Driver_License_State__c, and License_Expiry_Date__c merge fields. These are compliance-adjacent properties that Mailchimp can store but cannot validate or alert on. These fields enable you to include license details in email segmentation, such as targeting drivers with licenses expiring within 90 days, but Mailchimp does not generate renewal reminders. You will need a separate compliance system to monitor expiration dates and trigger alerts.

Azuga fuel card transactions (fuel type, gallon amount, cost, station, transaction timestamp) have no Mailchimp equivalent. These records are exported to a CSV for your finance team and excluded from Mailchimp import. Marketing campaigns cannot act on fuel spend data.

Azuga trip records (start/end location, distance, duration, fuel consumed, route) are time-series GPS events. Mailchimp contacts have no trip or route concept. Trip summaries are exported to CSV; operational reporting requires a separate telematics platform post-migration. Exporting to CSV preserves the full trip history for audits or future telematics imports. Marketing segmentation cannot act on trip data directly.

Azuga alerts (speeding, hard braking, geofence violation, idle time, panic button) are telematics events with no Mailchimp analogue. These records are outside Mailchimp's data model. We export alert history to CSV and your team should maintain a telematics platform for safety event tracking.

Azuga geofences (named zones with entry/exit rules) are a spatial logic construct. Mailchimp has no geofence or location-based automation capability. Geofence configurations cannot transfer — they must be rebuilt in any telematics platform you retain alongside Mailchimp. We export geofence definitions to a CSV listing zone names, coordinates, radius, and entry/exit rules. Mailchimp supports zip-code segmentation but cannot trigger alerts on zone entry. Location-triggered campaigns will need a separate geofencing engine.

Next_service_due_date and last_service_date from Azuga map to Vehicle_Service_Due__c and Last_Service_Date__c merge fields on the contact. Full service history (work order details, parts replaced, cost) is outside Mailchimp's model and exported to CSV for fleet maintenance records. These fields let you create service reminder emails based on the due date, but Mailchimp cannot pull live mileage or diagnostic codes; dynamic alerts require an external trigger.

Azuga's FMCSA-registered ELD module and driver vehicle inspection reports (DVIR) are DOT-regulated compliance records. Mailchimp has no compliance or inspection capability. These records must remain in a certified ELD system — we export available logs to CSV and note the regulatory requirement for a separate compliant system.

Each driver record's Azuga API ID (uuid field from /drivers endpoint) is stored as Source_Azuga_ID__c on the Mailchimp contact for traceability, delta-run deduplication, and cross-reference if records need to be reconciled against future Azuga exports. The UUID persists if driver details change in Azuga, allowing you to match updates without relying on email or name matches. It enables trails and supports integration with reporting tools that reference the Azuga identifier.

Azuga's created_at and updated_at timestamps for driver records are stored as Azuga_Created_Date__c and Azuga_Updated_Date__c merge fields. Mailchimp's native Created_At timestamp reflects the import date, not the original Azuga record creation date — the custom fields preserve historical context. These fields are useful for segmenting contacts by age of record or for reporting on data age. They also allow you to filter records if you set up reconciliation against Azuga exports.