Migrate from Visionary to Salesforce Sales Cloud

Visionary contact records map directly to Salesforce Contacts. Most fields (name, email, phone, title) translate 1:1. The Contact requires an AccountId lookup to an Account record—Visionary contacts with a primary company association resolve to that Account; contacts without a company link get attached to a default 'Unassigned Accounts' record or can be held for manual Account creation before the migration commits.

If Visionary stores unqualified prospects alongside contacts, those records split into Salesforce Leads. FlitStack applies a routing rule: records with a status field value indicating 'prospect' or 'unqualified' land as Salesforce Leads; records marked as 'customer' or with a closed-won deal association land as Salesforce Contacts. Your team specifies the split criteria during migration planning.

Visionary company records map to Salesforce Accounts. Field-level mappings include Name, Website (domain), Industry pick-list, NumberOfEmployees, and AnnualRevenue. If Visionary supports parent-child company hierarchies, the parent-company reference maps to Salesforce Account.ParentId. Circular parent references are flagged and resolved to the oldest ancestor before migration.

Visionary deal or opportunity records map to Salesforce Opportunities. The deal name becomes Opportunity Name, amount maps to Amount, and close date maps to CloseDate. The most consequential mapping is deal stage → Salesforce StageName, which may require value-mapping if Visionary stage names differ from Salesforce's default pick-list values. Each Visionary deal pipeline optionally maps to a Salesforce RecordType + Sales Process for stage-scoping.

Visionary pipelines (if multi-pipeline is used) transform into Salesforce Record Types and Sales Processes. A Salesforce admin must pre-create the record types and assign them to profiles before migration runs. FlitStack delivers a schema setup plan specifying which record type should be active per pipeline so stage pick-list values scope correctly after migration.

Visionary custom fields (properties) that have no direct Salesforce equivalent become Salesforce custom fields. FlitStack creates the __c field definition in Salesforce during the pre-migration schema setup phase, specifying the correct field type (text, picklist, number, date, etc.) based on the source data type. Custom field API names strip spaces and append __c per Salesforce conventions.

Visionary call logs and engagement records map to Salesforce Tasks. The Task.Subject field receives a constructed value (e.g., 'Call: [Contact Name]') and Task.ActivityDate preserves the original engagement timestamp. OwnerId resolves by email match to the Salesforce user who logged the activity. Task.Type is set to 'Call' for call logs and 'Email' for email engagement records.

Visionary meeting records map to Salesforce Events. Event.Subject, StartDateTime, EndDateTime, and Description all transfer directly. The Event is linked to its parent Contact or Account via the WhatId or WhoId lookup. Owner resolution follows the same email-match logic used for Tasks.

Visionary notes migrate to Salesforce Notes (modern Notes object, not legacy Note). The Note.Body transfers the note content, and Note.ParentId links to the associated Contact or Account. Rich-text formatting in Visionary notes is preserved as HTML within the Note.Body field. If Visionary stores notes in a plain-text format, no transformation is required.

Visionary file attachments download from the source and re-upload to Salesforce as Salesforce Files (ContentDocuments linked via ContentDocumentLinks). Each file re-attaches to the parent record it was associated with in Visionary. Files exceeding Salesforce's 25MB per-file limit are flagged for manual handling or chunked upload. Inline images embedded in rich-text notes are extracted and rehosted as Salesforce Files.

Visionary owner assignments do not map directly to a Salesforce User record. FlitStack resolves Visionary owner IDs to Salesforce Users by matching the owner's email address against Salesforce User emails. Unmatched owners are flagged in the pre-migration report—your team either invites them to Salesforce first or assigns their records to a designated fallback owner before migration commits.

Visionary custom objects map 1:1 to Salesforce custom objects. The Salesforce custom object must be pre-created with the correct API name (suffix __c) and sharing model before migration runs. If the Visionary custom object uses N:N relationships, a Salesforce junction custom object is created to represent the many-to-many association.