Migrating a Business-Critical Oracle RAC Estate with Minimal Cutover Risk

An Australian telecommunications business was running a business-critical Oracle RAC estate on NFS shared storage, and a new enterprise SAN was arriving. On paper this is a storage refresh. In practice, changing the storage underneath a RAC estate changes almost everything that sits on top of it.

The databases move. The cluster layer moves with them. Application connectivity has to be repointed. The Data Guard relationships protecting the estate have to be rebuilt. Monitoring and the management repository have to follow, or they end up stranded on storage that is being decommissioned. And every one of those is a place where a migration becomes an outage.

So the question was never "how do we move the files". It was how to move the platform while proving the applications, RAC failover, database performance and the recovery architecture all still work — before the business depends on the answer.

A new cluster, not an in-place conversion. New virtual machines, grid infrastructure, RAC and ASM installed fresh, and the database software deployed at patch levels matching the existing environment — so the migration moves the data without also moving the version.

The new SAN was presented as shared raw devices and organised into ASM disk groups by function: database files, redo, archive and the recovery area, cluster voting storage, and dedicated groups for the larger workloads. That is the part that makes the difference between new storage and a storage architecture.

Because the replacement was built beside production rather than on top of it, the existing cluster stayed available and untouched throughout. The estate was never in a half-migrated state, and the project could be stopped at any point before cutover with nothing lost. That single decision is what turned a high-risk storage change into a controlled platform transition.

One more thing shaped the design: where the new virtual machines were placed. Oracle licensing follows infrastructure, and a technically valid architecture is not the right architecture if it creates commercial exposure nobody budgeted for. Placement was specified to keep the new machines within the existing RAC licensing boundary.

The estate had Data Guard protection between two Australian data centres, and moving production breaks it. Rather than leaving that as a follow-on project, rebuilding the standby databases on the new storage and re-establishing Data Guard was planned into the migration itself.

Including the uncomfortable part: the plan identified the window after cutover during which disaster-recovery protection would not be available, until the new standby was rebuilt. That exposure was known, sized and sequenced in advance. The alternative is discovering it afterwards, which is how an organisation ends up unprotected without having decided to be.

The management layer moved too. The Oracle Enterprise Manager repository was relocated onto the new storage under its own controlled procedure — snapshot, new filesystem, shutdown, file movement, restart, agent connectivity confirmed, fresh backup — so monitoring did not stay behind on storage that was being retired.

At a glance this was a move from NFS to SAN. In practice the storage changed, the RAC platform changed, the cluster connection point changed, the production databases moved, the Data Guard relationships changed, disaster recovery had to be rebuilt and monitoring had to follow — and none of it was allowed to become an unacceptable outage.

What made that possible was sequence. The replacement was built and proven alongside production, the final data was synchronised rather than copied, the rollback path was designed before the change began, and recovery was rebuilt as part of the project instead of after it. The client did not migrate and then find problems; they found the problems while production was still running somewhere else.