GDO
All Case Studies
10 min

Oracle Migration: Managing Legacy Systems and High Availability

18 TB
Data managed
Optimized ASM (Automatic Storage Management) storage configuration.
< 60
minutes to switchover
An effective cascading migration strategy.
8
Cluster nodes
4 production nodes and 4 disaster recovery nodes to ensure business continuity.
100%
Oracle 11.2 database version preserved
Oracle 11.2 systems kept running on modern servers (Oracle Linux 7), overcoming compatibility barriers and software obsolescence.
Context

In a fast-paced sector like large-scale retail, the information system drives everything: from procurement to warehouses, all the way to the last receipt issued at the end of the day. Often, however, the critical nature of these processes leads companies to postpone maintenance, until they find themselves with servers that have been running nonstop for more than 10 years. This was the challenge we took on for Maxidi: renewing an outdated infrastructure that hosted a highly critical Oracle database.

The constraint: innovate without disruption.

What made the project unusual? The third-party ERP software required keeping Oracle 11.2, because heavy code customizations meant it was not certified for newer versions. We faced a paradox: installing “old” software on modern hardware and operating systems (Oracle Linux 7).

Problems

The project involved significant technical and procedural challenges.

  • Obsolescence and bugs: working with Oracle 11.2 in 2025 meant dealing with critical bugs, such as Data Guard broker errors that changed log destinations on their own, putting disaster recovery at risk.
  • Infrastructure inconsistencies: the servers supplied by the customer had inconsistent configurations (different ISO images, missing libraries) and shared disks with paths that did not match across nodes, making a standard Oracle Clusterware installation impossible.
  • OS compatibility: the Oracle Linux 7 kernel was too recent for the old database version, causing incompatibilities.

Switchover in under an hour

The customer's main concern was downtime. With a cascading migration strategy, in which the new infrastructure was first configured as a standby of the previous one, we kept the data perfectly and continuously synchronized, reducing the final switchover to a simple change of DNS records.

Solution

Our solution was to build a high availability architecture to ensure maximum reliability. Specifically, we implemented the following.

An 8-node architecture with 4 production nodes and 4 disaster recovery nodes. The new infrastructure was first installed as a standby of the previous production environment, so that it held an exact copy kept continuously and automatically in sync. A second standby was then attached in cascade, also fully synchronized.

Large-scale data management with 18 TB of data optimized on ASM storage. We configured an ASM architecture that separates the voting disks from the data (18 TB), so that a problem with the data could not compromise the stability of the entire cluster.

Tailored engineering, including a controlled Linux kernel downgrade to make the 11.2 database compatible with modern machines, plus manual fixes for critical Data Guard broker bugs and inconsistent shared disk paths.

Finally, we took care of relationship management: the project required complex mediation between the customer and the ERP vendor to align business needs with technical constraints.

Technologies
  • Database: Oracle Database 11g Release 2 Enterprise Edition.
  • Operating system: Oracle Linux 7 (with a customized kernel).
  • High availability: 4-node Oracle RAC (Real Application Clusters) + 4-node disaster recovery.
  • Storage: Oracle ASM (Automatic Storage Management) and ACFS.