Extract via IntelliHR REST API (250 req/60s), transform to Oracle HDL pipe-delimited .dat files, and load in dependency order. API-to-HDL is the only viable enterprise path.
Migrating from IntelliHR to Oracle Fusion Cloud HCM requires a full data-model translation, not a simple export-and-import operation. IntelliHR uses a flat, people-centric model where Person and Job records are connected via a simple parent-child relationship, while Oracle HCM uses a deeply hierarchical structure built around Worker, WorkRelationship, WorkTerms, Assignment, Position, and Organization objects, each with strict effective-dating rules and referential integrity constraints. There is no native migration path between the two platforms; IntelliHR's CSV exports produce flat snapshots that cannot preserve relational context or custom field metadata. Full-fidelity migration at any meaningful scale requires programmatic extraction via IntelliHR's REST API combined with Oracle HCM Data Loader (HDL) .dat files, plus custom transformation logic to map IntelliHR's flat org model to Oracle's legal employer hierarchy.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Decide early whether remuneration, recruiting, learning, documents, and user provisioning
Decide early whether remuneration, recruiting, learning, documents, and user provisioning are in scope. Oracle handles these through different business objects, loaders, and module boundaries. That separation shows up directly in Oracle's endpoint and business-object structure.
Always load Oracle HCM foundation data first
Legal Employers, Business Units, Departments, Locations, Jobs, and Grades must exist before loading Workers. HDL will reject Worker.dat records that reference non-existent foundation objects.
Oracle HDL dates must use YYYY/MM/DD format
IntelliHR API returns ISO 8601 (YYYY-MM-DD). This single-character difference (/ vs -) causes silent HDL import failures — the record is skipped with no inline error. Note: Oracle REST examples may use yyyy-MM-dd, but HDL .dat files require the slash-delimited format.
Oracle HDL silently skips records that fail validation instead of aborting the entire load
Always compare your input record count against the HDL Total Objects Loaded count. A "successful" HDL load with 4,800 of 5,000 records loaded means 200 employees are missing from your system. Download the error report CSV from the data set to identify which records failed and why.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope candidates, pipelines and the compliance obligations that come with them.
Objective Agreed scope across candidates, applications, jobs and interview history, with legal signed up on retention.
Keep these open
-
Inventory every object in Intellihr
Count candidates, applications (a candidate can have many), jobs and requisitions, interviews, scorecards, offers, and resume files. Applications and scorecards usually outnumber candidates several times over, and resume files dominate storage.
Data Profiler Get real record counts instead of estimating from memory -
Settle retention and consent with legal
Candidate data is heavily regulated: GDPR right-to-erasure, EEOC/OFCCP record-keeping, and per-region retention windows that conflict with each other. Decide what may be migrated at all before you scope anything else — this frequently shrinks scope substantially.
Migrating candidate records whose consent has lapsed or whose retention window has expired creates a new compliance breach in the target system.
-
Map the hiring pipeline and agree the target stages
Document every job's pipeline, stage, and rejection reason, then agree the Oracle Fusion Cloud Hcm model with talent leadership. Stage definitions drive every funnel metric you report, so changing them silently rewrites your hiring analytics.
-
Catalogue integrations and the job-board estate
List job boards, careers-site integration, HRIS, background check, assessment platforms, calendar and email. The careers site and job boards are customer-facing, so their cutover needs its own plan and its own testing.
-
Build the business case and choose the window
Model licence delta, effort and recruiter productivity dip. Time the window against your hiring cycle: a migration during peak graduate recruitment or a hiring surge will fail on people, not technology.
Vendor Evaluator Score Oracle Fusion Cloud Hcm against alternatives on weighted criteria
Intellihr → Oracle Fusion Cloud Hcm specifics
- Enterprise consolidation
- Organizations scaling beyond IntelliHR's mid-market sweet spot need Oracle HCM's payroll, benefits, and workforce management modules in a single platform.
- Compliance requirements
- Oracle HCM's legislative data groups, localization packs, and audit trails satisfy regulatory requirements (SOX, country-specific labor law reporting) IntelliHR was not designed to handle.
- Integration ecosystem
- Oracle HCM integrates natively with Oracle ERP, EPM, and EBS — critical for organizations already running Oracle's finance stack.
- Org complexity
- Multi-legal-employer structures, global assignments, and matrix reporting hierarchies exceed IntelliHR's modeling capabilities.
- Historical depth
- Do you need 10 years of job history or just current active records? Oracle HCM can load historical data, but every effective-dated row increases complexity. Bring as little historical baggage as compliance allows.
Don't move on until
- Counts confirmed for candidates, applications, jobs and offers
- Retention and consent obligations confirmed with legal
- Hiring-stage model agreed with talent leadership
02 Data Audit Audit candidate data with compliance sitting next to you.
Objective Profiled exports with duplicates, expired records and resume files all quantified and triaged.
Keep these open
-
Export and profile candidates, applications and jobs
Profile each object separately and reconcile against API counts. Watch the candidate-to-application ratio: a mismatch usually means applications have been silently truncated by pagination.
Data Profiler Profile the Intellihr export for nulls, outliers and type drift -
Quantify duplicate candidates and agree survivorship
The same person applies repeatedly over years with different emails and name spellings. Measure the duplicate rate and agree survivorship rules — which record wins and what happens to the application history attached to the losers.
Merging candidates without agreed survivorship rules destroys application and interview history that you may be legally required to retain.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Identify records outside their retention window
Flag candidates whose consent has expired, who have exercised erasure, or who fall outside regional retention. Exclude them from scope and document the exclusion — you need to show the decision was deliberate.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Inventory resume files and attachments
Count files, total volume and MIME types, and check every attachment still resolves to a live URL. Expiring signed download URLs are the classic reason a resume migration completes with a large fraction of empty files.
Resume download URLs are often short-lived signed links. Fetch files close to load time or they will 404 mid-migration.
-
Verify relationship integrity
Confirm every application links to a live candidate and a live job, and every scorecard to a real interview. Orphaned applications produce a funnel report that does not tie to anything.
-
Clean, normalise and produce masked test data
Normalise emails, phone formats and locations, standardise timestamps to UTC, and generate a masked dataset for the sandbox. Real candidate data in a sandbox is a compliance breach in most jurisdictions.
PII Masker Generate a safe copy for sandbox and vendor testing
Don't move on until
- Duplicate candidate rate quantified with a merge policy agreed
- Records outside retention identified and excluded
- Resume and attachment inventory complete with total volume
03 Field Mapping Map the candidate-application-job triangle before anything else.
Objective A signed mapping covering objects, stages, rejection reasons, scorecards and EEO fields.
Keep these open
-
Map the candidate, application and job model
ATS platforms differ on whether a person or an application is the primary record. Establish this first: getting it wrong means one candidate becomes five, or five applications collapse into one, and the entire field map has to be redone.
Candidate-centric and application-centric models are not interchangeable. Confirm which Oracle Fusion Cloud Hcm uses before mapping any field.
Schema Mapper Opens pre-loaded with the Intellihr → Oracle Fusion Cloud Hcm field pair -
Map pipeline stages and rejection reasons exhaustively
Enumerate every stage and rejection reason across all jobs, including retired values on historical applications, and map each explicitly. Unmapped rejection reasons are both a reporting gap and, in regulated hiring, a compliance one.
-
Decide EEO and diversity data handling
These fields are separately regulated and often legally required to be stored apart from the candidate record. Confirm with legal whether they migrate at all, and how Oracle Fusion Cloud Hcm isolates them.
EEO data usually cannot be migrated into ordinary custom fields without breaching the segregation rules that govern it.
-
Map interviews, scorecards and feedback
Structured scorecards rarely have a native equivalent. Decide whether to reconstruct them, flatten them into notes, or keep them only in the archive — and be explicit that flattening loses the ability to report on them.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Plan resume and file migration
Confirm size limits, MIME support and whether Oracle Fusion Cloud Hcm re-parses resumes on upload. Re-parsing can overwrite carefully curated candidate fields with worse machine-extracted values, so test it deliberately.
-
Set load order and freeze the spec
Users, then jobs, then candidates, then applications, then interviews and scorecards, then files. Keep source IDs in custom fields, then version and sign off the spec.
Intellihr → Oracle Fusion Cloud Hcm specifics
- Custom fields
- Which are actively used vs. stale? Only migrate fields with business value.
Don't move on until
- Candidate/application/job model mapped and reviewed
- Every stage and rejection reason explicitly mapped
- EEO and diversity field handling agreed with legal
04 Test Migration Pilot whole candidate journeys, not isolated records.
Objective A sandbox pilot where candidate journeys, funnel metrics and resume files all verify.
Keep these open
-
Configure the Oracle Fusion Cloud Hcm sandbox with the agreed pipelines
Create jobs, pipeline stages, scorecard templates, user roles and custom fields first. Loading applications before the stages exist puts every candidate in a default stage and invalidates the pilot.
-
Select complete candidate journeys as the pilot slice
Take 100-200 candidates with all their applications, interviews, scorecards and files — including repeat applicants, hires, rejections at every stage, and candidates on multiple jobs. Repeat applicants are where the model mapping actually gets tested.
-
Run the load in dependency order with logging
Jobs, candidates, applications, interviews, then files, logging each request against its source ID. Track file uploads separately: they fail for different reasons and at different rates than record writes.
-
Verify journeys and funnel metrics
Confirm each candidate sits at the right stage on the right job with their history intact, and that per-stage funnel counts match Intellihr for the pilot jobs. Funnel mismatches point straight back to stage mapping.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Open every pilot resume and check re-parsing
Actually open the files rather than trusting the upload count, and check whether re-parsing has overwritten any candidate fields. A resume that uploaded as a zero-byte file still counts as a success in most logs.
-
Put recruiters in front of the pilot data
Have recruiters work their own pilot requisitions end to end. They immediately spot missing feedback, wrong stages and unreadable history that reconciliation cannot see.
Don't move on until
- Candidate-application-job relationships intact for the pilot
- Funnel counts per stage match source for pilot jobs
- Resume files open correctly for every pilot candidate
05 Cutover Switch recruiting without dropping a live candidate.
Objective All in-scope recruiting data live in Oracle Fusion Cloud Hcm, careers site and boards repointed, recruiters working.
Keep these open
-
Pre-load historical candidates and closed jobs
Load closed requisitions, rejected candidates and archived applications while Intellihr stays live. Only active pipeline and the final delta need to move in the window.
-
Publish the runbook including the careers-site switch
A timed sequence with owners and abort criteria, treating the careers site and job boards as first-class steps. They are candidate-facing, so a failure there is publicly visible in a way a data defect is not.
-
Freeze Intellihr and take the final delta
Stop new applications and let recruiters finish in-flight actions, then export everything changed since the pre-load. Coordinate with anyone actively interviewing so feedback is not entered into the old system mid-freeze.
Interview feedback entered in the old ATS during the freeze is lost, and it is the data recruiters most immediately notice missing.
-
Load active pipeline and reconcile stages
Load active candidates and applications, then verify every active candidate is at the correct stage on the correct job before repointing anything. Active-stage accuracy is what recruiters check first on day one.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint careers site, job boards and integrations
Switch the careers-site integration, repost or migrate live job ads, and repoint HRIS, background check, assessment and calendar integrations. Then submit a real test application through the careers site and every major board.
Job ads left posted against the old ATS keep collecting applications that never reach the new system.
-
Go/no-go and switch recruiters over
Call the decision against the exit criteria, then move recruiters with support on hand for the first day. Keep Intellihr read-only — candidate records have retention obligations that outlast the migration.
Don't move on until
- Historical load complete and reconciled before the freeze
- Careers site and job boards posting into Oracle Fusion Cloud Hcm and verified
- Active candidates confirmed at the correct stage
06 Validation Prove the funnel, the files and the compliance position.
Objective Reconciled recruiting data, funnel parity with baseline, and a defensible compliance record.
Keep these open
-
Reconcile every object including files
Compare counts for candidates, applications, jobs, interviews, scorecards and files, with field-level spot checks on a sample. Count files separately — they are the object most likely to be quietly short.
Migration Validation Tool Reconcile Intellihr and Oracle Fusion Cloud Hcm record-for-record -
Tie funnel and time-to-hire reporting to baseline
Rebuild funnel conversion, time-to-hire, source effectiveness and offer-acceptance reporting and compare to pre-migration figures. Variances trace back to stage mapping and to how application timestamps were handled.
Time-to-hire depends on stage-transition timestamps. If those were approximated, the metric will differ even with identical records.
-
Verify file integrity at scale
Sample-open resumes across the whole load and compare file sizes against source. Zero-byte and truncated files are common and never surface in an upload success count.
-
Confirm retention, consent and EEO configuration
Verify retention rules, consent state and EEO segregation are correctly configured in Oracle Fusion Cloud Hcm, and that excluded records genuinely did not migrate. File this as your compliance evidence.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test workflow, notifications and candidate-facing paths
Fire every stage automation, interview scheduling flow, rejection template and offer approval, and submit a live application through the careers site. Candidate-facing emails going out wrong is a brand problem, not just a bug.
-
Sign off and schedule decommission
Get written acceptance against the Discovery criteria, retain Intellihr read-only for the period your retention policy requires, take a final archive export, and diarise cancellation.
-
Rebuild workflows
IntelliHR onboarding workflows, approval chains, and notifications don't migrate. Rebuild in Oracle HCM's Transaction Design Studio.
-
Monitor for data drift
Run weekly reconciliation reports for the first 30 days to catch any records that slipped through or were modified incorrectly.
Intellihr → Oracle Fusion Cloud Hcm specifics
- Reconfigure integrations
- Any payroll, ATS, or LMS integrations pointing at IntelliHR must be redirected to Oracle HCM. Prefer HCM Extracts and Atom feeds for ongoing delta detection instead of worker-REST polling. (docs.oracle.com)
- User training
- Oracle HCM's navigation and terminology differ significantly from IntelliHR. Budget dedicated training sessions, particularly around the work-relationship and assignment model — that's where post-cutover tickets concentrate.
- Decommission IntelliHR
- Keep the IntelliHR instance read-only for 90 days post-migration for reference, then archive and terminate.
- Recruiting endpoints
- If recruiting is in scope, validate Oracle Recruiting Cloud API availability separately; some recruiting endpoints may have limited support. For recruiting-specific migration patterns, see Taleo to Oracle Recruiting Cloud Migration: The CTO's Technical Guide.
Don't move on until
- Reconciliation complete across candidates, applications and files
- Funnel and time-to-hire reporting tie to baseline
- Retention and EEO configuration verified, acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Object Object
| Intellihr field | Oracle Fusion Cloud Hcm field | Notes |
|---|---|---|
| Person | Worker (Person component) | 1:1 mapping; PersonName, PersonAddress, PersonEmail are child components |
| Job | Assignment (under Work Relationship → Employment Terms) | Requires WorkRelationship and WorkTerms wrappers |
| Business Entity | Legal Employer | Must be pre-configured in Oracle HCM; cannot be loaded via HDL |
| Business Unit | Business Unit / Department | Oracle separates these — Business Units are org-level, Departments are assignment-level |
| Location | Location | Direct mapping; loaded via Location.dat |
| Pay Grade / Remuneration | Grade / Salary | Oracle uses Grade → Grade Rate; Salary is a separate business object |
| Custom Fields (Person) | Person DFF / EFF | Must configure flexfield segments in Oracle before loading |
| Custom Fields (Job) | Assignment DFF / EFF | Same — configure first, load second |
| Training Records | Learning Record (Oracle Learning) | Different module; may require separate migration |
| Qualifications | Person Qualification | Loaded via Worker.dat PersonQualification component |
| Documents / Attachments | Document of Record / Attached Documents | Separate upload process; not part of Worker.dat |
| Diary Notes | Person Note | Loaded via Worker.dat PersonNote component |
IntelliHR Oracle HCM
| Intellihr field | Oracle Fusion Cloud Hcm field | Notes |
|---|---|---|
| firstName | FirstName | Direct |
| lastName | LastName | Direct |
| displayName | DisplayName | Direct |
| dateOfBirth | DateOfBirth | Format: YYYY/MM/DD |
| primaryEmailAddress | EmailAddress | Map EmailType = W1 for work |
| phoneNumber | PhoneNumber | Map PhoneType = W1 for work |
| address | AddressLine1, TownOrCity, PostalCode | Decompose; set AddressType = HOME |
| employeeNumber | PersonNumber | Use as source key; load only if not auto-generated |
| startDate | LegalEmployerSeniorityDate | Format: YYYY/MM/DD |
| endDate | ActualTerminationDate | Null if active |
| jobTitle | BusinessTitle | Map to Job.dat reference or BusinessTitle |
| businessUnit | BusinessUnitName | Must match pre-loaded Business Unit |
| location | LocationCode | Must match pre-loaded Location |
| employmentType | AssignmentCategory | Map: Full-Time → FR, Part-Time → PR (verify against your Oracle lookup — values vary by legislation) |
| reportsTo | ManagerPersonNumber | Requires manager loaded first |
| baseSalary | SalaryAmount | Requires linked Salary Basis |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Worker / Person Records | medium | Core identity and contact data maps reasonably between IntelliHR's Person object and Oracle's Worker and PersonName components, but effective-date sequencing and required fields such as Legal Employer must be resolved before load. |
| Job / Assignment History | high | IntelliHR Job records must be expanded into Oracle's WorkRelationship, WorkTerms, and Assignment components with individual effective-dated rows per change event, and any gaps or overlaps in job history will cause HDL load failures or silent data truncation. |
| Remuneration / Compensation Data | high | IntelliHR remuneration records use a flat structure that does not align with Oracle's Salary or Compensation business objects, and currency, frequency, and component-type mappings must be manually defined with no guaranteed one-to-one field correspondence. |
| Custom Fields | high | IntelliHR custom fields have no automatic migration path to Oracle Flexfields; each field requires manual configuration of the target flexfield context and segment in Oracle HCM before data can be loaded, creating a high risk of data loss if the mapping is incomplete. |
| Org Structure (Business Units, Locations) | high | Oracle HCM enforces strict referential integrity against foundation data, so all Legal Employers, Business Units, Departments, and Locations must be created and validated in Oracle before any worker records referencing them can be loaded. |
| Qualifications and Training Data | medium | IntelliHR exports qualifications and training records via CSV and API, but these map to Oracle Learning and Profile business objects that reside in separate modules with distinct HDL templates and loader files from core HR. |
| Attachments and Documents | high | IntelliHR's document and attachment data has no CSV export path and is not exposed fully through the standard Data Import/Export tool, requiring direct API extraction and Oracle BlobFiles/ClobFiles handling in HDL, which is a non-trivial technical implementation. |
| Performance and Goals Data | medium | IntelliHR's performance management data maps to Oracle's Goal Management and Performance modules, which use separate business objects and loaders not covered by core HR HDL templates, increasing scope and complexity. |
| User Accounts and Access Provisioning | medium | IntelliHR user accounts and role assignments do not map directly to Oracle HCM's role-based access control model, requiring manual reprovisioning of user roles, data access groups, and security profiles in Oracle Identity Governance or Oracle HCM Security. |
| Historical Effective-Dated Records | high | Any historical job changes, promotions, or transfers stored as date-effective rows in IntelliHR must be reconstructed as separate effective-dated transactions across all relevant Oracle HCM components, and incorrect date sequencing will cause Oracle to reject entire worker record sets during HDL processing. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Flat-to-Hierarchical Model Mapping
IntelliHR's two-level Person-to-Job structure must be decomposed and reconstructed into Oracle HCM's five-level Worker hierarchy, requiring custom transformation logic to derive WorkRelationship, WorkTerms, and Assignment records from a single IntelliHR Job record.
Org Structure Hierarchy Translation
IntelliHR's loosely structured Business Entities, Business Units, and Locations must be mapped to Oracle's strictly enforced Legal Employer → Business Unit → Department → Location hierarchy, which requires all foundation data to exist in Oracle before worker records can be loaded.
Custom Field to Flexfield Conversion
IntelliHR's custom fields on Person and Job objects have no automatic equivalent in Oracle HCM and must be manually mapped to the appropriate Extensible Flexfields (EFF) or Descriptive Flexfields (DFF), including defining the flexfield context and segment configuration in Oracle first.
HDL File Format Compliance
Oracle HCM Data Loader requires strictly formatted pipe-delimited <code>.dat</code> files with correct METADATA headers, source keys, and file discriminators packaged in <code>.zip</code> archives, and formatting errors frequently cause silent failures rather than explicit error messages.
Effective-Dating Across All Objects
While IntelliHR applies effective dating only to Job records, Oracle HCM enforces effective-dated history across every business object in the Worker hierarchy, meaning historical job changes must be reconstructed into multiple dated rows per object rather than a single current-state record.
IntelliHR API Rate Limit Constraints
IntelliHR's REST API is rate-limited to 250 requests per 60 seconds by default, requiring extraction pipelines to implement pagination, throttling, and retry logic to safely extract large workforce datasets including jobs, remuneration, qualifications, and training records without hitting limits.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How do I migrate data from IntelliHR to Oracle Fusion Cloud HCM?
Extract data via IntelliHR's REST API (People, Jobs, Locations, Business Units), transform JSON to Oracle HDL pipe-delimited .dat format, package as .zip, and load through Oracle's HCM Data Loader. Foundation data (Locations, Departments, Legal Employers) must be loaded before Workers.
What are IntelliHR's API rate limits for data extraction?
IntelliHR's public API limits requests to 250 per 60 seconds per tenant. When exceeded, the API returns HTTP 429. You can request an increase through your IntelliHR Account Manager. Implement exponential backoff using the X-RateLimit-Reset response header.
Can I use CSV exports instead of APIs for this migration?
Yes, for small tenants under 500 employees with standard fields. But CSV exports flatten relational data, and Oracle's HSDL is single-object per spreadsheet and not attachment-friendly. For history-heavy or document-heavy migrations, API-based extraction into HDL is the safer path.
How do IntelliHR custom fields map to Oracle Fusion Cloud HCM?
Oracle HCM does not support custom objects. IntelliHR custom fields must be mapped to Oracle's Descriptive Flexfields (DFF) or Extensible Flexfields (EFF) on existing business objects. The flexfield segments must be configured and deployed in Oracle before data can be loaded.
Should I use Oracle REST APIs or HCM Data Loader for bulk employee data?
Use HCM Data Loader. Oracle explicitly recommends HDL and HCM Extracts for bulk operations. Worker create or update calls via REST can take minutes due to post-processing and are not designed for high-volume loads.