Migrate from Vorex to HubSpot Service Hub

Vorex Tickets map directly to HubSpot Service Hub Tickets with status, priority, assigned technician, requester contact, and timestamps. The Vortex ticket_id becomes a custom field vortex_ticket_id__c for cross-reference. Vorex custom fields on tickets expose inconsistently in the V2 API (flat key-value pairs in some tenants, nested under custom_properties in others); we normalize both formats during extraction and map them to HubSpot custom ticket properties. Ticket attachments are referenced by URL in the V2 API; we re-fetch them and attach them to the migrated HubSpot Ticket as file uploads if the HubSpot subscription supports the storage limit, or log attachment URLs for the customer's admin to restore manually.

Vorex Client records map to HubSpot Contacts with name, email, phone, address, and account manager assignment. Client-level custom fields migrate to HubSpot Contact properties. If the customer uses Vorex Clients as both individual requesters and organizational entities, we discuss the split preference during scoping: each Client becomes a standalone Contact, or Clients with a business name pattern are mapped to HubSpot Companies with the individual as a Contact linked to that Company.

Vorex Company records (business name, industry, size, primary contact link) map to HubSpot Companies. The Company name is the dedupe key during import to prevent duplicate Companies if the customer also migrated Clients that resolve to the same business entity. Company-level custom fields map to HubSpot Company properties.

Vorex Projects map to HubSpot Deals by default, with the project name as Deal name, start_date and end_date mapped to closedate and a custom project_start__c date field, and estimated budget mapped to amount. We flag any Vorex Project where start_date exceeds end_date or where date fields are null on active projects; these records are reconciled during the pre-flight re-profile phase before migration rather than carried forward with corrupted date logic. If the customer has complex project hierarchies or milestone structures that exceed Deal field capacity, we recommend a HubSpot Custom Object (requires Enterprise tier) and deploy the schema before migration. QuickBooks sync flags on Projects are stripped during transformation.

Vorex Time Entries export cleanly via the V2 API with billable/non-billable flags, labor rates, owner assignment, and associated project or ticket references. We preserve the billing rate and multiplier as separate custom fields on the migrated engagement record. Time Entries link to the parent Vorex Project (mapped to a HubSpot Deal) and the assigned technician (mapped to a HubSpot User). If the customer requires time entry reporting inside HubSpot, we recommend a Custom Object for Time Entries rather than Notes, since Custom Objects support more flexible reporting filters.

Vorex Expense records (expense type, amount, date, receipt attachment reference, owner) map to a HubSpot Custom Object (Expense) for customers who need expense tracking inside HubSpot, or to Deal Line Items on the associated Project-Deal for customers who consolidate project financials on the Deal object. We flag any Expense linked to an inactive Vorex employee for manual reconciliation before migration. Receipt attachment URLs are extracted and re-uploaded to HubSpot file storage if within storage limits.

Vorex Invoice records carry line items, tax codes, and QuickBooks sync flags that vary by tenant configuration. We export invoice headers and line items to a HubSpot Custom Object (Invoice) with fields for invoice_number, invoice_date, total_amount, tax_amount, and line_items as a JSON blob in a long-text field. All QB-specific metadata (GL account references, sync_error flags, external QB invoice IDs) is stripped during transformation and logged in the reconciliation report for the customer's admin to review; these fields have no equivalent in HubSpot and cannot be imported. If the customer is leaving QuickBooks integration, all QB-linked invoices require manual reconciliation post-migration.

Vorex User and technician records (role, email, active/inactive status, team assignment) map to HubSpot Users by email match. We resolve Vorex users to HubSpot users during migration scoping; any Vorex user without a matching HubSpot User goes to a reconciliation queue for the customer's HubSpot admin to provision before record import resumes. Inactive Vorex users are migrated as inactive HubSpot Users if the customer wants to preserve historical assignment, or omitted from migration if they represent only abandoned accounts.

Vorex custom fields on tickets, projects, and clients expose inconsistently in the V2 API. We run a pre-flight API introspection on each tenant to detect whether custom fields appear as flat key-value pairs or nested under a custom_properties object, then normalize both formats before mapping to HubSpot. Ticket custom properties migrate to HubSpot custom ticket properties. Project and client custom fields migrate to custom properties on Deal or Contact, or to a Custom Object field if the structure is too complex for a flat property. Custom field data types are preserved as closely as possible: text to text, number to number, date to date, checkbox to single-checkbox.

Vorex ticket and project attachments are referenced by URL in the V2 API rather than streamed directly. We extract attachment URLs and attempt to re-fetch and upload them to HubSpot file storage, attaching them to the parent Ticket or Deal record via the HubSpot file API. If the customer's HubSpot subscription has insufficient file storage, or if an attachment URL returns a 403 or 404, we log the attachment reference in the reconciliation report with the original URL so the customer's admin can restore manually. We do not migrate inline images embedded in ticket descriptions or notes; this is a known HubSpot import limitation and we flag it in the pre-migration report.

QuickBooks sync metadata embedded in Vorex Invoice and Project records (QB-specific GL account references, sync_error flags, external QB invoice IDs, QB sync status timestamps) has no equivalent in HubSpot and is stripped during transformation. We log every stripped QB field value in the reconciliation report so the customer's admin can review what was removed. If the customer is moving away from QuickBooks entirely, we recommend a post-migration reconciliation session to validate that no financial data was inadvertently dropped. If the customer intends to maintain QuickBooks alongside HubSpot, they configure a new QuickBooks-to-HubSpot integration post-migration without carrying forward the corrupted Vorex sync artifacts.

Vorex ticket status and priority values map to HubSpot Ticket pipeline stages and priority values. We configure the HubSpot Ticket pipeline before migration to match the Vorex ticket workflow: status values become Ticket status values, priority values (low, medium, high, urgent) map to HubSpot priority, and any custom ticket type or category field becomes a HubSpot custom property. Ticket pipeline configuration happens in HubSpot before migration begins so that incoming migrated tickets land in the correct stage.