Migrate from TalentWall to BambooHR

Jobs originate in the upstream ATS (Greenhouse, Lever, or Jobvite) and sync to TalentWall as the canonical source. We extract job records from the upstream ATS API — not TalentWall — to preserve title, department, location, job description, and opening date. In BambooHR, these map to Job Openings. We validate the count against BambooHR's tier cap (Core: 5, Pro: 25, Elite: 50 active openings) before migration. Any job over the cap is flagged for the customer to archive or upgrade their BambooHR plan.

Candidates are ATS-native records synced to TalentWall as interactive cards. We export from the upstream ATS API to preserve all application data, status history, and source attribution. In BambooHR, candidates map to Job Applications for open positions and Employee Records for hired candidates. We resolve the BambooHR job opening reference by matching job title and department. Historical applications without a matching active BambooHR job opening are held in a staging table for admin assignment.

Stage names and order are defined per job in the ATS and reflected as columns on TalentWall's Wall. We pull stage definitions from the ATS job configuration and map them to BambooHR's job opening stage structure. Stage probability and stage type (hired, rejected, active) migrate as stage metadata. BambooHR's stage model is simpler than most ATS platforms; if the source ATS has more than 10 stages, we consolidate to BambooHR's stage limit with a written stage mapping table for the admin to review.

Interview scheduling data shown in TalentWall's calendar view originates from the ATS calendar integration. We extract interview records — scheduled time, interviewer, interview type, and meeting link — from the ATS to preserve them in BambooHR. BambooHR does not have a standalone interview scheduling object; interview records attach to the Job Application. We map the interview type to the BambooHR application stage and write interviewer assignments as application notes.

TalentWall allows custom fields scoped to individual jobs. These are TalentWall-native and not stored in the ATS. We extract them via TalentWall's interface or direct storage access arranged with their support team, and map them to BambooHR job opening custom fields. We validate field type — text, number, date, dropdown — before migration. BambooHR custom fields on job openings are created via the BambooHR API before record import so the field exists at insert time.

Offer-level custom fields in TalentWall track data against a candidate's offer record. We extract these as key-value pairs and map them to BambooHR candidate custom properties or employee file fields depending on offer status. If the offer is accepted, these fields land on the employee record; if the offer is pending, they attach to the application. We preserve the original field namespace annotation so the admin can verify the mapping post-migration.

Job health (Red/Yellow/Green status) and associated notes are TalentWall-native annotations stored exclusively in TalentWall's own database — they are not written back to the connected ATS. We extract the health ranking and notes for each job and write them as a custom field (e.g., TW_JobHealth__c) on the corresponding BambooHR job opening. This preserves the recruiting team's prioritization signal in the destination HRIS where it can inform hiring manager conversations.

Candidate freshness is a TalentWall-computed or -entered metric reflecting last activity and pipeline position. This data lives in TalentWall's storage and has no ATS equivalent. We extract freshness scores and last-activity timestamps and write them as custom fields on the corresponding BambooHR employee or candidate record. If BambooHR is also receiving new hire data, the freshness field is useful as a hiring velocity reference.

Interview scorecards may be entered directly into TalentWall rather than the ATS, depending on team workflow. We audit both TalentWall and the upstream ATS during discovery to identify where scorecard data lives. If scorecards are TalentWall-native, we extract them and write them as employee file attachments (PDF) or rich text notes on the candidate record in BambooHR. Scorecard templates and rubrics do not migrate as reusable forms; we deliver a written inventory of the evaluation structure for the admin to recreate in BambooHR if needed.

Resumes and attachments are the ATS as the system of record. We export them from the ATS file storage at migration time and deliver them as a structured file package alongside the record data. Files are associated with the correct BambooHR employee or application record via file naming conventions (candidate_id + document_type) and a manifest CSV the customer's admin uses to attach in BambooHR, since BambooHR's bulk file attachment requires API calls per file.

TalentWall may carry recruiter-applied tags or labels on candidate cards that are not mirrored back to the ATS. We extract any TalentWall-native tags and write them as BambooHR tags on the candidate or employee record. Tags with more than 500 distinct values are written to a custom multi-select picklist field instead, since BambooHR's tag model has cardinality limits for high-volume label sets.

TalentWall's custom widget library maps visual widgets to specific job-level or offer-level custom fields. Widgets reference the custom field by name or ID. We extract the widget-to-field mapping and document it as a configuration reference for the admin: widget name maps to BambooHR custom field X, type maps to field type Y, display position is noted. BambooHR does not replicate TalentWall's kanban widget layout; the mapping document allows the admin to assess which signals need a custom field in BambooHR and which represent purely visual annotations.