SAP ECC on Oracle: Lift-and-Shift Before S/4HANA

Lift-and-shift is defensible for the ECC application and database core, and wrong for three specific things. Say so plainly rather than arguing the principle.

Preserve: the ECC application server tier, the custom ABAP, the RFC/IDoc interfaces and the Oracle schema. Re-architecting ECC two years before an S/4 programme is work you will throw away.

Must change during the move:

• Oracle 12c, which is out of premier support. Moving an unsupported database to a new platform means you own the remediation. Certify and migrate to 19c as part of the same cutover - doing it later means a second full database migration.
• The BW on HANA sidecar must run on SAP-certified hardware with the correct vCPU-to-memory ratio and scale-up versus scale-out decided by data volume. HANA does not tolerate 'roughly the right' sizing.
• The spool/print layer. OCI does not carry 900 warehouse printers. Design local print gateways per warehouse talking to the spool in OCI, or keep the printing on-premises behind private connectivity.

The missing evidence is the whole sizing basis. There is no SAPS-per-shape exercise and no RFC round-trip measurement, so nobody can say whether the 1.2-second dialog SLA survives. Build the sizing from the existing SAP Early Watch/SAPS measurements with headroom, select from the certified shape list, and measure application-to-database round-trip latency before committing.

'Exactly as is' also imports the current performance profile. If ECC is slow on-premises, it will be slow on OCI and the programme will be blamed.

Nothing about this migration is proven until round-trip latency is measured. SAP dialog response is dominated by the number of database round-trips multiplied by latency, so the design must place the application tier and the database in the same availability domain with a measured, low round-trip time, and validate it with a real load test at quarter-end peak. Do not accept an architectural diagram as evidence; instrument the round-trip and compare against the on-premises baseline - which you currently do not have, so measure it before you leave.

Integration:

• IDoc delivery is ordered and must not be lost, so the 30 partners should ride private connectivity (FastConnect), not an internet-only path. Where a partner must use the internet, terminate through a controlled ingress with monitoring and retry handling, and document the ordering guarantee you are actually providing.
• File interfaces move to OCI File Storage or Object Storage, with the partner's expected latency and directory semantics checked - flat object storage is not interchangeable with a shared filesystem for some interfaces.
• SAProuter and SAPGUI access go over private connectivity or VPN; do not expose the SAP GUI or the message server directly.

Print: do not backhaul 900 devices' print traffic over the WAN. Deploy local print gateways in each warehouse or distribution centre that receive the spool output from OCI and drive the printers locally. This also gives you a failure mode you can reason about - a warehouse with no WAN still prints its labels - instead of a single remote dependency.

Finally, test the interfaces with real partner traffic, not with a ping or a synthetic IDoc. Partner-side firewalls and certificates are where cutovers stall.

The requirement is modest enough that a pilot-light posture in a second OCI region meets it, and that is the right spend given 2029.

• Oracle database: Data Guard to a standby in the second region, in maximum performance mode. Redo shipping puts RPO in seconds, well inside 15 minutes, and the standby is a running instance rather than a restore-from-backup exercise - which is what makes the 4-hour RTO achievable.
• BW on HANA: HANA System Replication, asynchronous. Measure the actual redo shipping lag at peak load rather than quoting a design figure; the 15-minute RPO holds only if the log volume at quarter-end is carried.
• Application tier: compute provisioned but stopped or scaled to a minimum, with automation to start and reconfigure. Fully running standby capacity for 4,000 concurrent users is money spent on a capability you will re-platform in three years.
• File and interface layer: replicate File Storage or Object Storage to the second region; DR that restores the database but loses the file shares fails the test.
• Orchestration: OCI Full Stack Disaster Recovery to run the switchover as a repeatable, tested plan rather than a wiki page. Test it at least twice, including a test with the primary region treated as genuinely unavailable.

What to invest in and what not to: build the landing zone, network, identity and DR automation so that they are reusable for S/4HANA in 2029. Do not build a bespoke, highly optimised DR pattern for ECC that S/4 will discard. And say clearly that the 15-minute RPO for ECC's file shares and interface queues is the part most likely to be missed - those are usually the last thing replicated and the first thing forgotten in the test.