Who this is for, and what it covers
Audience, the phrase "large data reporting platform", sources and target covered.
This is for architects, data engineering leads and warehouse specialists who have been handed a migration and need to decide how to do it — not a step-by-step procedure, and not a substitute for product documentation.
I use the phrase large data reporting platform deliberately. The industry distinction between EDW, data warehouse, datamart and ODS is not cleanly drawn, and in practice every customer draws it differently. What these systems have in common is what matters here: a large body of historical data, a dense web of loading and reporting dependencies built up over years, a business that reads the output every morning, and a limited tolerance for it being unavailable. The migration problems are substantially the same across all of them. Where a genuine difference bites — an ODS with a high change rate has a different cutover shape from a datamart that is rebuilt nightly — I say so.
Sources covered. The primary case is on-premises Oracle Database. Other relational platforms — SQL Server, Teradata, Netezza, Db2, PostgreSQL — are covered where their treatment differs, mainly in converting the code rather than data. Hadoop and Hive sources get a short aside; they are a different problem wearing similar clothes.
Target. Oracle Autonomous AI Lakehouse, in whichever deployment you land on. Deployment choice constrains method more than most teams expect, and I return to it repeatedly.