Migrate from Softgarden to Bullhorn ATS & CRM

Softgarden's Bewerber maps directly to Bullhorn Candidate. Base fields—firstName, lastName, email, phone, address—are mapped to Bullhorn's CandidateName, Email, Phone, and Address composite. Softgarden's applicant status (Bewerbungsstatus) does not map directly; we preserve it as a custom field sg_original_status__c since Bullhorn derives candidate status from Opportunity and Placement records. Candidate attachments (CVs, profile pictures) migrate via Bullhorn's CandidateAttachment API endpoint. German-language name formatting (titles, double-barreled names) maps to Bullhorn's name component fields with validation against Bullhorn's formatting rules.

Softgarden's Bewerbung (the junction between Bewerber and Stellen) maps to Bullhorn Opportunity. The Softgarden application date maps to Bullhorn dateAdded; current workflow stage maps to Opportunity currentState with OpportunityHistory entries capturing stage transitions. Softgarden's Bewerbungs-ID becomes a custom field sg_application_id__c for reconciliation. Note that Bullhorn's Opportunity is used for candidate pipeline tracking even before a placement is made—Softgarden customers accustomed to a separate Application object should plan for this model shift during admin configuration.

Softgarden's Stellen (job postings) map to Bullhorn JobOrder. Position title, description, department, and employment type map to Bullhorn's title, description, occupation, and employmentType fields. Publication status in Softgarden (published, archived, draft) maps to JobOrder status (Open, PAUSED, Closed) with a status mapping matrix created during scoping. Active and archived positions are distinguished by the isActive flag.

Softgarden's Katalogwerte drive dropdown fields for location, department, employment type, and source channels. Bullhorn does not have a native catalog value system—these become custom picklist fields on Candidate, JobOrder, or Opportunity. We query Softgarden's catalog endpoint during discovery, extract all active Katalogwerte, and create equivalent Bullhorn picklist values in the destination org. Catalog structure is flattened during migration: each Katalogwert becomes a discrete picklist entry. Custom catalog values (customer-defined) require additional discovery to map without a pre-built enumeration endpoint.

Softgarden tracks application source (job board, direct, referral) as a catalog value on each Bewerbung. Bullhorn Candidate has a standard source field (source) and a secondary source field (secondarySource). We map the primary Softgarden application source to Bullhorn source. If the customer uses multiple source categories, we create a custom field sg_application_source__c and migrate both primary and secondary values there. Source channel normalization is applied during transformation since Softgarden's source taxonomy (driven by its multiposting channels) may include values not present in Bullhorn's standard list.

Softgarden's configurable pipeline stages (New, Screening, Interview, Offer, Hired, Onboarding) map to Bullhorn Opportunity Stage values. Each Softgarden stage becomes a Bullhorn stageName entry with a corresponding probability. Bullhorn's OpportunityHistory automatically timestamps each stage change; we supplement this with sg_stage_entered_date__c custom fields from Softgarden's stage transition timestamps. Stage probability percentages migrate with rounding to Bullhorn's supported integer range. If Softgarden uses custom stage names beyond the standard six, we create custom Opportunity Stage values during Bullhorn configuration.

Softgarden attachments (CVs, cover letters, profile pictures, general documents) migrate via Bullhorn's CandidateAttachment API. We extract attachments from Softgarden's attachment endpoints and upload to Bullhorn using the Candidate ID as the parent reference. Softgarden's system-generated applicant PDF (a composed summary of all attachments) is not reliably available via the API for candidates in early pipeline stages because it is status-triggered—we migrate the raw attachment files instead and note that the composed PDF is not available for candidates pre-trigger status.

Softgarden exposes custom fields on Bewerbung records but does not publish a dedicated custom field registry endpoint. We discover active custom fields during the discovery phase by sampling a representative record set and inferring field names, types, and presence across the dataset. Discovered custom fields become custom Opportunity fields in Bullhorn with equivalent data types (text, number, date, picklist). Custom field discovery adds one to two days to scoping but does not block migration.

Softgarden custom fields on Stellen (position-level custom fields) map to Bullhorn custom fields on JobOrder. Same discovery methodology applies: we sample position records, infer schema from field presence, and create equivalent Bullhorn custom fields. Position-level custom fields are typically fewer than application-level custom fields and map cleanly to Bullhorn's extensible JobOrder schema.

Softgarden assigns owners (recruiters or hiring managers) to Bewerber and Bewerbung records. Bullhorn User records are the owner reference. We resolve Softgarden owners by email match against Bullhorn's User table. Any Softgarden owner without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes. Owner assignment on Candidate, JobOrder, and Opportunity must be resolved before bulk insert.

Softgarden acquired absence.io in 2021 to offer personnel files, absence management, and time recording as a separate module. This data lives in a separate absence.io product instance not accessible via the Softgarden ATS API. We do not migrate absence.io data as part of a Softgarden-to-Bullhorn ATS migration. If the customer requires absence.io data migrated to a separate HR system, that is a distinct engagement.

Softgarden's configurable workflow stages (pipelines, stages, triggers) are a configuration layer, not a data migration target. Bullhorn's Opportunity stage model and placement workflow serve as the equivalent. We document the Softgarden workflow stage structure and map it to Bullhorn's Opportunity stage configuration during the schema design phase. Active workflow automation (email triggers, status-change notifications) is not migrated—we deliver a written inventory of these for the customer's Bullhorn admin to rebuild in Bullhorn's workflow or task automation tools.