Migrate from Highrise to Microsoft Dynamics 365 Sales

Highrise People map to Dynamics 365 Contact records. Standard fields (name, email, phone, address, social links) transfer directly. The primary email address on the Highrise Person becomes the Contact's emailaddress1, and we preserve any alternate emails as emailaddress2 and emailaddress3. Phone numbers map to telephone1, telephone2, and mobilephone. The Highrise Party-to-Person association (when a Person belongs to a Company) is preserved by first creating the Account from the linked Company Party and then setting the Contact's parentcustomerid_account to that Account at insert time.

Highrise Companies map to Dynamics 365 Account records. Company name maps to accountname, website maps to websiteurl, and address fields map to address1_line1 through address1_postalcode. Account is created before any Contact import so that the parentcustomerid_account lookup is satisfied at the moment of Contact insert. Highrise does not distinguish between individual (person-only) and organizational accounts, so we flag any Company-linked Person records for Account creation and any standalone Person records as Contacts without a parent Account.

Highrise Deals map to Dynamics 365 Opportunities. Because Highrise exports Deals only as .txt files, we parse the TXT output to extract deal name (name), deal value (estimatedvalue), stage (stagename via pipeline reference), and responsible user (ownerid via User mapping). Closed-Lost and Closed-Won status from Highrise map to Dynamics 365 Opportunity Stage values that we configure during schema setup. Highrise's flat Deal-Party link (where a Deal attaches to either a Person or Company) requires resolution: if the Deal links to a Company Party, we create the Opportunity with the resolved Account; if it links to a Person Party without a Company, we create the Opportunity and link it to the Contact record directly.

Highrise Cases map to Dynamics 365 Case records. Cases export as TXT only, so we parse the text to extract Case title (title), status (statecode and statuscode), and linked party reference (customerid). Case priority, origin, and resolution details that are absent from the TXT output are flagged as data gaps for manual review before the final migration step. We also flag any embedded attachments or internal notes stored within Cases for SharePoint re-upload post-migration since Cases support Notes within Dynamics 365 but the TXT export does not preserve attachment metadata.

Highrise Tasks map to Dynamics 365 Task records with full field fidelity. Subject, due date (scheduledend), priority (prioritycode), status (statecode), and description transfer directly. Task assignment resolves the Highrise owner reference to the Dynamics 365 OwnerId via the User mapping table. Completed tasks migrate with their actual completed date preserved. Open tasks migrate with their original due dates. Highrise Tasks linked to a specific Party (Person or Company) map to the corresponding Dynamics 365 Contact or Account via the RegardingObjectId lookup.

Highrise stores Notes and Emails as Recordings linked to People or Companies. Notes migrate as Dynamics 365 Annotation records (notenote field for body, subject for title) attached via objectid to the corresponding Contact or Account. Email Recordings migrate as Email records in Dynamics 365—body text, subject, and timestamp transfer, but HTML formatting is lost since the TXT export strips all markup. We attach each Email Annotation to the corresponding Contact or Account record. Call and Meeting Recordings also migrate as Activity records (PhoneCall or Appointment) where the TXT content provides sufficient structured data for field mapping.

Highrise custom fields on People, Companies, and Deals are exported via the custom_field_subjects API endpoint and parsed into name-value pairs. We detect all custom field definitions in the Highrise account, provision matching custom fields in Dynamics 365 (with appropriate field types: text, number, date, picklist, two-option), and map each custom field value to the corresponding Dynamics 365 custom field at migration time. Custom field options (for picklist-type custom fields) require manual mapping to Dynamics 365 option set values during schema configuration.

Highrise Tags are flat labels applied to People, Companies, Deals, and Cases. We export all tag assignments and re-apply them in Dynamics 365 as custom multi-select picklist fields on the relevant entity. For example, Highrise tags on People become a custom field contact_tag__c (type: multiselctpicklist) on Contact, populated with the comma-separated list of original tags. The customer chooses during scoping whether to consolidate tags into one multi-select field per entity or to create a separate Tag entity with a many-to-many relationship via a junction table.