BICC is legacy. What should Oracle Fusion data teams do next?

Oracle now documents BICC as legacy and its Data Extraction tool (RODS) as the long-term replacement. What changes, what doesn't, and how to prepare without re-platforming twice.

For a decade, BI Cloud Connector (BICC) has been the way to bulk-extract Oracle Fusion Cloud data into a warehouse or lake. That is changing. Oracle's current documentation describes its new Data Extraction tool — often called RODS, after the read-only data store it reads from — as “designed as the long-term replacement for Business Intelligence Cloud Connector (BICC)”, and the 26C Projects update says it “will eventually replace data extracts using BI Cloud Connector (BICC) and BI Publisher”.

BICC isn't switched off tomorrow. But if you're designing a Fusion data platform now, you should design for both.

What actually changes

• Where extraction runs. Data Extraction reads a replicated, read-only copy of Fusion data rather than the transactional application, so large extracts stop competing with your users.
• The object model. PVOs give way to business objects with extraction views. Foreign keys become object references (a PVO's OrganizationId becomes organization.id), and Oracle notes there is not a 1:1 correspondence with BICC in every case.
• Who owns the watermark. With BICC, reliable pipelines track incremental state themselves. Data Extraction manages incremental state per schedule on Oracle's side, driven by timeCreated / timeUpdated.
• Where files land. Oracle-managed storage is the default; UCM is kept for BICC-style compatibility; delivery to your own OCI Object Storage is a separately licensed option.
• Automation. Extract definitions, export groups, schedules and output downloads all have REST APIs with OAuth client-credentials, so extraction can be driven from code.

What doesn't change

• Your downstream tables. Databricks, Snowflake and BI models don't care which Oracle engine produced the file — as long as the columns, keys and meaning stay stable. Data Extraction can even apply BICC column headings.
• The hard questions. Which sources hold the data, which columns are really populated, how deletes are detected, what order things must load in — all still yours to answer.
• Your security posture. You still need a least-privilege Fusion identity with the right extraction roles.

What's still unclear

Be careful with anything you can't verify on your own instance. As of Oracle's current guide, we have not found documented answers to: how deletes are detected (there is no documented equivalent of BICC's primary-key extracts), whether every Projects view matches today's PVOs, and whether descriptive flexfields are fully covered — Oracle's release notes and guide say different things. Oracle's BV_to_BICC_Database_Mapping spreadsheet (My Oracle Support) and the 26D Migration Assistant help with the mapping, but test before you commit.

How to prepare without re-platforming twice

1. Separate your model from the engine. Describe each source by business meaning — entity, primary key, columns, watermark, delete behavior, dependencies, destinations — and keep engine-specific names (PVO path, business object, view) as bindings underneath.
2. Keep the model in git. When a source moves from BICC to Data Extraction, that becomes a reviewed change to one binding — not a rebuild.
3. Own reconciliation. Row counts and delivery checks on every run let you run both engines side by side and prove the numbers match before switching.
4. Plan for deletes explicitly. Decide per source whether you need soft deletes, and how you'll reconcile keys if the new engine doesn't provide them.
5. Pilot one subject area. Enable the feature in a test pod, pick a well-understood area, and compare outputs against your BICC pipeline for a few weeks.

sources:
  projects:
    primary_key: [project_id]
    watermark: last_update
    delete_mode: soft
    depends_on: [project_types]
    bindings:
      bicc:            {pvo: ProjectExtractPVO}
      data_extraction: {business_object: projects}   # confirm on your instance

Checklist

• Inventory the BICC offerings and PVOs you extract today
• Check each against Oracle's BV-to-BICC mapping and flag gaps
• Move your extraction definitions into an engine-neutral model in git
• Add per-run row counts and reconciliation if you don't have them
• Enable Data Extraction in a test pod and pilot one subject area

Sources: Oracle Fusion Cloud documentation (Data Extraction guide G51947, 26B–26D readiness notes). Quotes current as of September 2026; check Oracle's latest documentation.