Migrate from SignalHire to Crelate

SignalHire People Profile records map to Crelate Candidate records. We extract the SignalHire UID, full name, current job title, company, location, LinkedIn profile URL, and all returned work history entries. SignalHire's email verification status (Valid/Risky/Unknown) and deliverability score migrate as custom fields on the Crelate Candidate record. If the candidate's SignalHire profile includes multiple email addresses, the primary (highest-confidence) email maps to Crelate's primary contact field and alternates populate a custom multi-email field.

SignalHire Company Profiles (30M+ scraped records) do not map directly to Crelate Clients because SignalHire company data lacks the firmographic depth and relationship ownership that Crelate Clients require. We extract company name, domain, industry, size range, and LinkedIn company URL from SignalHire Company Profiles and use them as a preliminary enrichment layer: where a matching Crelate Client or Client Contact already exists, we attach the SignalHire company data as a custom enrichment block. For net-new company records, we create a Crelate Client stub with the SignalHire-sourced domain and industry. Recruiters must validate and enrich the Client record with owned firmographic data post-migration.

SignalHire returns email addresses with a verification status (Valid, Risky, Unknown) and a confidence score. We map the Valid emails to Crelate's standard email field on the Candidate record, preserving the SignalHire verification status in a custom field signalhire_email_status__c and the confidence score in signalhire_email_score__c. Risky and Unknown emails migrate to a custom multi-email field signalhire_alternate_emails__c as a semicolon-delimited list. This preserves the full SignalHire enrichment signal for the recruiter to act on inside Crelate.

SignalHire phone records include country code, line type (mobile/landline), and verification confidence. The primary phone (highest confidence) maps to Crelate's Candidate phone field. Additional phones with a mobile line type map to the mobile phone field. All returned phone variants with line type metadata migrate to a custom field signalhire_phones__c as a structured text block (format: '+1XXXXXXXXXX [mobile]'). The verification confidence score is preserved in signalhire_phone_score__c.

SignalHire stores social profile URLs (LinkedIn, Twitter, GitHub, etc.) as URL arrays per person. The LinkedIn URL migrates to Crelate's LinkedIn URL field if present. All other social links (Twitter, GitHub, Xing, etc.) migrate to a custom field signalhire_social_links__c as a JSON-encoded list or semicolon-delimited string. The platform identifier for each link is preserved for downstream segmentation.

SignalHire lead lists and talent pools are many-to-many relationships between list IDs and People Profile UIDs. We reconstruct each named list as a Crelate Candidate Group (the primary container) and add the constituent members as Candidate Group entries. The original SignalHire list name and list ID are preserved as group metadata fields. Candidates that appeared in multiple SignalHire lists receive multiple Crelate Group memberships. This mapping requires enumerating all distinct list IDs in the source account during discovery, as SignalHire does not expose list membership through a single API endpoint.

The SignalHire-generated unique identifier (UID) for each People Profile migrates as a read-only custom field on the Crelate Candidate record. This field serves as the migration provenance reference and allows the customer to cross-check any migrated record back to the original SignalHire profile. The field is not used for deduplication because Crelate generates its own Candidate IDs.

SignalHire People Profiles include work history entries (job title, company name, start date, end date, description). These map to Crelate's Candidate employment history section as discrete entries with job title, company, dates, and description preserved. The most recent work history entry from SignalHire becomes the Candidate's current position, which Crelate surfaces in search and list views. We flag any work history entries where the SignalHire company name differs from the matched Crelate Client name for reconciliation.

SignalHire surfaces an aggregate verification score per profile combining email, phone, and social link confidence. We extract this composite score and migrate it as a numeric custom field signalhire_profile_score__c on the Candidate record. Recruiters can use this field to sort and filter migrated prospects by data quality at time of migration. Crelate's native candidate scoring is separate and can be applied by the recruiting team post-migration.

SignalHire team plans include a team roster with name, email, and role. We export the team roster as a structured list and hand it to the customer's Crelate admin for User provisioning. SignalHire team member roles (Admin, Member) do not map directly to Crelate User Roles and Permissions, which are defined per Crelate tier. The admin maps each SignalHire team member to the appropriate Crelate seat and permission level. We do not migrate SignalHire team member records as Crelate Users directly because user provisioning requires admin action and identity verification.

SignalHire CRM and ATS integrations (Salesforce, Pipedrive, Zoho field mappings, sync directions, webhook URLs) are destination-specific and do not migrate. We export the raw SignalHire contact data; the customer must reconfigure integrations in Crelate's Business tier integrations (Google Calendar, Outlook Calendar, RingCentral, Indeed, Dice, CareerBuilder, Monster, Zapier, and Crelate's API access). We provide a written inventory of every active SignalHire integration as a reference for the Crelate admin to rebuild.

Credits are a SignalHire-specific billing mechanism with no Crelate equivalent. We do not migrate credit balances. Unused SignalHire credits are forfeited at account cancellation. The migration cost and timeline are scoped independently of any remaining credits; the customer should exhaust or accept forfeiture of credit balances before cancellation.