Migrate from Highrise to Salesforce Sales Cloud

Highrise People are the primary contact records and map directly to Salesforce Contact. We extract all standard fields (name, email, phone, address, social links) from the CSV/Excel export and map them to typed Salesforce fields. The Highrise contact's associated Company (Party link) resolves to a Salesforce Account that we create before Contacts are imported. Any Highrise People without a linked Company map to Contacts without an AccountId and are flagged for the customer to assign accounts manually or merge.

Highrise Companies are a distinct Party type and map to Salesforce Account. The parties.xml API endpoint provides the export, and we preserve the Company-Contact association using Highrise's party_id foreign key. Account is created before any Contact import so that the AccountId Lookup is satisfied at Contact insert. The Company name becomes the Account Name; any custom fields on the Company Party map to custom fields on Account.

Highrise Deals export as plain-text (.txt) only, not CSV. We parse the TXT output to extract deal name, stage, value (as currency), responsible user (mapped to Salesforce OwnerId), and linked Party. We reconstruct these as Salesforce Opportunity records with the Highrise stage name mapped to a Salesforce StageName value in the configured Sales Process. Closed dates from Highrise migrate to CloseDate. Deals with complex or ambiguous data are flagged for manual review before the final migration step.

Highrise Cases (Customer Cases) handle support or task tracking and export as TXT only. We parse the text to extract case title, status, linked Party, and responsible user, then map these to Salesforce Case with Subject, Status, and OwnerId resolved. Any embedded attachment references in the TXT output are flagged because attachments cannot transfer through the TXT export mechanism. If the destination Salesforce org includes Service Cloud, Cases map with full Status and Priority field support; otherwise, Cases map to a custom Case__c object in Sales Cloud.

Highrise's named deal stages (e.g., New, Contacted, Qualified, Won, Lost) are extracted during scoping and mapped to Salesforce StageName values in a pre-configured Sales Process. We create the Sales Process in the destination Salesforce org during the schema design phase, whitelisting only the stages that exist in the Highrise account. Stage probabilities are approximated from Highrise's implied stage progression or set to Salesforce defaults if no probability data is available.

Highrise Tasks are standard API-accessible objects and export cleanly via the tasks.xml endpoint. Completed and open tasks transfer with due dates, assignees (mapped to Salesforce OwnerId via the User lookup), and related Party references. Status (completed, open, deferred) maps to Salesforce Task Status, and Priority maps to Task Priority. Tasks linked to Deals resolve to the Opportunity ID after Opportunity import is complete.

Highrise Notes are stored as Recordings and export as TXT, which strips HTML formatting. We capture the full text content, timestamp, and author (mapped to Salesforce CreatedById via User lookup). Notes are inserted as Salesforce Note records linked via ContentDocumentLink to the parent Contact, Account, or Opportunity. The plain-text-only limitation is disclosed to the customer before migration; any Notes with rich formatting are flagged for post-migration review.

Highrise emails are Recordings linked to People or Companies and export as TXT, stripping HTML body content and inline image references. We capture the email metadata (date, from, to, subject, body as plain text) and insert as Salesforce EmailMessage records linked to Tasks on the Contact. The WhoId on the Task points to the migrated Contact; the WhatId points to the related Opportunity if applicable. Email thread continuity in Salesforce relies on the subject-line matching which is outside migration scope.

Highrise custom fields on People, Companies, and Deals are accessible via the custom_field_subjects API endpoints. We detect all custom field definitions during scoping, map them to Salesforce custom fields of equivalent type (text, number, date, picklist, checkbox), and pre-create the destination schema before any data import. Custom fields are deployed to the Sandbox for validation before production migration. Any Highrise custom field with no Salesforce equivalent (e.g., a complex multi-select that cannot map to any Salesforce field type) is flagged for customer decision during scoping.

Highrise Tags are flat labels applied to People, Companies, Deals, and Cases. We export all tags and re-apply them as Salesforce Tags (Platform standard) or as custom multi-select picklist fields on the relevant object, depending on the customer's preference. The many-to-many relationship between records and tags is preserved through either a TagAssignment table or through multi-select field values. The customer chooses the tag strategy during scoping.

Highrise Users (team members who own records and are assigned to Deals) are exported with name and email. We map them to Salesforce User records by email match. Any Highrise User without a matching Salesforce User is placed in a reconciliation queue, and the customer's Salesforce admin must provision the User before record import resumes because OwnerId references are required on Opportunity and Case records.

Highrise SMS conversations stored as part of a contact's recording history are captured via the API. Message text and timestamp migrate to Salesforce Task with TaskSubtype = SMS. The SMS content is stored in the Task Description field. Media attachments (images, files) sent via SMS cannot transfer because Highrise's recording export does not preserve media blobs. The customer is informed of this limitation during scoping.