Migrate from Onpipeline to Salesforce Sales Cloud

Onpipeline Contacts map to Salesforce Lead if the contact represents an unqualified prospect or inbound inquiry, and to Salesforce Contact attached to an Account if the contact represents a qualified buyer or existing customer relationship. We determine the split during scoping by examining the Onpipeline Lifecycle Stage property (lead, customer, evangelist) and the presence of associated Deals. A closed-won Deal or a Lifecycle Stage of customer maps to Contact under an Account; all others map to Lead. The original Onpipeline Lifecycle Stage and any Tags are preserved in custom fields on the migrated Salesforce record for audit and segmentation.

Onpipeline Company records map directly to Salesforce Account. The Company domain or website becomes the Account Website field and is used as the dedupe key during bulk import. The Account must be inserted before any Contact import so that the AccountId Lookup relationship is satisfied at the moment of Contact upsert. Onpipeline allows a Contact to exist without a Company; those Contacts migrate as Leads without an AccountId and are flagged for manual Account assignment during UAT.

Onpipeline Deals map to Salesforce Opportunity. The Deal value, stage name, probability, and expected close date migrate to Opportunity Amount, StageName, Probability, and CloseDate. The Onpipeline Deal linked Contact resolves to the Salesforce Contact via email match; if the Contact migrated as a Lead rather than a Contact, we link the Opportunity to the Lead instead and flag it for conversion during UAT. Custom fields on Deal (Standard and Advanced plans) map to equivalent custom fields on Opportunity.

Onpipeline allows custom stage names and probabilities per pipeline. We capture the full stage hierarchy during discovery, then create a Salesforce Sales Process that whitelists the migrated stage names. Probability percentages from Onpipeline transfer to Salesforce StageProbability with rounding to the nearest whole number. If the customer uses multiple Onpipeline pipelines, we create separate Salesforce Record Types on Opportunity, each with its own Sales Process.

Onpipeline Events (calendar appointments) map to Salesforce Event with StartDateTime, EndDateTime, Subject, Location, and Description preserved. The assigned Onpipeline user resolves to the Salesforce User via email match and becomes the Event Owner. Attendee records from Onpipeline map to EventRelation records linking the Event to the related Contact, Lead, or Account. Onpipeline's user-scoped calendar model means each user has one calendar containing all Events; we preserve this by maintaining owner attribution on each Event record.

Onpipeline Tasks migrate to Salesforce Task with Subject, Status, Priority, ActivityDate, and Description preserved. The assigned Onpipeline user resolves to Salesforce OwnerId. Tasks linked to Deals carry the WhatId pointing to the migrated Opportunity; Tasks linked to Contacts carry the WhoId pointing to the migrated Lead or Contact. Completed status maps directly from Onpipeline completion flags.

Onpipeline Notes attached to Deals or Contacts migrate to Salesforce Note records. The Note body and creation timestamp transfer as-is. We link each Note to its parent record via ContentDocumentLink using the resolved Contact or Opportunity ID. Onpipeline files attached to Deals and Contacts migrate as ContentDocument records and are linked via ContentDocumentLink to preserve the association.

Onpipeline Product catalog records (name, SKU, price, stock quantity) map to Salesforce Product2. Stock quantity is preserved in a custom field on Product2 since Salesforce does not have native inventory management. Standard Pricebook entries are created during migration with the Onpipeline price as the ListPrice. The Product2 PricebookId is resolved at Line Item import time.

Onpipeline Quotes with line items, pricing, and e-signature status migrate to Salesforce Quote records. Quote header fields (quote date, expiration, total amount) map directly; each line item becomes an OpportunityLineItem attached to the parent Opportunity that was created from the Onpipeline Deal. E-signature status and signed document references are stored in a custom field since Salesforce Quote does not natively store e-sign metadata. The Quote is linked to the Contact and Opportunity via QuoteContactId and OpportunityId.

Onpipeline Invoice records (header, line items, payment status) require a destination mapping decision during scoping. Salesforce Quote is suitable for proposal-to-acceptance workflows; Salesforce Order is suitable for post-sale record keeping. We recommend creating a custom Invoice object in Salesforce with a Number, Date, Amount, Status, and Line Items custom field set, since neither native object is purpose-built for imported historical invoices. Recurring invoice automation configuration (Advanced plan) is noted as metadata only and does not transfer; automated billing requires a post-migration Revenue Cloud or subscription app setup.

Onpipeline Tags applied across Contacts, Companies, and Deals migrate to Salesforce as a multi-select picklist field on the relevant standard object, or as a custom Tag__c field if the customer uses a tag architecture that crosses object types. The customer selects the tag strategy during scoping. Tag frequency and usage counts are preserved in the field values.

Onpipeline recurring revenue schedules (subscription metadata: amount, frequency, start date, next billing date) migrate as records in a Salesforce custom object that we provision during schema design. Automated recurring invoice generation is a feature available only on Onpipeline's Advanced plan ($75/user/mo); Standard plan customers do not have this feature, and Advanced plan customers using this feature require a post-migration setup in Salesforce Revenue Cloud or a third-party subscription management tool. We preserve the schedule data as a record; the automation layer is out of migration scope.

Onpipeline Web Form definitions (field names, field types, submission routing) are documented as a written form schema that the customer's admin uses to rebuild in Salesforce Web-to-Lead, Experience Cloud Forms, or a third-party form tool. Form submission records migrate as Salesforce Leads with the original submission timestamp, form source, and field values preserved in custom fields. Any Zapier integration routing form data from Onpipeline requires reconfiguration in the Zapier account to point to Salesforce.

Onpipeline custom fields on Contacts, Companies, Deals, and Products migrate to Salesforce custom fields of equivalent data type. We extract the custom field schema during discovery, map Onpipeline field types (text, number, date, dropdown, checkbox) to Salesforce field types (Text, Number, Date, Picklist, Checkbox), provision the custom fields in the destination org before data import, and migrate all values in the same import phase as their parent object. Custom field API names preserve the Onpipeline field name with a migration-origin prefix for traceability.

Onpipeline Users assigned as Deal owners and activity assignees are resolved by email match against the destination Salesforce org User table. Any Onpipeline User without a matching Salesforce User is placed in a reconciliation queue and the customer's admin provisions the User before the production migration phase begins. OwnerId references on Opportunities, Events, and Tasks are resolved at migration time; orphaned records without a resolved OwnerId are flagged in the reconciliation report and held for manual assignment.

Onpipeline's per-user Calendar containing Events and Appointments maps directly to Salesforce Event records under the correct User owner. Each Onpipeline user has one calendar; Salesforce uses a shared Event model where Events are owned by a User but visible to other users based on sharing rules. We preserve the user-to-calendar ownership so the activity history remains accessible under each User. Team Leaders viewing team calendars in Onpipeline map to Salesforce sharing rules configured during schema design to grant team-calendar visibility.