Migrate from Vortex Field Software to HubSpot

Vortex stores customer name and email inside work-order records. We extract these into standalone HubSpot Contacts. Multiple work orders referencing the same customer name are deduplicated by email match and consolidated into one HubSpot contact record. The email address serves as the primary identifier, ensuring that all interactions for the same customer are linked to a single contact profile in HubSpot.

Email is the primary deduplication key across Vortex work orders. If a customer appears in multiple work orders with different email spellings, all variants are preserved as alternate email addresses on the HubSpot Contact record. This approach ensures that each contact retains all email variations, allowing your team to see every communication history associated with the customer.

Phone numbers from Vortex work orders map directly to HubSpot's phone contact property. Mobile and landline variants are stored in the same field; no type split is available at migration time. If you need separate handling for mobile vs. landline numbers, you can create custom properties post-migration to capture that distinction.

Vortex site records carry an address, city, state, and postal code. These merge into a HubSpot Company record for the service location, with the address also copied to the Contact record for quick reference in the field technician mobile view.

Work orders become HubSpot Deals (representing the service engagement) with a linked custom object (Service_Order__c) carrying FSM-specific fields: service_type, priority, technician, scheduled_date, actual_start, actual_end, and resolution_status. This split preserves Vortex work-order richness without overloading the standard Deal schema. This ensures that all FSM-specific details are searchable and reportable within HubSpot's native tools.

Vortex status values (Scheduled, In Progress, On Hold, Completed, Cancelled) map to HubSpot Deal stage values via a value-by-value mapping table. Teams choose the target pipeline and stage names during scoping so the mapping is approved before migration runs. If your workflow requires additional stages, they can be added to the mapping during the planning phase.

Vortex work-order line items (parts used, labor hours, materials) migrate as HubSpot Deal Line Items attached to the migrated Deal. Each line item carries description, quantity, unit price, and a reference back to the source work-order line ID for auditability.

Vortex assets are first-class objects with serial number, model, install date, and customer linkage. We migrate these to a HubSpot custom object named Asset__c. Parent-child asset hierarchies are preserved using a self-referencing Asset__c.Parent_Asset__c lookup field. Each asset record also retains its original Vortex ID in a custom field for traceability and future integrations.

The Vortex link between an asset and its customer (the person who owns or manages the asset) maps to a lookup field on Asset__c pointing to the migrated HubSpot Contact record. Unassigned assets link to a placeholder contact record. This ensures that asset ownership is visible in HubSpot reports and can be used in segmentation.

Vortex technician records — name, phone, email, certifications, and home base — migrate as HubSpot Contacts marked as internal staff (using the is-contact role or a Staff_Member__c boolean). These contacts are used in Deal assignments and Service_Order__c technician lookups but excluded from marketing contact billing.

Vortex attachment URLs (photos, signatures, scanned documents) are downloaded and re-uploaded to HubSpot Files, then linked to the target Deal or Asset__c record. The original Vortex URL is stored in a Source_Attachment_URL__c field for audit reference. Inline images in notes are extracted and rehosted.

Vortex service history entries (visit notes, status changes, technician comments) migrate as HubSpot engagement timeline entries on the linked Contact record. Timestamps, technician name, and the original note text are preserved. Complex multi-line service narratives are stored as a custom long-text field on the Service_Order__c object.

Vortex stores recurring-service rules and dispatch logic as configuration data. HubSpot has no native scheduling engine. We export the rule definitions as a structured JSON file your team uses to configure HubSpot Workflows or a third-party FSM integration post-migration. The exported JSON includes rule triggers, conditions, and actions, serving as a blueprint for rebuilding the logic in HubSpot.