Exadata Cloud Service Go Live Checklist

The riskiest moment in any Exadata Cloud Service project is the cutover to production. Everything that was theoretical becomes real, and the gaps you did not close in the build show up at the worst possible time. A disciplined go live checklist is the difference between a quiet cutover and a long night. This is the checklist we run before we let any Exadata estate carry production traffic.

It assumes the platform is built and the migration is rehearsed. For the migration itself, see migrating to Exadata Cloud Service.

Network readiness

Confirm the SCAN name resolves from the application tier, because a SCAN that does not resolve is the most common day one failure. Verify connectivity over the production path, whether that is FastConnect, VPN or in VCN routing, and confirm the security lists permit exactly the listener ports from exactly the application source ranges and nothing wider. Test from the real application hosts, not from a bastion, because the bastion path is not the production path. The network design behind this is in Exadata networking.

Security readiness

Verify the cluster has no public IP unless there is a documented reason. Confirm Transparent Data Encryption is active and, where policy requires it, that master keys are customer managed in OCI Vault. Check that administrative accounts are named rather than shared, that multi factor authentication is enforced for control plane write access, and that unified auditing is on and shipping records off the cluster. Run through the full ExaCS security controls as your reference.

Backup and recovery readiness

A backup you have never restored is a guess. Before go live, confirm the backup configuration runs successfully, then restore a backup to a test target and validate it opens cleanly. Confirm the retention meets your recovery point objective and that backups land in the intended object storage location with the right encryption. The strategy behind this is in backup strategy for Exadata Cloud.

Data Guard readiness

If the design includes a standby, rehearse a switchover before go live, not after. Confirm the standby is applying redo and the transport lag is within tolerance, verify the broker configuration, and confirm Fast Start Failover and the observer are configured where the design calls for them. A standby that has never taken over is an untested standby. The design reference is Data Guard on Exadata Cloud.

Monitoring readiness

Production without monitoring is production you find out about from users. Before cutover, confirm the monitoring agents are installed and reporting, that alarms exist for node health, storage pressure, backup failures and Data Guard lag, and that the alarms route to a team that will act on them around the clock. Test an alarm end to end so you know the path from event to human actually works.

Performance readiness

Capture a performance baseline on the new platform under representative load before go live, so that after cutover you can tell whether a slowdown is real or imagined. Confirm the Exadata smart features you sized for are active and delivering, and that connection pooling and the application configuration match the cluster. Going live without a baseline means every later performance question becomes an argument with no data.

The go live checklist

Operational readiness

Technical readiness is not the whole picture. Confirm there are runbooks for the common operational tasks, a named owner for the database, documented escalation contacts and, above all, a tested rollback plan. The cutovers that go badly are almost never the ones with a rollback plan ready. They are the ones where the team committed with no way back. For estates that will grow, line this up with the operating model in managing Exadata Cloud at scale.

Run the cutover with the checklist in hand

Every item above has been the thing that broke a go live for someone. The checklist is not bureaucracy. It is the accumulated scar tissue of cutovers that went wrong, turned into a list so yours does not. Run it as a gate: nothing carries production traffic until every line is green and signed off.

The Exadata Cloud Service practice runs this checklist as the final gate on every implementation, and will validate a go live planned by your own team before you commit.