HRMS migration
Field-level mapping, validation, and rollback between HROffice and Recruit CRM & ATS. We move data and schema; workflows are rebuilt natively in Recruit CRM & ATS.
HROffice
Source
Recruit CRM & ATS
Destination
Compatibility
10 of 12
objects map 1:1 between HROffice and Recruit CRM & ATS.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from HROffice to Recruit CRM is a structural migration for staffing-focused organizations. HROffice organizes placement data around Assignments and weekly timecard cycles for temporary workers; Recruit CRM follows standard ATS conventions with Candidates, Applications, and Job Postings. We do not force Assignments into a continuous employee record model. Instead we export Assignments as related supplemental metadata and attach them to the migrated Candidate in Recruit CRM, preserving placement type, duration, and timecard history as custom fields or notes. Recruit CRM's API access at the Business tier ($119/user/mo) unlocks the REST endpoints needed for programmatic migration; the Team tier ($85/user/mo) requires manual import. We do not migrate branded career site content, automated workflows, or referral tool configurations as these are platform-specific and do not carry over to Recruit CRM.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a HROffice object lands in Recruit CRM & ATS, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
HROffice
Candidate
Recruit CRM & ATS
Candidate
1:1HROffice Candidate records map directly to Recruit CRM Candidate. We export standard fields including name, email, phone, address, skills, experience, and application history. The mapping is straightforward for fields that exist in both systems; custom fields on Candidate may require prioritization if the customer's Recruit CRM plan is Team tier (15-field limit per entity) versus Business tier (50 fields). We flag any HROffice custom candidate fields exceeding the destination tier limit during scoping and work with the customer to prioritize or restructure.
HROffice
Application
Recruit CRM & ATS
Application
1:1HROffice Applications tied to open Job Postings map to Recruit CRM Applications. Each Application carries the candidate reference, job reference, application date, status pipeline, and recruiter notes. Status values from HROffice's application pipeline map to Recruit CRM's candidate pipeline stages, with the mapping defined during scoping based on the customer's specific stage names.
HROffice
Job Posting
Recruit CRM & ATS
Job
1:1HROffice Job Postings map to Recruit CRM Jobs. Job content including title, description, requirements, location, department, and employment type migrate directly. Employer branding, custom career site fields, and embedded media tied to HROffice's career site builder do not carry over; these are platform-specific assets that require recreation in Recruit CRM's job posting interface.
HROffice
Assignment
Recruit CRM & ATS
Candidate (supplemental metadata)
lossyHROffice Assignment records represent temporary or temp-to-perm placements with start dates, end dates, assignment type, and placement status. This is a staffing-agency-specific concept without a direct Recruit CRM equivalent. We export Assignments as supplemental metadata and attach them to the migrated Candidate record as custom fields (assignment_type, assignment_start_date, assignment_end_date, placement_status) or as structured notes. This preserves the staffing history without forcing placement records into a standard employment model that Recruit CRM does not support.
HROffice
Timecard
Recruit CRM & ATS
Candidate (supplemental notes or custom fields)
lossyHROffice timecard records capture hours worked and submission dates for temporary workers on assignment. Recruit CRM has no native timecard object. We export timecard history as a structured note on the related Candidate record or as custom fields (weekly_hours, timecard_submission_date, pay_period) if the customer's data volume and Recruit CRM tier support it. Recruit CRM's invoice management feature can handle billing for placed candidates but does not replace payroll cycle tracking.
HROffice
User
Recruit CRM & ATS
User
1:1HROffice internal Users (recruiters, administrators) are separate from the candidates placed through the platform. User records carry role-based permissions and name/email. We export active User accounts for reconciliation against Recruit CRM User provisioning. Inactive HROffice users are exported as a reference list for the customer's admin to provision or archive in Recruit CRM after migration.
HROffice
Benefits
Recruit CRM & ATS
Candidate (custom fields)
1:1HROffice benefit enrollment records include plan assignments, coverage type, and effective dates for placed workers. These map to custom fields on the Candidate record in Recruit CRM if the destination tier supports the field count. We export benefit data as structured key-value fields or as a supplemental notes section on the candidate, depending on the volume and Recruit CRM plan constraints.
HROffice
Compensation
Recruit CRM & ATS
Candidate (custom fields)
1:1HROffice compensation records include pay type (hourly, salary), rate, currency, and effective dates for temporary placements. These map to custom fields on the Candidate record in Recruit CRM (pay_type, hourly_rate, salary, currency, compensation_effective_date). We standardize currency values to the primary currency used in the Recruit CRM instance during the transform step.
HROffice
Company
Recruit CRM & ATS
Client
1:1HROffice Company records (client organizations that post jobs or receive placements) map to Recruit CRM Client records. Company name, address, industry, contact information, and notes migrate directly. The mapping uses company name as the dedupe key during import to prevent duplicate client records.
HROffice
Contact
Recruit CRM & ATS
Contact
1:1HROffice Contact records (hiring manager or client-side contact individuals) map to Recruit CRM Contact records attached to Client organizations. Name, title, email, phone, and relationship to the client organization migrate directly. We resolve the parent Client reference during migration so that contacts are properly linked at import time.
HROffice
Job Posting (archived)
Recruit CRM & ATS
Job (archived)
1:1Archived or closed HROffice Job Postings migrate to Recruit CRM Jobs with a closed status flag. The customer's Recruit CRM plan determines whether archived jobs count against the active job posting limit. We flag any archive strategy during scoping and advise whether to migrate all historical postings or only recent ones.
HROffice
Candidate Document
Recruit CRM & ATS
Candidate Document
1:1HROffice candidate documents (resumes, CVs, attachments) migrate as linked documents to the corresponding Candidate record in Recruit CRM. We handle document extraction from HROffice's storage, validate file format compatibility, and attach each document to the correct Candidate using the candidate ID mapping established during the primary record migration.
| HROffice | Recruit CRM & ATS | Compatibility | |
|---|---|---|---|
| Candidate | Candidate1:1 | Fully supported | |
| Application | Application1:1 | Fully supported | |
| Job Posting | Job1:1 | Fully supported | |
| Assignment | Candidate (supplemental metadata)lossy | Fully supported | |
| Timecard | Candidate (supplemental notes or custom fields)lossy | Fully supported | |
| User | User1:1 | Fully supported | |
| Benefits | Candidate (custom fields)1:1 | Mapping required | |
| Compensation | Candidate (custom fields)1:1 | Mapping required | |
| Company | Client1:1 | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Job Posting (archived) | Job (archived)1:1 | Fully supported | |
| Candidate Document | Candidate Document1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
HROffice gotchas
Zero public review presence limits due diligence
API is a paid add-on, not self-service
Assignment-based data model does not map directly to standard HRMS
Recruit CRM & ATS gotchas
API rate limits are license-scaled and can throttle bulk migration
Custom field schemas vary per organization and require field-level mapping
Files and email attachments require separate extraction and re-upload
Email sequences and automation logic do not transfer between platforms
Pair-specific challenges
Migration approach
API access and credentials setup
We confirm HROffice API connectivity before any data work begins. If the customer has not purchased the API connection add-on, we coordinate with HROffice to enable it. We request API credentials (client ID, client secret, and base URL) and validate connectivity to api.hroffice.nl. On the Recruit CRM side, we confirm the customer's active plan tier (Team or Business) to determine the available custom field quota. If the customer is on the Team plan and has more than 15 custom fields on any entity in HROffice, we flag this during scoping and recommend upgrading to Business before migration begins.
Schema discovery and data audit
We audit the HROffice instance across all supported objects: Candidates, Applications, Job Postings, Assignments, Timecards, Users, Benefits, Compensation, Companies, and Contacts. We extract record counts, custom field definitions, assignment volume, and timecard history. We also identify any duplicate records, incomplete profiles, or data hygiene issues that affect migration scope. The discovery output is a written data inventory including record counts per object, custom field lists with data types, and an initial assessment of what migrates cleanly versus what requires supplemental metadata treatment.
Destination schema design and mapping specification
We design the Recruit CRM destination schema based on the customer's active plan tier. This includes defining which custom fields migrate within the tier limit, which fields require prioritization or grouping into notes, and how Assignment records attach as supplemental metadata to Candidate records. We create the object mapping specification document covering every supported HROffice object, its Recruit CRM equivalent, transform rules, and any field-level type conversions. If the customer is upgrading from Team to Business tier to accommodate field volume, we confirm the upgrade is complete before finalizing the schema.
Sandbox migration and reconciliation
We run a full migration into Recruit CRM using a test environment or a limited initial import to validate the mapping. The customer's lead recruiter or HR admin spot-checks 25-50 candidate records, application histories, and assignment metadata against the HROffice source. Any mapping corrections, field priority adjustments, or supplemental metadata handling decisions are made during this validation phase before production migration begins. The customer approves the final mapping specification at this stage.
Production migration in dependency order
We run production migration in record-dependency order. Client and Contact records migrate first to establish the organizational hierarchy. Candidate records migrate second with Assignment and Timecard data attached as supplemental metadata. Applications and Job Postings migrate third with status pipeline mappings applied. User records migrate fourth for reconciliation against Recruit CRM user provisioning. Each phase emits a row-count reconciliation report before the next phase begins. We handle document attachments (resumes, CVs) as a final phase using Recruit CRM's document upload API.
Cutover, validation, and workflow rebuild handoff
We freeze writes to HROffice during cutover, run a final delta migration of any records modified during the cutover window, then enable Recruit CRM as the system of record. We deliver a written inventory of any HROffice automated workflows, referral tool configurations, or career site customizations that require manual rebuild in Recruit CRM's settings. We do not rebuild these as part of the migration scope. We support a one-week post-migration window where we resolve any data reconciliation issues raised by the customer's team.
Platform deep dives
HROffice
Source
Strengths
Weaknesses
Recruit CRM & ATS
Destination
Strengths
Weaknesses
Complexity grading
Moderate HRMS migration. 3 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across HROffice and Recruit CRM & ATS.
Object compatibility
3 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
HROffice: Not publicly documented.
Data volume sensitivity
HROffice doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during HROffice to Recruit CRM & ATS migration scoping. Not seeing yours? Book a call.
Walk through your HROffice to Recruit CRM & ATS migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave HROffice
Other ways to arrive at Recruit CRM & ATS
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.