Migrate from Softgarden to Zoho Recruit

Softgarden Applicant records map to Zoho Recruit Candidate records. The applicant name, contact fields (email, phone, address), and any profile metadata transfer directly. We resolve Softgarden's German field labels (Bewerber-ID, Vorname, Nachname) to Zoho Recruit's English equivalents (CANDIDATEID, First Name, Last Name) during the transform phase. Candidate records are created first so that subsequent Application records can reference them via lookup.

Softgarden Application records link Applicants to Positions and track the pipeline stage for each submission. We map Bewerbung to Zoho Recruit's Job Submission module, preserving the application source channel, submission timestamp, current stage, and any stage-entry timestamps. Stage names from Softgarden's configurable workflow (New, Screening, Interview, Offer, Hired, Onboarding) map to Zoho Recruit's Candidate Status picklist values configured during setup.

Softgarden Position records (Stellen) map to Zoho Recruit Job Opening. We transfer title, description, department, location, employment type, and publication status. Active versus archived positions are distinguished by Zoho Recruit's Opening Status field. Position records must exist in Zoho Recruit before Application records are imported so that the Job Opening lookup on Job Submission is satisfied at import time.

Softgarden supports document upload and retrieval via dedicated API endpoints. We migrate CV files, profile pictures, and supporting documents as binary attachments linked to the corresponding Candidate record in Zoho Recruit. The mapping uses the original filename and MIME type preserved during extraction. Note that Softgarden's system-generated applicant PDF summary is only available via the PUSH export interface triggered by status changes; we bypass the composed PDF and migrate raw attachment files directly instead.

Softgarden tracks the originating channel for each application (job board, direct, referral, multipost) via configurable application sources. These catalog values (Katalogwerte) require resolution via Softgarden's catalog endpoint before mapping to Zoho Recruit's Source picklist. If the customer has created custom source labels in Softgarden, we map each to an equivalent Zoho Recruit Source value during the catalog value normalization phase.

Softgarden's configurable workflow stages (e.g., New, Screening, Interview, Offer, Hired, Onboarding) map to Zoho Recruit's Candidate Status picklist. We preserve the original stage names and stage-entry timestamps. If Softgarden's workflow has custom stages beyond the standard set, we configure matching Zoho Recruit status values during the module setup phase before migration begins.

Softgarden uses catalog values (Katalogwerte) for structured dropdown fields including location, department, employment type, and salary range. We resolve each catalog value via Softgarden's dedicated catalog endpoint and map it to the corresponding Zoho Recruit picklist. Picklist values in Zoho Recruit are created during the schema setup phase to ensure the field type matches the incoming data before any records are imported.

Softgarden exposes custom fields on applications and positions but does not publish a dedicated API endpoint to enumerate all active custom fields and their data types. We discover the active custom field schema by querying a representative sample of records during the discovery phase, inferring field names and types from field presence across the dataset. Discovered custom fields are then created in Zoho Recruit's module builder before migration, matching the inferred data type (text, number, date, picklist, checkbox, etc.).

Softgarden Owner records map to Zoho Recruit Users. We resolve by matching the owner's email address against the Zoho Recruit destination account's User table. Any Softgarden Owner without a matching Zoho Recruit User is placed in a reconciliation queue for the customer's admin to provision before record import resumes. Owner assignments on Application and Position records are preserved as User lookups in Zoho Recruit.

Softgarden's system-composed applicant PDF summary—including all attachments—is only generated and pushed via the export interface when a candidate enters the configured trigger status. There is no on-demand PDF generation endpoint. For candidates still in early pipeline stages, the composed PDF may not exist in exportable form. We migrate the raw CV and document attachments directly from Softgarden's attachment API instead of relying on the composed PDF, which is the more reliable data source in all cases.

Softgarden's PUSH export interface only transmits applicant data for candidates who enter the configured trigger status after the integration is set up. Candidates historically past that status are permanently excluded from automated export. We flag this gap during scoping, assess how many historical candidates fall outside the export window, and present options: accept the data boundary, request a manual export from Softgarden's backend team, or identify a different export mechanism. This boundary is a pair-specific constraint, not a platform limitation of Zoho Recruit.

Softgarden acquired absence.io in 2021 to expand into internal HR processes. Absence.io data (personnel files, absence management, time recording) lives in a separate product instance not accessible via Softgarden's main ATS API. We do not attempt to migrate Absence.io data within the standard Softgarden-to-Zoho Recruit migration scope. If the customer also uses Zoho People, a separate engagement covers personnel file and absence data migration.

Softgarden's configurable pipeline stages and workflow rules do not have a direct Zoho Recruit equivalent at the automation level. We do not migrate workflows, automation rules, or stage-triggered actions as code. We deliver a written inventory of every Softgarden workflow stage, rule, and trigger condition with a Zoho Recruit Workflow Rule or Blueprint equivalent documented for the customer's admin to rebuild post-migration. This inventory is included in the standard migration scope as a deliverable, not as an automated migration.