Migrate from World Manager to Bullhorn ATS & CRM

World Manager employee records map to Bullhorn Candidate records. The core mapping covers firstName, lastName, email, phone, and address fields. Hire date from World Manager becomes dateAvailable on Candidate or a custom field hireDate__c depending on Bullhorn edition. Employee status (active, inactive, terminated) maps to Candidate status with a custom field originalEmploymentStatus__c preserving the source value. Note: Bullhorn Candidate is designed for applicants and placed workers; it has no native equivalent to an internal employee record. Custom fields carry over employment-type and pay-rate data that World Manager tracked on the employee profile.

World Manager's Location entity maps to Bullhorn ClientCorporation if the customer is a staffing firm placing workers at client sites, or to a custom field locationName__c on Candidate if the destination models the location as an attribute rather than a client relationship. We resolve this during scoping by confirming whether the customer operates as a staffing agency with client relationships or as a multi-location hospitality operator. Parent-client resolution for ClientCorporation hierarchy happens before Candidate import.

World Manager Department maps to a Bullhorn custom text field dept__c or a custom picklist field on Candidate. If the customer's Bullhorn org has a Department custom object set up by Bullhorn Support, we create Department records and link them to Candidate via a lookup relationship. Without custom object provisioning, department data stores as a labeled custom field with the department name as the value.

World Manager Role maps to Candidate.title (standard Bullhorn field) as the primary target. If the customer requires role-to-position tracking across multiple roles per employee, we use a custom field role__c to preserve the full World Manager role designation separately from the Bullhorn candidate title.

World Manager training module completions per employee map to Bullhorn credential records. If Bullhorn Support has provisioned the standard credential entity or a custom credential object (e.g., customObject1s), we create one credential record per training module completion with credentialType (the module name), dateEarned, expirationDate, and status (current, expired). For customers without custom credential objects, completions store in a custom object with the same field structure. We exclude training modules that do not resolve to a valid employee record in the source export.

World Manager certifications (e.g., food handler, alcohol service, safety certifications) map to Bullhorn Credential records or a customCertification__c object with fields for certificationName, issuingAuthority, dateIssued, and expirationDate. Certifications with expiry dates require Bullhorn's expiry-alert workflow rebuild in Bullhorn Automation post-migration; we flag these as candidates for the automation inventory document delivered at cutover.

World Manager compliance document attachments (PDFs, images, scanned certificates) migrate as Bullhorn ContentDocument records linked to the corresponding Candidate record via ContentDocumentLink. We preserve the document name, description, and any expiry metadata as a custom field on the ContentDocument. Documents attached to deprecated or orphaned employee records (records not resolvable to a Candidate) are placed in a separate folder and flagged in the reconciliation report for the customer's admin to reassign or discard.

World Manager shift eligibility (availability windows, shift-type preferences) has no direct Bullhorn equivalent. We store shift eligibility data in a custom text or multi-select picklist field shiftEligibility__c on the Candidate record with structured values representing the original World Manager shift availability matrix. If the customer requires shift scheduling management post-migration, we recommend Bullhorn Workforce Management integration as a separate scope.

World Manager platform administrators and trainers map to Bullhorn User records. We resolve World Manager user accounts by email match against the Bullhorn User table. Any World Manager user without a matching Bullhorn User is placed in a reconciliation queue; the customer's Bullhorn admin provisions the User account before record import resumes, because OwnerId and assignedTo references on Candidate and JobOrder require a valid Bullhorn User.

For customers migrating from World Manager who are standing up Bullhorn as a staffing ATS, any open job requisitions tracked in World Manager (or tracked externally) become Bullhorn JobOrder records. JobOrder maps title, description, status, and startDate from the source record. JobOrder must be created before Candidate placement records are imported so that the JobOrderCandidate出色 reference is satisfied at migration time.

World Manager employee records that represent current placements at client sites map to Bullhorn Placement records with the Candidate, JobOrder, ClientCorporation, and staffing assignment dates resolved. Placement status, pay rate, bill rate, and termination date migrate from the corresponding World Manager employee record fields. Placement documents (offer letters, assignment agreements) migrate as ContentDocument attachments linked to the Placement record.

World Manager training module definitions (the course catalog, not the completion records) have no direct Bullhorn equivalent because Bullhorn is not a learning management system. We export the training module structure as a written inventory of module names, descriptions, required frequency, and applicable roles, and the customer's admin rebuilds the training requirement tracking in Bullhorn Automation or a separate LMS as a post-migration configuration task.