Migrate from Spiro to Salesforce Sales Cloud

Spiro Company records map to Salesforce Account. Spiro's company name becomes Account Name; billing address and shipping address map to Account Address fields. The domain name stored in Spiro's company record becomes the Website field on Account for dedupe reference. If multiple Spiro Company records share the same legal entity name, we normalize and merge them at import time using external ID resolution to prevent duplicate Account creation.

Spiro Contact records map to Salesforce Contact. Standard fields (FirstName, LastName, Email, Phone, Title) migrate directly. Spiro Contact custom fields are extracted from Spiro's schema (coordinated via CSM) and recreated in Salesforce as custom Contact fields before import. The parent AccountId is resolved at import time by matching Spiro's Company association to the Salesforce Account created in the previous phase.

Spiro Opportunity records map to Salesforce Opportunity with stage, value, and close date preserved. The most critical mapping is Spiro stage name to Salesforce StageName. We extract the complete stage list from Spiro during scoping, map each to a corresponding Salesforce stage (or create new stages to match Spiro's pipeline exactly), and configure Record Types and Sales Processes before Opportunity import begins. Amount maps from Spiro's Opportunity value. CloseDate migrates from Spiro's close date.

Spiro uses Opportunities to represent pipeline entries without a separate Pipeline configuration object. Each distinct stage set in Spiro becomes a Salesforce Record Type on Opportunity with a corresponding Sales Process. Stage probability percentages are extracted from Spiro and applied to Salesforce StageProbability values. If Spiro uses multiple pipelines with different stage sets, we create a Salesforce Record Type per pipeline and assign page layouts accordingly.

Spiro custom fields on Companies, Contacts, and Opportunities require explicit schema extraction coordinated through Spiro's Customer Success Manager because no public API exposes the full custom field definition. We request the field inventory from Spiro support before migration design, recreate each custom field in Salesforce as a typed custom field (__c), and then import data with those fields populated. If Spiro's custom field types (picklist, date, number, text) differ from Salesforce field types, we perform type conversion during the transform phase.

Spiro email activities linked to Contacts and Companies map to Salesforce Task (activity timeline entry) combined with EmailMessage (email content). The Spiro email timestamp becomes Task ActivityDate; email body becomes EmailMessage TextBody; sender and recipient map to EmailMessage FromName, FromAddress, ToAddress. The WhoId on Task points to the migrated Contact. We flag any emails logged during a Spiro email disconnection window as missing data and document the gap in the migration report.

Spiro call activities map to Salesforce Task with TaskSubtype = Call. Call duration, disposition, and any recording URL stored in Spiro migrate to custom Task fields. ActivityDate is set to the original Spiro call timestamp. OwnerId is resolved by matching Spiro's owner email to the Salesforce User created in the User provisioning phase.

Spiro meeting activities map to Salesforce Event. StartDateTime, EndDateTime, Subject, and Location migrate directly. Attendees are mapped via EventRelation records pointing to the migrated Contact and User records. The original Spiro meeting timestamp preserves the activity timeline ordering.

Spiro task activities map to Salesforce Task with Status, Priority, Subject, and ActivityDate preserved. OwnerId resolution follows the same email-based matching used for all other owner-dependent records. Completed tasks in Spiro map to Status = Completed; open tasks map to Status = Not Started or In Progress.

Spiro user records map to Salesforce User accounts. We match by email address. Spiro users without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive Spiro users (former employees) are created as inactive Salesforce Users so that activity ownership is preserved on the historical timeline.

Spiro stores attachments as linked file URLs rather than embedded file blobs. During migration we verify each Spiro attachment URL is reachable, download the file content, upload it as a Salesforce ContentVersion record, and create a ContentDocumentLink associating it with the parent Account, Contact, or Opportunity. If the source Spiro workspace access is revoked before migration completes, attachment links break permanently. We flag this risk during discovery and recommend downloading critical files before the cutover window.

Spiro's Data Collector is the primary data export mechanism and requires CSM enablement and a Dropbox folder destination. We coordinate with Spiro's team to provision the Dropbox folder and confirm CSM access before beginning any export-phase work. This adds 3-5 business days to the migration timeline. Data Collector produces CSV exports per object type that we then transform and load into Salesforce via Bulk API 2.0.