Migrating from Taleo to Workday: what moves, what doesn't, and what to decide before go-live

The short answer: Taleo to Workday is the most common ATS move we see in healthcare, and the part that goes wrong is never the Workday side. It is the decision, usually made by default, that the years of applications, dispositions and candidate relationships in Taleo are "history" and can stay behind. They can, but then every past applicant, every silver medalist and every former employee starts from zero in the new system. This guide covers what Taleo actually holds, the four decisions that determine what lands in Workday, how the data gets out of one and into the other, and what a migration that accounts for every record looks like.

What is actually in your Taleo tenant

Oracle describes Taleo Enterprise Edition as software that "helps organizations reach hard-to-find talent, hire the right people, and get them productive more quickly". After a decade of use, a health system's tenant typically holds six kinds of record, and they are worth more together than apart:

• Candidate profiles. Name, contact details, work history, education, and whatever licenses and certifications the application form captured.
• Applications. One per candidate per requisition, each with its applied date, the step and status it reached, and the disposition reason if it closed. This is the record of every hiring decision your team has made.
• Requisitions. The jobs themselves: title, department, facility, location, status. Without them an application has nothing to point at.
• Attachments. Resumes, cover letters and licenses uploaded with each application.
• Flags and tags. Internal and former-employee markers, candidate sources, and any withdrawn or do-not-hire flags your recruiters set.
• Configuration. The step and status vocabulary, disposition reasons and custom fields your tenant was built with. These do not migrate; they are what the mapping has to translate.

The sixth item is why "export it and import it" fails. Taleo's candidate selection workflow has its own steps and statuses; Workday Recruiting has its own stages and dispositions. A record only makes sense in the new system once someone has decided what each old value means in the new one.

The four decisions to make before anything moves

1. Scope: how much history

Everything, or a window. Most health systems move every applicant from the last several years and archive the rest, but the decision should follow the data: if a third of your hires in the last two years were past applicants, the history is a sourcing asset, not an archive. Decide by date range, by facility or division, by requisition status, or by candidate status, and write the rule down so the reconciliation can test against it.

2. Mapping: what each stage and disposition becomes

Every Taleo step and status needs a destination in Workday, and every disposition reason needs a decision: keep it as a reason, collapse it into a category, or carry it as text. Two rules keep this honest. Map from the source system's own codes rather than its display names, because display names get edited over the years and codes do not. And make sure anything that was closed in Taleo arrives closed in Workday, so a candidate who declined an offer in 2019 does not surface as an active applicant in 2026.

3. Exclusions: what stays behind

Some fields should not move at all, and the list should be agreed on before the first record does. EEO responses, Social Security numbers, dates of birth and compensation history are the usual candidates, either because the new system has no place for them or because your privacy team would rather they did not travel. Exclusions are a decision, not an accident; a migration that documents them is one you can defend to a compliance reviewer later.

4. Identity: one record per person

A decade of applications means the same nurse applied four times under three email addresses. Workday will happily create four candidates. Decide the rule for merging them (email, phone, name plus date of birth, in what order of trust) and which record wins when two disagree. If two systems are being consolidated after a merger, this is the decision that determines whether the new ATS starts clean or starts with duplicates.

How the data gets out of Taleo

Oracle's documentation for Taleo Enterprise Edition lists two integration routes, "Use Connect Client" and "Use Web Services", and a guide for integrating Taleo with Oracle Fusion. In practice, three situations come up:

• The tenant is live and under contract. The integration route, or a scheduled file export, reads the full history while recruiters keep working. Nothing is written to Taleo and nothing is deleted from it.
• The tenant is being switched off. Oracle's export tooling needs the tenant running. Extract before the contract ends, not after, and keep the extract until the reconciliation report is accepted.
• The tenant is already gone and only an archived database remains. This is more common than it sounds: a system retires Taleo, keeps a read-only copy of the database for records retention, and later realizes the history is worth recovering. The archive can be read directly, without an API or a vendor, provided someone can read Taleo's schema.

How it gets into Workday

Workday describes its talent acquisition product as "one centralized hub for all the tools and AI insights recruiters need". Historical records go in through Workday's supported load routes, usually with your implementation partner, and the practical constraint is not volume but shape: Workday expects candidates, applications and requisitions as separate, linked objects, with stages and dispositions from its own configured vocabulary. That is why the mapping decision above has to be finished before the load starts; a load that invents stages on the fly is one you will be cleaning up for a year.

Two things are worth confirming with whoever runs your Workday load. First, that requisitions are loaded before applications, so every application has a job to point at. Second, that closed applications are loaded closed, with their disposition, so your reports in Workday show the real history rather than a wall of open applications dated 2018.

What a migration that accounts for every record looks like

The method Betterleap uses has four stages, and the old system stays on until the last one is done:

1. Count. A read-only pass that counts every record in scope and confirms the population with you before anything is extracted. No surprises about volume later.
2. Pilot. A few thousand records end to end, through the mapping and into the destination, so the mapping decisions are tested on real data rather than on a spreadsheet.
3. Full run. Extraction, cleaning, deduplication, contact refresh, mapping and load.
4. Reconcile. Every source record reported as loaded, skipped by rule, or failed with a reason, and the totals compared against the source. The report is yours before the old system is switched off, never after.

In practice: the largest Taleo history Betterleap has moved to date was a retired Taleo archive for a leading US academic health system, 1.17 million candidate records and 5.3 million applications covering 9.5 years, read directly from the archived database with no API or vendor involved, reconciled at a 0.001% loss rate. That is the scale of history a hospital system accumulates in a decade, and it is why "start fresh" is an expensive default.

What to leave behind on purpose

Not everything deserves the trip. Candidates with no application and no contact details, requisitions cancelled before they were posted, test records your admins created in 2014, and attachments the retention policy says should have been deleted already. Make each of these an explicit rule, so the reconciliation report shows them as "skipped by rule" rather than as unexplained loss.

Questions to ask before you sign the Workday cut-over date

• Who owns the Taleo export, and does the contract allow a full extract before termination?
• What is the retention requirement for the Taleo history, and does a Workday load satisfy it, or does an archive still need to be kept?
• Who signs off the stage and disposition mapping: talent acquisition, HRIS, or both?
• Which fields are excluded, and who in privacy or compliance has agreed the list?
• What is the deduplication rule, and who decides when two records disagree?
• What does the reconciliation report have to show before the old system is switched off?

Betterleap runs Taleo-to-Workday migrations for health systems, through Taleo's integration route, a file export or a direct read of a retired archive, into Workday's supported load routes, with the reconciliation report built in. It is the same work behind Betterleap's 25+ ATS integrations. Details and a scoping form are on the ATS data migration page.

Sources

• Oracle, Oracle Taleo Enterprise Edition documentation hub, docs.oracle.com/en/cloud/saas/taleo-enterprise, and its Integrate section listing the guides Use Connect Client, Use Web Services and Implementing Fusion and Taleo Enterprise, docs.oracle.com/en/cloud/saas/taleo-enterprise/integrate.html, read 15 October 2026.
• Workday, Talent Acquisition Software, workday.com/en-us/products/talent-management/talent-acquisition.html, read 15 October 2026.
• Betterleap, ATS data migration for health systems; migration figures from Betterleap's own run records, October 2026.