Core Banking Reporting Database: 11.2.0.4 on AIX to Exadata Database Service in a 4-Hour Window

The window is the whole problem, so start by rejecting anything whose downtime scales linearly with database size.

• Data Pump full export/import: 38 TB will not import in four hours, and the two prior failures show the operational fragility. Reject as the primary method.
• Physical RMAN with cross-platform conversion: the source is AIX, which is big-endian; Linux x86-64 is little-endian. This is a true cross-platform migration, so a plain backup/restore or a physical duplicate will not work. The viable physical-adjacent route is transportable tablespaces with RMAN CONVERT DATABASE (or the file-level conversion for datafiles), moving the bulk once and applying only the delta at cutover.
• Logical with transportable tablespaces: Data Pump in transportable mode moves metadata only, so the 38 TB is shipped once and the cutover moves almost nothing. This is the most reliable path given the character set requirement, and it also produces the AL32UTF8 target naturally.
• Oracle Zero Downtime Migration can orchestrate these flows, but be clear about its constraint: its physical online methods assume compatible platforms/endianness, while cross-platform AIX-to-Linux work falls back to a transportable or logical flow with different downtime characteristics. Do not promise near-zero downtime from ZDM alone on this combination.
• GoldenGate would give true near-zero downtime but adds a licensed component and a second moving part to a database that already has a two-quarter deadline.

Recommendation: staging migration of tablespaces to the target over several weeks, followed by a metadata-only cutover, with Data Guard established between the 19c target and a 19c staging copy where possible to support the 15-minute RPO once live. Rehearse the cutover twice and measure; if the second rehearsal cannot finish inside three hours, the window assumption is wrong and must be renegotiated before go-live, not during it.

Version path: 11.2.0.4 can upgrade directly to 19c, so a double-hop through 12c is unnecessary - but 11.2.0.4 support status means the upgrade is the objective, not a side effect.

These are two independent changes that are easy to conflate and expensive to get wrong.

Order of operations. Convert during the staging phase, not at cutover. One option is to create the target database directly as AL32UTF8 (which the vendor requires anyway) and let transportable tablespaces plus Data Pump perform the conversion as the data lands. The other is to run the character set conversion on the source in a maintenance window before the move. Converting at cutover puts a 38 TB, unpredictable-duration step inside a four-hour window - that is precisely how the earlier NLS failure turned into a missed deadline.

Validate the conversion, don't assume it. WE8ISO8859P1 is a single-byte Western European set; converting to AL32UTF8 expands some characters and truncates differently in fixed-width columns. Before cutover, run a scan of the source for non-ASCII data using CSSCAN/Database Migration Assistant style analysis, list the affected tables and columns, and have the vendor confirm the expanded column widths. Byte-length-to-character-length semantics are the classic post-migration defect: a VARCHAR2(30 BYTE) column that held 30 accented characters may not fit the same 30 characters once converted.

Endianness is handled by the transportable/conversion mechanism, not by any application change, but it does mean you cannot mix backup-based physical copies between the two platforms as a shortcut.

The window budget then becomes: stop the source feed, apply the final delta of tablespaces, import metadata, run the pre-agreed validation script set, repoint the application, restart. The bulk already moved weeks earlier. Keep AL16UTF16 as NLS_NCHAR_CHARACTERSET on the target - it is already the required national set and removes a second conversion variable.

Autonomous Database removes a great deal of operational burden and would genuinely be simpler for many workloads - but here the decision is constrained by facts that are not architectural preferences.

1. Vendor certification is a hard gate. The application vendor certifies only 19c on Linux against a conventional database and has put that in writing. Running an uncertified configuration means the first production defect becomes a support dispute in which the bank carries both sides. If the vendor will not move, ADB is out regardless of technical merit.
2. Character set. ADB requires AL32UTF8 and gives no OS-level access. Since the target must be AL32UTF8 anyway for the vendor, this is not the blocker - but the conversion testing described earlier still applies, and it must be done against whatever platform you choose.
3. Operational model fit. ADB's value is highest for teams that want to stop patching, tuning and sizing. This team has just bought dedicated Exadata and has the skills to run it, so a large part of ADB's benefit is already paid for.
4. Performance and control. Regulatory reporting with month-end bursts benefits from ADB's elastic scaling, but it also expects predictable performance and specific optimizer behaviour; that has to be evidenced by a proof of concept on real data volumes, not assumed.

What to tell the business: the recommended path is 19c on Exadata Database Service because it satisfies certification, preserves the current operational skills and meets the RPO/RTO with Data Guard. ADB remains a live option for the next generation of reporting, and the migration should be designed so it is not foreclosed - keep the schema free of platform-specific features, keep the character set at AL32UTF8, and re-open the question when the vendor certifies ADB or when the application is replaced.