---
title: "Taleo to Oracle Recruiting Cloud Migration: The CTO's Technical Guide"
slug: taleo-to-oracle-recruiting-cloud-migration-the-ctos-technical-guide
date: 2026-04-21
author: Raaj
categories: [Migration Guide, Taleo]
excerpt: "A CTO-level guide to migrating from Taleo to Oracle Recruiting Cloud, covering TCC export limits, HCM Data Loader constraints, object mapping, and real API trade-offs."
tldr: "Taleo to ORC migration is schema translation, not a lift-and-shift. TCC's 500K/day limit and HDL's validation rules are the primary bottlenecks — plan for hybrid API + file-based extraction."
canonical: https://clonepartner.com/blog/taleo-to-oracle-recruiting-cloud-migration-the-ctos-technical-guide/
---

# Taleo to Oracle Recruiting Cloud Migration: The CTO's Technical Guide


Migrating from Oracle Taleo to Oracle Recruiting Cloud (ORC) is a schema-translation and platform-unification problem. Taleo is a standalone ATS with a deeply nested, SOAP-based data model where Requisitions, Candidates, and Submissions form complex relational chains. ORC is a natively integrated recruiting module within Oracle HCM Cloud, sharing core data structures — organizations, jobs, positions, locations — directly with HCM Core. The foundational data that Taleo manages independently must be reconciled against an entirely different source of truth.

If you need a fast decision: **Taleo Connect Client (TCC) CSV exports cannot preserve nested relational data or binary attachments.** TCC imposes a hard limit of 500,000 extracted records per day and 100,000 per extraction transaction — a bottleneck that can stretch multi-million-record migrations across weeks. On the target side, **ORC's HCM Data Loader (HDL) only creates job applications in the first phase and state of the candidate selection process** and does not support loading job applications with offers in the same load. ([docs.oracle.com](https://docs.oracle.com/cd/E56931_01/trans/hcm/F77414-01/hcm-data-loading-business-objects.pdf)) API-based extraction combined with HDL for ingestion is the only full-fidelity path at enterprise scale.

The relationship chain that matters is **Requisition → Candidate → Submission → Offer → Attachment**. That graph is where bad migrations lose context, break compliance history, and silently orphan candidate records. This guide covers the real API constraints on both sides, object-by-object mapping, every viable migration method, and the edge cases that cause silent data loss.

For a broader HRIS migration perspective, see [The Ultimate HRIS Data Migration Checklist](https://clonepartner.com/blog/blog/hris-data-migration-checklist/). If you are evaluating Workday as an alternative target, see [Taleo to Workday Migration: The CTO's Technical Guide](https://clonepartner.com/blog/blog/taleo-to-workday-migration-the-ctos-technical-guide/).

> [!WARNING]
> **Oracle does not provide a native migration path from Taleo to ORC.** Oracle Consulting explicitly tells customers not to think of Taleo-to-ORC as a lift-and-shift. Conversion of candidate data must be done by customers themselves or by a partner. ([static.rainfocus.com](https://static.rainfocus.com/oracle/ocw24/sess/1718320834490001S04m/finalsessionfile/Taleo%20to%20ORC_Session_THR3486_FINAL_1724765704441001pQHT.pdf))

## Why the Taleo to ORC Migration Is Inevitable

Taleo — officially "Oracle Talent Acquisition Cloud" (OTAC) — was the dominant enterprise ATS for over a decade. Oracle acquired it in 2012 and, starting with release 18B in 2018, began shipping Oracle Recruiting Cloud as the replacement module within HCM Cloud.

The practical signals are clear:

- **Feature freeze.** New feature development for Taleo has stopped. Updates are limited to security patches and critical bug fixes. All product innovation is going into ORC.
- **Commercial pressure.** Oracle's February 1, 2026 Taleo price list shows Taleo Enterprise and Taleo Midsize are **no longer available to new customers**. Multiple Oracle partners report that existing Taleo renewals are becoming increasingly difficult to secure, with Oracle steering customers toward ORC. ([oracle.com](https://www.oracle.com/bh/a/ocom/docs/corporate/pricing/oracle-taleo-cloud-global-price-list.pdf))
- **Component sunsetting.** Oracle already retired Taleo Performance (December 2020, due to Flash dependency) and the legacy Taleo Career Website (May 2024). The pattern is unmistakable.
- **Integration tax.** Taleo requires dedicated integrations for foundational data — organizations, locations, job functions, requisition templates, position details, and new hires. ORC eliminates most of these because it natively shares HCM Core structures. Baker Tilly notes that "the number of integrations needed to maintain the system decreases dramatically" when moving to ORC. ([bakertilly.com](https://www.bakertilly.com/insights/6-reasons-to-move-to-oracle-recruiting-cloud-from-taleo))

Oracle has not published a formal end-of-life date for Taleo Enterprise Edition. But the de facto sunset is already underway. Delaying the migration means accumulating more historical data behind an API with hard extraction limits, while ORC's quarterly release cadence continues to widen the feature gap.

For compliance implications during candidate data transfers, see [Ensuring GDPR & CCPA Compliance When Migrating Candidate Data](https://clonepartner.com/blog/blog/ats-migration-gdpr-ccpa-compliance/).

## Taleo vs. ORC: Architectural and Data Model Differences

This is the core of why migration is hard. Taleo and ORC are architecturally different systems, not different versions of the same product.

### Taleo's Standalone Model

**Taleo Enterprise Edition** is a self-contained ATS with its own data model, its own foundational data (organizations, locations, job fields), and its own integration layer. Taleo Connect Client (TCC) uses **SQ-XML**, a proprietary XML query language, and sends proprietary **T-XML** messages wrapped in SOAP. ([docs.oracle.com](https://docs.oracle.com/en/cloud/saas/talent-acquisition/17.6/otccu/introduction.html))

Key entities:

- **Requisition** — the job opening, with workflow states, approval chains, and posting configuration
- **Candidate** — the person record, with profile data, education, experience, and attachments
- **Submission** — the join object linking a Candidate to a Requisition, carrying workflow state (CSW steps), offer data, and screening results
- **Offer** — nested under Submission, with compensation, start date, and approval chain

Relationships are deeply nested. A single Candidate can have multiple Submissions across multiple Requisitions, each with independent workflow state, offers, and attachments.

### ORC's HCM-Integrated Model

**Oracle Recruiting Cloud** is a module within Oracle Fusion Cloud HCM. It does not maintain its own foundational data — it inherits organizations, jobs, positions, locations, grades, and work structures from HCM Core. Key entities:

- **Job Requisition** — references HCM Job, Position, Organization, and Location objects directly
- **Candidate** — a person record within the HCM person model (can convert directly to Worker upon hire)
- **Job Application** (`CandidateJobApplication`) — the equivalent of Taleo's Submission, linking a Candidate to a Job Requisition. HDL identifies it with the composite user key `RequisitionNumber + CandidateNumber`
- **Offer** — structured within the Job Application lifecycle

### Why 1:1 Mapping Fails

The fundamental mismatch: Taleo's foundational data — org structures, job functions, location hierarchies — is **standalone**. ORC's equivalent data lives in **HCM Core**. You cannot import Taleo organizations directly into ORC. You must map them to existing HCM organizations, or create the HCM foundation data first.

In the older Fusion HCM-to-Taleo coexistence model, HCM exported Departments, Jobs, Business Units, Users, Employees, Locations, Positions, Grades, Legal Employers, and Job Families into Taleo targets. That mapping is the clue that a 1:1 reverse migration into ORC does not exist — many Taleo fields that looked first-class in the source are either synced HCM structures or old user-defined selections that now need to become HCM setup, CSP configuration, or flexfields. ([docs.oracle.com](https://docs.oracle.com/en/cloud/saas/human-resources/faihm/exporting-data-to-oracle-taleo-recruiting-cloud-service.html))

| Dimension | Taleo | ORC |
|---|---|---|
| **Foundation data** | Self-contained (own orgs, locations, job fields) | Inherited from HCM Core |
| **Integration layer** | SOAP + TCC (T-XML, SQ-XML) | REST API + HCM Data Loader (.dat files) |
| **Workflow engine** | Highly customizable CSW (Candidate Selection Workflow) | Standardized selection process with phases |
| **Custom fields** | UDFs (User Defined Fields) on most entities | Extensible Flexfields (EFF) on supported entities |
| **Attachments** | Base64-encoded, gzip-compressed in SOAP XML | Standard file upload via REST or HDL |
| **Candidate → Employee** | Requires integration to push hire into HRIS | Native conversion within HCM |

> [!NOTE]
> **Why flat Taleo exports mislead teams:** In Oracle's own documentation, a candidate with two work experiences and three education elements produces six rows in XML/CSV-report mode because n-ary relations multiply rows. CSV-entity mode avoids row multiplication but serializes multivalue relations into single columns and does not support joining or grouping. ([docs.oracle.com](https://docs.oracle.com/en/cloud/saas/talent-acquisition/19b/otccu/using-connect-client.pdf))

## Migration Methods: TCC, HDL, APIs, and Third-Party Tools

There are five primary ways to move data from Taleo to ORC. Each carries specific engineering trade-offs.

### Method 1: TCC Export → HDL Import (File-Based)

**How it works:** Use TCC to export data as CSV/XML files. Transform the data offline — clean, map fields, restructure. Package into HCM Data Loader .dat files (pipe-delimited). Upload .zip files to ORC via WebCenter Content.

**When to use it:** One-time historical migration of structured data where you have internal TCC expertise and limited data volume.

**Key constraints:**
- TCC imposes a **maximum of 500,000 extracted records per day**, **100,000 records per extraction transaction**, and **50,000 imported records per day** in the basic offering ([docs.oracle.com](https://docs.oracle.com/en/cloud/saas/taleo-enterprise/20b/otccu/appendix.html))
- TCC does not natively export file attachments — you need the TCC Custom Steps library (`ExtractAttachedFilePostStep`) to decode Base64-compressed attachments
- HDL .dat files have a practical size ceiling — official documentation states 2GB, but Oracle Support has indicated the actual enforced limit may be under 1GB
- HDL imports to staging tables first, then loads to application tables — if any component of a logical object fails validation, the entire object fails

**Complexity:** High. Requires deep knowledge of both Taleo's data model and HCM's business object hierarchy.

For more on CSV-based migration limitations, see [Using CSVs for SaaS Data Migrations: Pros and Cons](https://clonepartner.com/blog/blog/csv-saas-data-migration/).

### Method 2: API-Based Migration (Taleo SOAP → ORC REST + HDL)

**How it works:** Extract data programmatically via Taleo's SOAP web services. Transform in-flight using a canonical staging model. Load into ORC via HCM REST API endpoints or automated HDL drops.

**When to use it:** When you need to preserve complex relational data (submission chains, attachment metadata) and have engineering capacity to build custom scripts.

**Key constraints:**
- Taleo Enterprise Edition uses SOAP web services — the REST API is only available for Taleo Business Edition
- ORC REST API uses OAuth 2.0 authentication and enforces rate limiting (429 errors on threshold breach)
- ORC REST endpoints cover candidates (`/recruitingCandidates`), job requisitions (`/recruitingJobRequisitions`), and job applications, with child resources for attachments, education, experience, and skills
- Not all ORC data is writable via REST — some recruiting objects are only loadable through HDL
- Some candidate-facing and job-site attachment endpoints are restricted to approved Oracle Cloud Marketplace partners ([docs.oracle.com](https://docs.oracle.com/en/cloud/saas/human-resources/25b/farws/api-recruiting-job-site-candidates-attachments-candidates.html))

**Complexity:** High. Best suited for teams with integration development experience.

### Method 3: Hybrid (TCC Export + Custom ETL + HDL/REST Import)

**How it works:** Extract via TCC in bulk. Run a custom ETL pipeline (Python, Node.js, or Oracle Integration Cloud) to transform and map data. Load via HDL for bulk records and REST API for incremental updates or records requiring real-time validation.

**When to use it:** Enterprise migrations with millions of records, complex custom fields, and attachments. This is the approach most experienced migration teams use.

**Key constraints:**
- Requires orchestrating multiple tools and managing state across extraction, transformation, and loading phases
- HDL supports multi-threaded loading with tunable throughput: default load group size 100, maximum concurrent import threads 8, maximum concurrent load threads 8, transfer group size 100,000 ([docs.oracle.com](https://docs.oracle.com/en/cloud/saas/human-resources/25b/fahdl/hcm-data-loader.pdf))
- You must sequence loads carefully: foundation data → candidates → job requisitions → job applications → offers → attachments
- HDL job submission can be automated via the `dataLoadDataSets` API for repeatable runs ([docs.oracle.com](https://docs.oracle.com/en/cloud/saas/human-resources/faadm/automate-the-loading-of-hdl-files.html))

**Complexity:** Very High. But it is the only method that handles full-fidelity migration at scale.

### Method 4: System Integrator (SI) Managed Migration

**How it works:** Engage an Oracle partner (Mastek, Baker Tilly, Elire, Accenture, etc.) to handle the full Taleo-to-ORC transition, typically bundled with ORC implementation and change management.

**When to use it:** When you are doing a full HCM Cloud implementation alongside the recruiting migration.

**Key trade-offs:**
- SIs focus on system configuration, process redesign, and change management — historical data migration is often treated as a secondary workstream
- Timelines of 12–24 months are common for full HCM transformations
- Data migration quality varies significantly between SI teams — budget allocation for migration is typically 10–15% of the project

**Complexity:** Medium (for your team), but cost is high and data fidelity depends entirely on the SI's migration sub-team.

### Method 5: Middleware / Integration Platforms (iPaaS)

**How it works:** Use Oracle Integration Cloud (OIC), MuleSoft, or similar iPaaS to orchestrate the data flow between Taleo and ORC.

**When to use it:** Organizations already invested in OIC who want ongoing sync during a phased rollout, or for orchestrating delta loads during parallel running.

**Key constraints:**
- OIC offers a Taleo adapter that can export bulk data in CSV or XML, and an HCM adapter that can submit HDL jobs — but schema mapping and HDL-compatible file generation remain your responsibility ([docs.oracle.com](https://docs.oracle.com/en/cloud/paas/integration-cloud/talent-acquisition-cloud-adapter-user/oracle-talent-acquisition-cloud-capabilities.html))
- Consumer-grade tools (Zapier, Make) do not have Taleo Enterprise Edition connectors and lack the depth to handle HDL's .dat format
- Best for ongoing sync scenarios, not one-time bulk historical migration

**Complexity:** Medium to High.

### Migration Method Comparison

| Method | Bulk Historical Data | Attachments | Relationships | Scalability | Complexity | Typical Timeline |
|---|---|---|---|---|---|---|
| TCC → HDL (file-based) | ✅ | ⚠️ Requires Custom Steps | ⚠️ Manual re-linking | Bottlenecked by 500K/day limit | High | 4–12 weeks |
| API-to-API (SOAP → REST) | ⚠️ Slow for bulk | ✅ | ✅ Best fidelity | Limited by rate limits | High | 6–16 weeks |
| Hybrid (TCC + ETL + HDL/REST) | ✅ | ✅ | ✅ | Best for enterprise | Very High | 4–10 weeks |
| System Integrator | ✅ | Varies | Varies | Varies | Medium (outsourced) | 12–24 months |
| Middleware (OIC/iPaaS) | ⚠️ Not ideal for bulk | ✅ | ✅ | Good for ongoing sync | Medium–High | 8–16 weeks |

### Scenario Recommendations

- **Enterprise with millions of records + attachments:** Hybrid (TCC + ETL + HDL/REST) or a dedicated managed migration service.
- **Mid-market, <100K candidates, no attachments:** TCC → HDL file-based with careful field mapping.
- **Already engaged with an SI for HCM implementation:** Push the SI to dedicate a separate data migration workstream with its own QA cycle.
- **Ongoing sync needed during parallel run:** OIC or custom API integration — not Zapier-class tools.
- **Dedicated dev team with months of bandwidth:** Custom ETL is viable only if you need repeatable sync or extreme transformation control after go-live.

## Pre-Migration Planning: Auditing Your Taleo Data

Before writing a single line of extraction code, audit what you actually have in Taleo. Most instances accumulate 10–15+ years of candidate data, much of which is garbage.

### Data Audit Checklist

| Entity | What to Audit | Action |
|---|---|---|
| **Candidates** | Total count, duplicate profiles, incomplete records, GDPR/CCPA-affected records | Deduplicate, purge expired data per retention policy |
| **Requisitions** | Open vs. closed vs. cancelled, template requisitions, test data | Exclude templates and test data from migration scope |
| **Submissions** | Submissions per candidate, workflow state distribution, incomplete submissions | Decide whether to migrate incomplete/withdrawn submissions |
| **Offers** | Accepted vs. declined vs. expired | Typically only migrate accepted offers for historical record |
| **Attachments** | Resumes, cover letters, offer letters — total file count and storage volume | Profile attachment sizes; plan for Base64 decode/decompress |
| **Custom Fields (UDFs)** | Count, data types, usage frequency | Map to ORC Extensible Flexfields (EFF) or drop unused fields |
| **Workflows (CSW)** | Custom steps, statuses, routing rules | Cannot migrate directly — must redesign in ORC's selection process |
| **Integrations** | Job boards, onboarding, analytics, background checks, agency workflows | Plan for rebuild against ORC's REST API or HCM Extracts |

> [!WARNING]
> **Migrate operating history; archive reporting history.** Oracle's own HDL guidance says not to load historic job applications just for reporting, and Oracle Consulting's Taleo-to-ORC material explicitly lists "all data needs to move" as a misconception. Move what recruiters must work with in ORC. Archive the long tail elsewhere. ([docs.oracle.com](https://docs.oracle.com/cd/E56931_01/trans/hcm/F77414-01/hcm-data-loading-business-objects.pdf))

### Migration Strategy

- **Big bang:** Migrate everything in a single cutover weekend. Works if your dataset is manageable (<500K candidates) and you can freeze recruiting activity during the window.
- **Phased:** Migrate foundation data and active requisitions first, then historical data in batches. Allows parallel running of both systems during transition.
- **Incremental:** Continuous sync from Taleo to ORC during a parallel-run period. Architecturally the most complex — requires API-based extraction and careful state management.

For most enterprises, **phased migration** with a hard cutover date is the right balance of risk and speed. Run both systems in parallel for 2–4 weeks, migrating active data first and backfilling historical records after go-live.

Candidate-data retention and consent rules deserve their own stream. See [Ensuring GDPR & CCPA Compliance When Migrating Candidate Data](https://clonepartner.com/blog/blog/ats-migration-gdpr-ccpa-compliance/).

## Taleo to ORC Object and Field Mapping

This is the make-or-break section. Every field mapping decision has downstream consequences. The safe principle: **map candidacies, not just people**.

### Core Object Mapping

| Taleo Object | ORC / HCM Equivalent | Notes |
|---|---|---|
| Requisition | Job Requisition | Must link to HCM Job, Position, Organization, Location. Taleo's standalone org/location data must be pre-mapped. |
| Candidate (external) | Recruiting Candidate | External candidates load through `Candidate.dat`. ORC candidate is a Person in HCM — can convert to Worker on hire. |
| Candidate (internal) | Worker | Oracle only supports internal candidates through worker data, not `Candidate.dat`. |
| Submission | CandidateJobApplication | The join between Candidate and Job Requisition. User key is `RequisitionNumber + CandidateNumber`. Workflow state mapping is manual. |
| Offer | Offer (within Job Application) / Pending Worker | HDL does not support loading job applications with offers in the same load. Accepted offers should become pending workers or new hires. |
| Candidate Profile (Education, Experience, Skills) | Candidate child objects | Mapped to subcategories under `recruitingCandidates` resource. |
| Attachments (Resume, Cover Letter) | Candidate Attachments | Taleo stores as Base64-encoded, gzip-compressed SOAP blobs; must decode before import. Some job-site attachment endpoints are partner-restricted. |
| User Defined Fields (UDFs) | Extensible Flexfields (EFF) | EFF contexts are only available on specific entities and must be registered and deployed before data loads. Not every Taleo UDF will have a home. |
| Candidate Selection Workflow (CSW) | Selection Process Phases | No direct mapping. ORC uses a standardized phase model; Taleo's custom CSW steps must be redesigned. |
| Source/Medium tracking | Recruiting Source | Different taxonomy; requires value mapping. |
| OLF (Org, Location, Job Field) | HCM Foundation Data (Departments, Locations, Job Families/Profiles) | Must exist in HCM Core before any recruiting records reference them. |

### Sample Field-Level Mapping

| Taleo Field | ORC Field / Component | Transform Required |
|---|---|---|
| `CandidateID` | `CandidateNumber` | Generate new ORC number or use as source key. Alphanumeric + underscore + hyphen allowed. |
| `FirstName` | `FirstName` | Normalize Unicode and locale quirks |
| `LastName` | `LastName` | Direct map |
| `EmailAddr` | `EmailAddress` | Validate RFC compliance — ORC enforces this |
| `RequisitionID` | `RequisitionNumber` | Preserve where possible for traceability. Map to HCM Job/Position references. |
| `JobField` | `JobFamilyId` (HCM Core) | Lookup mapping table |
| `Organization` | `DepartmentId` (HCM Core) | Lookup mapping table |
| `Location` | `LocationId` (HCM Core) | Exact match required or HDL rejects the record |
| `Submission.Status` | `PhaseId` / `StateId` | Load to first phase/state first, then transition. Build custom mapping table (CSW step → ORC phase). |
| `Offer.BaseSalary` | `Salary` | Currency/format normalization; must associate with HCM Salary Basis |
| `UDF_CustomField1` | `EFF_Attribute1` | Register flexfield context in ORC first, then map |

The ORC field and component names above come from Oracle's recruiting HDL object definitions, including `Candidate`, `CandidateEmail`, `CandidateName`, `JobRequisition`, and `CandidateJobApplication`. ([docs.oracle.com](https://docs.oracle.com/cd/E56931_01/trans/hcm/F77414-01/hcm-data-loading-business-objects.pdf))

> [!NOTE]
> **Keep two immutable source keys:** one for the person and one for the candidacy. Use `SourceSystemOwner` and `SourceSystemId` wherever the business object supports them. This is what lets you rerun failed batches without duplicating records or breaking relationships. ([docs.oracle.com](https://docs.oracle.com/cd/E56931_01/trans/hcm/F77414-01/hcm-data-loading-business-objects.pdf))

### Handling Dependencies and Load Order

HCM Data Loader validates foreign-object references during the load phase — if a referenced object does not exist yet, the entire logical record fails.

**Required load sequence:**
1. HCM Foundation: Organizations, Locations, Jobs, Positions, Grades
2. Recruiting Candidates (person records — external only via `Candidate.dat`)
3. Job Requisitions (linked to HCM foundation)
4. Job Applications (linked to both Candidate and Job Requisition)
5. Offers / Pending Workers (loaded separately from Job Applications)
6. Attachments (child of Candidate or Job Application)

> [!CAUTION]
> If you load Job Applications before their parent Job Requisition exists in ORC, every application record will fail validation and the entire batch will be rejected. HDL does not do partial loads of logical objects — it is all or nothing per record.

## Migration Architecture: Extract → Transform → Load

### Extraction (Taleo Side)

**Primary tool: Taleo Connect Client (TCC)**

TCC communicates with Taleo via SOAP web services and provides a GUI for designing export specifications based on entity relationships. Each export is rooted on a single entity from which related fields and relationships are projected.

**Hard limits:**
- 500,000 extracted records per day (basic offering)
- 100,000 records per extraction transaction
- 50,000 imported records per day (basic offering)
- 4 concurrent integrations per Taleo product
- Attachment export requires TCC Custom Steps library — standard TCC does not handle file extraction
- Large extractions queue asynchronously on the Taleo server

([docs.oracle.com](https://docs.oracle.com/en/cloud/saas/taleo-enterprise/20b/otccu/appendix.html))

For multi-million-record databases, plan extraction across multiple days with date-range filtering to stay within limits. At 500,000 records/day, a 5-million-record candidate database takes a minimum of 10 calendar days — assuming no errors, no retries, and perfect batching. Factor in weekends, Taleo maintenance windows, and multiple entity types, and extraction alone can stretch to 3–4 weeks.

**Auth requirement:** Taleo extraction needs a user with the **System Integrator** role. ([docs.oracle.com](https://docs.oracle.com/en/cloud/paas/application-integration/talent-acquisition-cloud-adapter-user/prerequisites-creating-connection.html))

### Transformation (ETL Layer)

This is where most migration effort concentrates. Build a **canonical staging model** with separate entities for requisition, person, application/submission, offer/hire, attachment, and reference data. If you skip this layer and map source-to-target row by row, reruns become brittle.

Key transformation tasks:

- **Deduplicate candidates** — Taleo's duplicate detection is optional; many instances have significant duplicate populations
- **Build lookup tables** — Translate Taleo org IDs, location IDs, and job field codes to HCM Core equivalents
- **Restructure CSW states** — Map Taleo's custom workflow steps to ORC's standardized selection phases
- **Decode attachments** — Taleo compresses and Base64-encodes attachments; you must decode, decompress, and re-package for HDL or REST upload
- **Normalize data types** — Date formats, phone number formats, email validation (ORC enforces RFC-compliant email addresses), Unicode normalization
- **Resolve picklists and flexfield contexts** — Convert Taleo-specific selection values into target-controlled values
- **Split internal from external candidates** — Internal candidates must go through worker data, not `Candidate.dat`

### Loading (ORC Side)

**Primary tool: HCM Data Loader (HDL)**

HDL uses pipe-delimited `.dat` files packaged in `.zip` archives. Each file represents a single business object hierarchy. The process has two stages: import (to staging tables) and load (to application tables).

**Key capabilities and settings:**
- Multi-threaded import and load — configurable batch size and thread count (defaults: load group size 100, import threads 8, load threads 8, transfer group size 100,000)
- Supports MERGE operations (create if not exists, update if exists)
- Validates all foreign-object references during load phase
- Can be automated via `HcmCommonDataLoader` web service or `dataLoadDataSets` API
- Supports Source Key referencing (`SourceSystemId` + `SourceSystemOwner`) for maintaining cross-system record lineage

([docs.oracle.com](https://docs.oracle.com/en/cloud/saas/human-resources/25b/fahdl/hcm-data-loader.pdf))

**HDL access requirements:** The `ORA_HRC_HCM_DATA_LOAD_DUTY` role plus WebCenter Content import/export access (`HCM_DATALOADER_IMPORT_RWD`, `HCM_DATALOADER_EXPORT_RWD`).

**ORC REST API** supplements HDL for real-time or incremental operations. Page REST reads with `limit`, `offset`, and `orderBy` — Oracle notes paged results are not ordered unless you specify `orderBy`. Default query limit is typically around 500 rows. Rate limiting is enforced (429 errors on threshold breach).

## Automation Script Outline

Here is a high-level Python structure for a hybrid TCC-extract + HDL-load migration pipeline:

```python
import os
import csv
import zipfile
import requests
import base64
import gzip
import logging
from datetime import datetime

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("taleo_to_orc_migration")

# --- Configuration ---
TALEO_TCC_EXPORT_DIR = "/exports/taleo/"
HDL_OUTPUT_DIR = "/staging/hdl/"
ORC_BASE_URL = "https://<your-orc-instance>.oraclecloud.com"
HDL_UPLOAD_URL = f"{ORC_BASE_URL}/hcmCommonDataLoader/"
TCC_DAILY_LIMIT = 500_000
TCC_TRANSACTION_LIMIT = 100_000

# --- Step 1: Parse TCC exports ---
def parse_tcc_export(filepath: str) -> list[dict]:
    """Parse a TCC-exported CSV into a list of dicts."""
    with open(filepath, "r", encoding="utf-8") as f:
        reader = csv.DictReader(f)
        records = [row for row in reader]
    logger.info(f"Parsed {len(records)} records from {filepath}")
    return records

# --- Step 2: Transform and map ---
def transform_candidate(taleo_record: dict, org_map: dict, loc_map: dict) -> dict:
    """Map a Taleo candidate record to ORC HDL format."""
    return {
        "CandidateNumber": taleo_record.get("CandidateID"),
        "FirstName": taleo_record.get("FirstName", "").strip(),
        "LastName": taleo_record.get("LastName", "").strip(),
        "EmailAddress": taleo_record.get("EmailAddr", "").strip().lower(),
        "SourceSystemId": taleo_record.get("CandidateID"),
        "SourceSystemOwner": "TALEO_LEGACY",
    }

def decode_taleo_attachment(base64_content: str) -> bytes:
    """Decode Base64 + gzip compressed Taleo attachment."""
    decoded = base64.b64decode(base64_content)
    try:
        return gzip.decompress(decoded)
    except gzip.BadGzipFile:
        return decoded  # Not all attachments are compressed

# --- Step 3: Generate HDL .dat files ---
def generate_hdl_dat(records: list[dict], object_name: str, attributes: list[str]) -> str:
    """Generate pipe-delimited .dat content for HDL."""
    lines = []
    lines.append(f"METADATA|{object_name}|{'|'.join(attributes)}")
    for rec in records:
        values = [str(rec.get(attr, "")) for attr in attributes]
        lines.append(f"MERGE|{object_name}|{'|'.join(values)}")
    return "\n".join(lines)

def package_hdl_zip(dat_files: dict[str, str], output_path: str):
    """Package .dat files into a .zip for HDL upload."""
    with zipfile.ZipFile(output_path, "w", zipfile.ZIP_DEFLATED) as zf:
        for filename, content in dat_files.items():
            zf.writestr(filename, content)
    logger.info(f"Packaged HDL zip: {output_path}")

# --- Step 4: Upload to ORC via HDL web service ---
def upload_to_hdl(zip_path: str, access_token: str):
    """Upload .zip to HCM Data Loader via web service."""
    headers = {"Authorization": f"Bearer {access_token}"}
    with open(zip_path, "rb") as f:
        resp = requests.post(
            HDL_UPLOAD_URL,
            headers=headers,
            files={"file": (os.path.basename(zip_path), f, "application/zip")},
        )
    if resp.status_code == 200:
        logger.info(f"HDL upload successful: {resp.json()}")
    else:
        logger.error(f"HDL upload failed: {resp.status_code} - {resp.text}")
        raise RuntimeError(f"HDL upload failed with status {resp.status_code}")

# --- Step 5: Validate ---
def validate_migration(source_count: int, target_count: int, entity: str):
    """Compare record counts between source and target."""
    if source_count != target_count:
        logger.warning(
            f"Count mismatch for {entity}: "
            f"source={source_count}, target={target_count}, "
            f"delta={source_count - target_count}"
        )
    else:
        logger.info(f"{entity} count validated: {source_count} records")
```

> [!NOTE]
> This is a structural outline, not production-ready code. Real implementations need retry logic with exponential backoff, TCC session management, HDL job status polling, comprehensive error logging per record, and source-key idempotency so reruns do not duplicate data.

## Edge Cases, Hard Limits, and Failure Modes

The problems that break Taleo-to-ORC migrations are predictable. Plan for these explicitly.

### Duplicate Candidates
Taleo instances commonly have duplicate candidate profiles — the platform's duplicate check is optional and many organizations never enabled it. Run deduplication **before** migration. ORC runs duplicate checks on the preferred mode of communication (email or phone). If your Taleo data has shared inboxes or dirty phone data, you will hit rejection on load.

### Internal vs. External Candidates
Oracle only supports external candidates through `Candidate.dat`. Internal candidates belong in worker data. If your Taleo instance mixes internal and external candidate records, split them before loading. ([docs.oracle.com](https://docs.oracle.com/cd/E56931_01/trans/hcm/F77414-01/hcm-data-loading-business-objects.pdf))

### Application Phase/State Constraints
ORC job applications must load into the **first phase and state** of the target Candidate Selection Process (CSP), then be moved through allowed transitions. You cannot land applications directly in arbitrary final states. Every historical application requires a post-load transition step that walks it to the correct status. ([docs.oracle.com](https://docs.oracle.com/cd/E56931_01/trans/hcm/F77414-01/hcm-data-loading-business-objects.pdf))

### Offer History
HDL does not support loading job applications with offers in the same load. Accepted offers are better modeled as downstream pending worker or new hire records rather than historical offer objects inside the original application load. ([docs.oracle.com](https://docs.oracle.com/cd/E56931_01/trans/hcm/F77414-01/hcm-data-loading-business-objects.pdf))

### Attachment Extraction
Taleo stores recruiting module attachments as Base64-encoded, gzip-compressed blobs within SOAP XML payloads. Standard TCC cannot export these — you need the TCC Custom Steps library (`com.taleo.integration.client.customstep.xml.ExtractAttachedFilePostStep`). Budget extra time for this; it is the most error-prone part of extraction. On the ORC side, some candidate-facing attachment endpoints are restricted to Oracle Cloud Marketplace partners, so plan your loading approach accordingly.

### Custom Fields (UDFs → EFFs)
Taleo supports User Defined Fields on most entities. ORC uses Extensible Flexfields (EFF), but EFF contexts are only available on specific entities and must be registered and deployed before data loads. Not every Taleo UDF will have a home in ORC — some data may need to be stored in notes, flexfield contexts on other entities, or dropped entirely. ORC does not have a generic custom-object layer. ([docs.oracle.com](https://docs.oracle.com/en/cloud/saas/human-resources/farws/Flexfields.html))

### CSW-to-Selection-Process Mapping
Taleo's Candidate Selection Workflow is deeply customizable — organizations often have dozens of custom steps, sub-statuses, and routing rules. ORC uses a standardized selection process with phases. There is no automated translation. You must manually map each CSW step to an ORC phase and accept that some granularity will be lost.

### Date-Effective Records
Oracle HCM uses date-effective records. If you load a candidate or person record with a start date that conflicts with an existing HCM record, HDL will reject it. This is especially relevant for internal candidates who already exist as Workers in HCM.

### Orphaned Submissions
If a Taleo Requisition was deleted but the Submission remained, ORC will reject the application on import because it lacks a valid parent Requisition ID. Identify and handle orphaned submissions during the audit phase.

### Phone Numbers
Phone numbers loaded through HDL are treated as verified and will not be candidate-editable on external career sites. This is a subtle but important distinction for candidate experience.

### API Failures and Throttling
Both Taleo (SOAP) and ORC (REST) APIs enforce usage limits. Build retry logic with exponential backoff into every API call. Log every failed record with its source ID so you can remediate without re-running the entire migration. Use source-key idempotency, not row-order retries.

For broader guidance on ATS migration pitfalls, see [5 "Gotchas" in ATS Migration](https://clonepartner.com/blog/blog/ats-migration-gotchas/).

## Validation and Testing

### Record Count Validation
Compare source counts (from Taleo) to target counts (in ORC) for every entity: Candidates, Job Requisitions, Job Applications, Offers, Attachments. A delta of zero is the goal; any non-zero delta requires root-cause analysis.

### Field-Level Validation
Sample 5–10% of migrated records and validate field-by-field against the source. Focus on:
- Name and email accuracy
- Requisition → HCM Job/Position linkage
- Job Application workflow state mapping
- Offer compensation data
- Attachment file integrity (open and verify a sample of migrated resumes)

### Parent-Child Chain Reconciliation
Validate the full relationship chain: Requisition → Candidate → Application → Attachment. Focus on the hard cases: multi-application candidates, pipeline requisitions, multilingual profiles, accepted offers, and deleted or withdrawn records.

### UAT Process
Recruiting operations teams must validate that:
- Active requisitions display correctly with correct candidate pipelines
- Candidate search returns expected results — ORC requires running `Maintain Candidates and Job Requisitions for Search` after bulk loads
- Offer details are accurate
- Historical submission data is accessible for compliance queries

### Rollback Planning
HDL supports rollback for some business objects if you retain the dataset. For critical migrations, maintain a full backup of the target ORC environment (sandbox/test pod) before loading production data. Run at least **two full test migrations** before the production cutover. Freeze lookup and CSP changes near cutover.

## Post-Migration Tasks

Data alone does not complete the migration. These tasks are mandatory after the data loads:

- **Rebuild selection processes.** Taleo CSW workflows do not migrate. Redesign them in ORC's selection process configuration.
- **Reconfigure career sites.** Taleo career sites are separate from ORC career sites. All branding, application flows, and questionnaire configurations must be recreated.
- **Run `Maintain Candidates and Job Requisitions for Search`.** This scheduled process must execute after bulk data loads for candidates to appear in ORC's search index.
- **Rebuild integrations.** Any downstream systems that consumed Taleo data — background check providers, HRIS feeds, BI tools, agency workflows — need new integration points against ORC's REST API or HCM Extracts.
- **Rebuild reports.** If your Taleo instance fed BI tools via TCC extracts, rebuild those reports against ORC's OTBI (Oracle Transactional Business Intelligence) subject areas.
- **User training.** The ORC interface is fundamentally different from Taleo's Recruiting Center. Budget time for recruiter, hiring manager, and admin training.
- **Monitor for data inconsistencies.** Run daily validation reports for the first 30 days, checking for missing records, broken relationships, and search indexing gaps.

## Why System Integrators Fail at Data Migration

SIs like Mastek, Baker Tilly, and Accenture are excellent at ORC system configuration, process design, and change management. But historical data migration is a fundamentally different discipline — and it is routinely treated as a secondary workstream within SI-led implementations.

The pattern we see repeatedly:
1. SI scopes a 12–18 month HCM Cloud implementation
2. Data migration is allocated 10–15% of project budget and assigned to junior resources
3. Complex Taleo data (attachments, multi-submission candidates, custom CSW states) hits unexpected API limits
4. Migration falls behind, forcing either data truncation or timeline extension
5. Go-live happens with incomplete historical data, broken compliance trails, or missing attachments

The root cause: data migration and system implementation are **different problems** requiring different skills. Implementation is design and configuration. Migration is extraction, transformation, and validation engineering.

For a deeper analysis, see [Why Data Migration Isn't Implementation](https://clonepartner.com/blog/blog/data-migration-vs-implementation-guide/).

## When to Use a Managed Migration Service

**Build in-house when:**
- Your internal team has deep TCC and HCM Cloud expertise
- Your dataset is small and structurally simple (<100K candidates, no attachments, no custom fields)
- You have 4+ months of engineering bandwidth to dedicate

**Use a managed service when:**
- Your Taleo instance has millions of records, complex CSW configurations, or heavy attachment usage
- You need the migration completed in weeks, not months
- Your engineering team is already committed to the ORC implementation workstream
- You cannot afford data loss on compliance-critical candidate records
- You have multi-year candidate history, multilingual data, multiple CSPs, or a go-live window that allows only one or two full rehearsals

The worst option is the middle ground: a cheap migration plan that looks fine in a spreadsheet and fails when recruiters search for real people, real applications, and real history.

**ClonePartner** specializes in exactly this problem space: complex data migrations where relational integrity, attachment fidelity, and zero downtime are non-negotiable. We bypass TCC export bottlenecks, map Taleo's legacy foundational data into Oracle HCM's unified core structures, and guarantee the preservation of historical candidate relationships. We separate the data migration from the general system implementation so your team can focus on ORC configuration while we handle extraction, transformation, and loading.

> Migrating from Taleo to Oracle Recruiting Cloud? Our engineers handle extraction, transformation, and loading — including attachments, custom fields, and multi-million-record candidate databases — so you don't have to. Book a 30-minute technical scoping call.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click)

## Frequently asked questions

### Does Oracle provide a native Taleo to ORC migration tool?

No. Oracle does not provide a native migration path from Taleo to ORC. Oracle Consulting explicitly frames the move as not a lift-and-shift. The transition must be handled by customers themselves using TCC for extraction and HDL/REST API for loading, or through a partner or managed migration service.

### What are the Taleo Connect Client (TCC) export limits?

TCC's basic offering imposes a maximum of 500,000 extracted records per day, 100,000 records per extraction transaction, and 50,000 imported records per day. These are hard limits documented by Oracle. For multi-million-record databases, extraction must be spread across multiple days using date-range filtering.

### Is Oracle sunsetting Taleo?

Oracle has not published a formal end-of-life date for Taleo Enterprise Edition. However, new feature development has stopped, updates are limited to security patches, Taleo Enterprise is no longer available to new customers as of the February 2026 price list, and components like Taleo Performance (2020) and the legacy Career Website (2024) have already been retired.

### Can I migrate all historical Taleo applications into ORC?

Not cleanly as-is. ORC HDL creates job applications only in the first CSP phase/state, and loading job applications with offers is not supported in the same load. Oracle's own guidance says not to load historic job applications just for reporting. Most teams migrate operating history and archive the long tail elsewhere.

### How do I migrate Taleo attachments to Oracle Recruiting Cloud?

Taleo stores recruiting attachments as Base64-encoded, gzip-compressed blobs within SOAP XML. Standard TCC cannot export these — you need the TCC Custom Steps library (ExtractAttachedFilePostStep) to decode and extract the files. Once extracted, attachments can be loaded into ORC via the REST API attachment endpoints or packaged for HDL.