Migrate from Vorex to Salesforce Service Cloud

Vorex Client records map to Salesforce Contact. We export client name, email, phone, address, and account manager assignment via the V2 API /clients endpoint. In Salesforce, we resolve the Contact to an Account via domain-based matching or an explicit Account lookup the customer provides during scoping. Vorex Client records that represent organizations rather than individuals may instead map to Account with the contact data moved to a primary Contact on that Account.

Vorex Company records store business name, industry, size, and primary contact link. They map directly to Salesforce Account. If the customer has both Client and Company records representing the same entity, we deduplicate during scoping and map to a single Account with the Client data attached as a primary Contact. Account is created before any Contact import so the AccountId lookup is satisfied at insert time.

Vorex Tickets map to Salesforce Case as the primary service desk object migration. We export via /tickets with status, priority, assigned technician, requester contact, and all timestamps. In Salesforce, Ticket priority maps to Case Priority, Ticket status maps to Case Status (configured as a Status field on the Case Record Type), and the Vorex requester resolves to a Contact Lookup on the Case via email matching.

Project records are the most complex migration object because Vorex project date fields are documented as unreliable. Before any Project export, we re-profile every record to detect start_date exceeding end_date, null dates on active projects, and milestone date inconsistencies. Projects with clean dates map to Salesforce Case (if the customer treats projects as service engagements) or a custom Project__c object. Projects with corrupted dates are flagged for manual review before we commit to the migration mapping. QuickBooks sync flags on project financial fields are stripped during transformation.

Time Entries export cleanly via the V2 API with billable/non-billable flags, labor rates, owner assignment, and associated project or ticket references. We map to Salesforce Task with a custom Billable__c checkbox, Rate__c currency field, and a custom TimeEntrySource__c field set to 'Vorex' for audit traceability. The WhatId on Task links to the parent Case or Project__c record. Billing rate and multiplier are preserved as separate fields rather than merged into duration.

Expense records map to Salesforce Task with custom fields for ExpenseType__c, Amount__c (currency), ReceiptURL__c, and ExpenseDate__c. We flag any expense entries linked to inactive Vorex employees during scoping and hold them in a reconciliation queue. Expense category maps to a custom picklist or text field on the destination Task. Attachment references (receipt URLs) migrate as separate ContentDocument records linked via ContentDocumentLink.

Vorex Invoices carry line items, tax codes, and QuickBooks sync flags that vary by tenant configuration. Salesforce has no native Invoice object in standard Service Cloud. We map Invoice headers and line items to a custom VorexInvoice__c object with InvoiceNumber__c, InvoiceDate__c, TotalAmount__c, and QB_SyncFlag__c stripped of QB-specific GL references. If the customer uses Salesforce Opportunities for project billing, invoice line items may alternatively map to OpportunityLineItem. The customer chooses the strategy during scoping.

Vorex User and technician records export with role, email, active/inactive status, and team assignment. We match by email against the Salesforce destination org's User table. Any Vorex user without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import. Inactive Vorex users migrate as inactive Salesforce Users so that OwnerId references on historical records remain valid.

Vorex supports custom fields on Tickets, Projects, and Clients. The V2 API exposes them inconsistently across tenants: some show custom fields as flat key-value pairs, others nest them under a custom_properties object. We normalize both formats during extraction. Each Vorex custom field maps to a Salesforce custom field of equivalent type (text, number, date, picklist) created in the destination org before migration. We preserve the Vorex field label in a custom field description for admin reference.

Ticket and project attachments in Vorex are referenced by URL in the V2 API rather than streamed directly. We extract attachment URLs and re-fetch them if the destination Salesforce org supports file migration via the ContentVersion API. We upload each file as a ContentVersion record and link it via ContentDocumentLink to the parent Case or Project__c record. If a Vorex attachment URL returns a 404 or auth failure, we log it and flag it for the customer's admin to restore manually post-migration.

Vorex stores a primary contact link on Company records and a company assignment on Client records. During scoping we ask the customer whether their Vorex data has a clean Client-Company split or whether some records are duplicates. We apply a deduplication rule based on domain or explicit customer guidance, then build Account-Contact relationships in Salesforce using the resolved primary contact as the Contact record with a primary flag on the Account.