Migrate from Perfectview to Salesforce Sales Cloud

PerfectView Relation is the central migration challenge. Each Relation conflates company and individual contact data into a single entity. We split each Relation into one Salesforce Account (using the company-level fields: company name, address, industry, phone) and one or more Contact records (using the individual-level fields: name, email, role, direct phone). The split rule uses Relation type, role fields, and address presence to determine placement. We preserve the original PerfectView Relation ID as a custom field pv_relation_id__c on both Account and Contact for audit. Relations without individual contact data become Account-only records. Relations with multiple role entries become one Account plus multiple Contacts linked via AccountId. This split logic must be validated against live data (sampling 50-100 records) before bulk migration to avoid duplicates at scale.

Activities in PerfectView (calls, emails, meetings, tasks) are well-structured with timestamps and owner references. We migrate them as Salesforce Task and Event objects linked to the parent Account or Contact via WhatId and WhoId lookups. Call activities map to Task with TaskSubtype=Call and duration in CallDurationInSeconds. Meeting activities map to Salesforce Event with StartDateTime, EndDateTime, and Location preserved. Email activities map to Salesforce EmailMessage linked to a Task activity record. Activity ordering is preserved by setting ActivityDate to the original PerfectView timestamp. We use the Salesforce Bulk API 2.0 for large activity volumes with batch chunking and exponential backoff.

PerfectView Cases (support tickets, complaint management) map to Salesforce Case with Case Status, Priority, and Description preserved. Case conversation history migrates as EmailMessage records linked to the parent Case. The original case number is stored in a custom field pv_case_number__c for reference. If PerfectView uses a Case pipeline with stages, we map them to Salesforce Case Record Types and Status values during schema design. Relation-to-Account links are resolved at migration time using the split-rule output.

Documents stored in PerfectView migrate to Salesforce ContentDocument with file metadata (filename, size, mime type, upload date) preserved. Document links to parent Relation records are resolved to Account or Contact ContentDocumentLinks during migration. We retrieve documents via API where enabled, falling back to the UI export for bulk downloads. PDFs and attachments transfer as binary blobs; document-specific metadata (custom PerfectView document fields) migrate as ContentVersion custom fields. Note that PerfectView document folder structure does not map to Salesforce library structure; we store folder context in a custom field if needed.

Lead tracking in PerfectView may be implemented as a Relation lifecycle stage rather than a distinct object. We identify Lead status values during discovery and map them to Salesforce Lead with LeadSource, Status, and any custom fields preserved. If the PerfectView Lead is actually a Relation at a specific lifecycle stage, we create a Salesforce Lead record using the Relation data and preserve the original lifecycle value in a custom field pv_lifecycle_stage__c for reconciliation against the Contact records created from the same Relations.

Quote and pricing data from the PerfectView Sales module migrates to Salesforce Quote. Quote line items, pricing, and QuoteStatus transfer directly. Quote-to-Relation links are resolved to Account during the mapping phase. Signed Quote PDFs and e-signature documents migrate as ContentDocument attached to the Quote. Quote numbers may require renumbering if PerfectView uses a non-sequential format incompatible with Salesforce's numbering conventions; we flag this during discovery.

Billing records from PerfectView's invoicing module migrate with line items and payment status. Invoice numbers may require renumbering in the destination system if they conflict with Salesforce's invoice numbering rules or existing sequences. We assess whether the destination org uses the standard Salesforce Invoice object (Professional+ with Finance and Revenue Automation) or a custom invoice object during scoping. If Salesforce Invoice is not available in the destination edition, we create a custom object pv_invoice__c with equivalent fields.

PerfectView user records and owner assignments on records migrate directly. We resolve PerfectView owner references by matching email against the destination Salesforce User table. Owner-to-record links are preserved in the mapping file and reassigned to matching users in Salesforce. Any PerfectView Owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive PerfectView users are mapped to inactive Salesforce users to preserve historical assignment context.

PerfectView custom fields added to Relations must be split alongside the standard Relation-to-Account/Contact migration. We discover all custom field definitions during the discovery phase, classify each as a company-level field (mapping to Account) or individual-level field (mapping to Contact), and create equivalent custom fields in Salesforce with matching data types. The mapping is validated during the sandbox migration before production import. Custom field order and grouping on page layouts are documented separately for the customer's admin to configure post-migration.

PerfectView does not expose workflow rules, trigger conditions, or automated sequences through any export mechanism. We do not migrate workflows as code. During the discovery phase we document every active workflow: its trigger, conditions, actions, and assigned owner. We deliver a written workflow inventory with a recommended Salesforce Flow equivalent for each item. The customer's admin or a Salesforce partner rebuilds the automations post-migration. Workflows that trigger on Relation lifecycle stages require the split-rule output to be stable before the rebuild can be designed.

PerfectView stores company data inside Relations rather than as standalone Company records. We identify company fields within Relation records and reconstruct standalone Account objects. If standalone Company records do exist in the customer's PerfectView instance, we treat them as top-level Relations and create Accounts directly without the split. We flag any Relation records that lack company-level fields during discovery so that these records are handled as Contact-only without an orphaned Account.

Contact details (name, email, phone, role) live within Relations. We extract contact-specific fields and create individual Contact records linked to the parent Account. For Relations containing multiple contact individuals (multiple roles per Relation), we create one Contact per individual, all pointing to the same AccountId resolved from the parent Relation. Role type determines Contact title and department mapping. If a Relation has only company-level data and no individual contacts, no Contact record is created for that Relation.