Migrate from ELMO Software to Recruit CRM & ATS

ELMO employee profiles (GET /users, GET /users/{id}) map to Recruit CRM Candidates. The ELMO name, email, phone, address, and employment metadata fields map to the Candidate standard fields. Employment type (full-time/part-time/casual) from ELMO's employment-details becomes a custom Candidate field for filtering. Employee status (active/terminated) maps to Candidate status in Recruit CRM. We extract the ELMO employee_id for cross-reference during reconciliation and store it as a custom external_id field on the Candidate.

ELMO positions (GET /positions) define job titles and organisational role assignments. Where an employee holds an active position that corresponds to a hiring need in Recruit CRM, we create a Job record with the position title. The employee's current position becomes a Candidate field (current_title or similar) and a tag on the Candidate record. This is a 1:N split because one ELMO position can appear on many Candidate records and may spawn multiple Job openings.

ELMO departments (GET /departments) migrate as a custom picklist field on both Candidate and Job in Recruit CRM. The full department tree is preserved as a flat list with the hierarchy captured in a parent_department reference field. We map each ELMO employee to their primary department for tagging during migration.

ELMO locations (GET /locations) with physical address and timezone migrate to the Location field on Recruit CRM Job records. For Candidates, the location preference is stored as a Candidate custom field sourced from the employee's primary work location in ELMO.

ELMO Legal Entity records (GET /legal-entities) define ABN/ACN-level employer records for AU and NZ payroll compliance. In Recruit CRM, there is no native Legal Entity object. We store the ELMO Legal Entity as a custom Client field (legal_entity_name) and ABN/ACN as a custom Client field so that staffing agency clients linked to specific entities are traceable after migration. This is a lookup resolution because Legal Entity must exist as a Client record before Candidate assignments referencing it are imported.

ELMO employment details (GET /employment-details) — start date, employment type, pay frequency, superannuation fund — migrate as custom fields on the Candidate record in Recruit CRM. Effective start date maps to a custom date field; employment type becomes a picklist. Pay frequency and superannuation details have no native Recruit CRM equivalent and are stored as text or picklist custom fields. These fields are flagged as informational and do not drive any Recruit CRM workflow logic.

ELMO leave requests and leave balances (GET /leave-requests, BETA endpoint) are migrated as a static snapshot in custom fields on the Candidate record: annual_leave_balance, sick_leave_balance, parental_leave_balance, and leave_balance_as_of_date. Leave entitlement rules and accrual logic do not migrate because Recruit CRM has no native leave management. We cross-validate balances against the final payroll report exported from ELMO's UI before writing them. The BETA endpoint status means we treat leave data as best-effort and apply manual reconciliation where API responses are incomplete.

ELMO payroll calendars define pay periods, pay run dates and STP reporting cycles at the organisation level. Recruit CRM has no payroll calendar object. We export the calendar definition as a structured JSON configuration file delivered alongside the migration, and store the last pay run date and next pay run date as custom fields on the relevant Client or Job record for reference. Payroll calendar logic requires manual reconstruction in the customer's finance system post-migration.

ELMO groups (GET /groups) represent organisational units for access control and reporting. We migrate group membership as Candidate tags in Recruit CRM, allowing recruiters to filter candidates by the ELMO group they belonged to. Group hierarchy is flattened into the tag label. Access-control semantics from ELMO do not map to Recruit CRM's role-based model and are documented separately for the customer's admin.

ELMO configurable metadata fields (GET /configurable-fields-meta) are organisation-specific and vary per customer. We extract the full custom field schema during discovery, create equivalent custom fields in Recruit CRM (text, date, number, picklist, or checkbox), and migrate the values per Candidate record. The destination custom field type is chosen by FlitStack AI based on the source field's data type. If the destination field does not exist, we create it before the relevant Candidate batch is imported.