The BI, ETL and consumption tail

Owned by everyone and nobody. Where migrations actually overrun.

This is where migrations overrun, and it deserves more of your attention than the data movement it depends on.

The problem is that this layer is owned by everyone and nobody. The database team owns the tables. The BI team owns the reports. The integration team owns the feeds. The business owns the definitions. The migration team owns the deadline and none of the resources.

Practical positions I would take:

Inventory by consumer group, not by artefact. Four hundred reports is an unmanageable number. Twelve consumer groups, each with a named owner and a list of what they need working on day one, is a plan. Group by who screams if it breaks.

Get the dependency map from the systems, not from people. BI tool metadata, database dependency views, scheduler definitions and query logs will tell you what actually reads what. People will tell you what they remember. Reconcile the two and trust the first.

Semantic definitions are a migration risk, not a documentation problem. If “active customer” is defined in three places with two definitions, the migration will surface that, usually during business reconciliation, usually in front of a stakeholder. Find them in advance and force the decision before cutover rather than during it.

Connection strings and credentials are a bigger job than they look. Every report, every extract, every scheduled job, every desktop tool somebody built. There will be connections nobody has an inventory of, discovered by the fact that they break. Plan a discovery pass on source connection audit logs specifically for this, and expect a tail.

Ad-hoc and desktop consumption is real consumption. Analysts with direct SQL access, spreadsheets with database connections, departmental tools built by someone who has left. This population is invisible to your inventory and will be the loudest post-cutover. Communicate to it early and directly.

Budget re-testing, not just re-pointing. Re-pointing a report is a configuration change. Proving it still produces the same numbers is the work, and it needs the business owner’s time, which is the scarcest resource on the project.

Reviewed 25 August 2026

These are my own views, written from years of building and moving large Oracle data platforms. They are not Oracle’s official guidance and this is not Oracle documentation. Volatile product claims are quarantined in Product facts that will date.