Migrate from Vonigo to Salesforce Sales Cloud

Vonigo Client records split into Salesforce Account (company-level) and Contact (person-level) based on client type. Primary billing address maps to Account.BillingAddress; service address becomes Account.ShippingAddress. The client type (e.g., Residential, Commercial) is stored in a custom Client_Category__c pick-list on Account. Client contacts without a company name attach to a default placeholder Account to keep the relationship intact.

Vonigo stores primary contact name, email, and phone per client. These map directly to Salesforce Contact FirstName, LastName, Email, and Phone. Mobile and direct phone numbers migrate to Contact.MobilePhone. Multiple contacts per Vonigo client create multiple Salesforce Contact records linked to the same Account.

Vonigo Work Orders map to Salesforce Cases for service-desk-style tracking. Vonigo-specific fields (original work order ID, service type, technician assignment, line items, and signature status) migrate as custom fields on Case or as a custom Work_Order__c object with a lookup to Account/Contact. Case.Status maps from Vonigo work order status values using value mapping.

Vonigo line items (service type, quantity, unit cost, line total) have no direct Salesforce equivalent on Case. We create a custom Work_Order_Line_Item__c object with a lookup to Case, capturing Service_Type__c, Quantity__c, Unit_Cost__c, and Line_Total__c. The migration preserves the parent-child relationship by inserting line items after the parent Case record.

Vonigo Job records map to Salesforce Opportunities. Job name becomes Opportunity.Name; estimated or final amount becomes Opportunity.Amount; scheduled date becomes Opportunity.CloseDate. Vonigo Job status (Pending, Scheduled, In Progress, Completed, Cancelled) maps to a custom pick-list Job_Status__c on Opportunity since Salesforce Opportunity Stage has a different purpose.

Vonigo Estimates map to Salesforce Opportunities with IsWon=FALSE and a custom Is_Estimate__c flag to distinguish them from won opportunities. Estimate line items become OpportunityLineItems if the Salesforce org uses Products/Pricebooks; otherwise we create custom Estimate_Line_Item__c records. The original Vonigo estimate ID is preserved as Source_Estimate_ID__c for reconciliation, and the estimate total, date, and status are stored in custom fields on the Opportunity for reporting.

Vonigo Invoices have no direct Salesforce equivalent — Salesforce does not have a native Invoice object in Sales Cloud. We create a custom Invoice__c object with a lookup to Account, capturing Invoice_Number__c, Invoice_Date__c, Total_Amount__c, Balance_Due__c, and Status__c (Paid, Partial, Overdue). Vonigo payment records link to Invoice__c via a custom Payment__c object.

Vonigo Payment records (payment method, amount, date, transaction ID) do not exist as standard Salesforce objects. We create a custom Payment__c object with a lookup to Account and Invoice__c, capturing Payment_Method__c, Payment_Amount__c, Payment_Date__c, and Transaction_ID__c. Payment history is preserved for audit and reconciliation purposes.

Vonigo scheduling data (scheduled date/time window, technician assignment, arrival window) maps to custom fields on the Salesforce parent record. We add Scheduled_Date__c, Technician__c, Arrival_Window_Start__c, and Arrival_Window_End__c on Case or Opportunity. Note: Salesforce has no native scheduling engine — teams use Salesforce Maps, Calendars, or a third-party scheduling integration post-migration.

Vonigo user and technician records resolve by email match to Salesforce User records. Unmatched users are flagged as 'Unknown_Technician__c' and require manual Salesforce User provisioning or assignment to a fallback owner before migration. Role and permission sets do not migrate — those are destination-side configuration.

Vonigo custom objects (if configured in the client's Vonigo instance) map 1:1 to Salesforce custom objects. Vonigo's N:N relationship model for custom objects requires Salesforce custom junction objects to preserve the association graph. We document the relationship model during schema discovery and build junction objects where the source uses multi-valued associations.