OCI Migration Case Study: Seamlessly Moving Oracle EBS 11i and 11g Database to the Cloud

 

Introduction

Many legacy enterprise systems still operate on aging infrastructure and unsupported platforms. In this scenario, the production Oracle E-Business Suite (EBS) 11.5.10.2 and Oracle Database 11.2.0.4 Enterprise Edition are hosted together on a single physical on-premises server running Oracle Linux 5.11 (64-bit). While this setup has supported critical business operations, it presents challenges such as hardware limitations, lack of vendor support, and upgrade constraints.

As a first step toward modernization, the entire environment is being migrated “as-is” to Oracle Cloud Infrastructure (OCI), using a custom Oracle Compute VM with Oracle Linux 5.11. This approach enables a seamless lift-and-shift migration with minimal downtime and no immediate application changes.

⚠️ Important to note: Although Oracle Linux 5.11 is out of support, moving to OCI provides the customer with flexibility and safety to later upgrade the OS and application stack at their own pace. We strongly recommend planning for this upgrade as part of the post-migration roadmap to ensure long-term supportability and security compliance.

At Eclipsys Solutions, we help organizations design and implement scalable, secure, and cost-effective OCI architectures. Our expertise ensures that even legacy workloads can transition to the cloud smoothly while laying the groundwork for future modernization.

This blog outlines the migration approach, highlights key considerations for running legacy systems in OCI, and explains how this sets the foundation for future upgrades

Steps to Create a Linux Custom Image for OCI

1. Build the OS Image in VirtualBox

• First, install Oracle Linux 5 (OEL 5.11) on a VirtualBox VM using the Oracle Linux 5 ISO.

• Configure and test the OS to ensure it boots properly with:

o Correct kernel and bootloader (GRUB).

o Clean /etc/fstab and network configuration.

o No hardware-specific drivers.

• Power off the VM once the OS setup is complete.

2. Export the VirtualBox Disk to Raw Format

• Locate the VirtualBox VM disk file (typically .vdi or .vmdk).

• Convert it to raw format using qemu-img:

# Install qemu-img if not already present

sudo yum install qemu-img   # On Oracle Linux / CentOS / RHEL

# Convert the VirtualBox disk to raw format

qemu-img convert -f vdi -O raw /path/to/disk.vdi OEL5.11.X86_64.10022025.img

Alternatively, if you are working directly with a physical disk (e.g., /dev/sda), you could use:

qemu-img convert -f raw -O raw /dev/sda OEL5.11.X86_64.10022025.img

Or first dump it using dd:

dd if=/dev/sda of=disk.raw

qemu-img convert -f raw -O raw disk.raw OEL5.11.X86_64.10022025.img

3. Upload the Image to OCI Object Storage

oci os object put -bn temp-os-img-bk --file OEL5.11.X86_64.10022025.img

Important OCI Requirements for Custom Image Import

• OCI requires raw disk images for custom image import.

• The file system must support UEFI or BIOS boot (OCI supports both).

• Your image must include:

o A properly configured GRUB bootloader.

o A compatible kernel (with OCI's virtualization platform).

o A clean /etc/fstab to avoid boot issues.

o Correct network configurations (such as DHCP-enabled eth0 or ens3).

o No hardware-specific drivers that tie the image to VirtualBox or other hypervisors.

Import Image to OCI Console:

Get the URL for the OEL5 image from personal tenancy 

https://testobjectstorage.objectstorage.ca-montreal-1.oci.customer-oci.com/p/TESTDUMMYdw5K56_DummygpK14KPo7ZyxVRZSauk1GpMvxnHjdakdasdlasdlasjdlasjda/n/asddummydummy/b/temp-os-img-bk/o/OEL5.11.X86_64.10022025 

Once the image import is complete. Set the compatible shapes 

VM.Optimized3.Flex 

VM.Standard.E4.Flex 

VM.Standard3.Flex 

VM.Standard.E5.Flex 

Create a Virtual Machine using the imported custom image:

1. Navigate to: Menu → Compute → Custom Images and select OEL5.11.X86_64.10022025.

2. Click Create Instance.

3. Configure the instance by selecting the required shape, subnet, and VCN, along with any other necessary resources.

4. Complete the instance creation process.

Create File System to Match the Source Environment

To ensure a seamless migration or deployment, it's important to create a file system structure that mirrors the source environment. This allows the application and services to function without requiring changes to file paths or configurations.

In this setup, we are using OCI Block Volumes to replicate the source file system structure. OCI Block Volumes provide persistent, high-performance storage that can be attached to virtual machines, making them ideal for hosting application file systems, data directories (/apps), backup (/backup) and stage (/stage).

•  Create OCI Block Volumes

• Provision block volumes sized to match the source environment.

•  Attach Block Volumes to Compute Instance

• Attach the volumes to your target VM in OCI.

•  Format the Volumes

• Format each block volume with the required file system type, here we are using ext3 to match the source environment (e.g., ext3, ext4, xfs).

•  Create and Mount Directories

• Create mount points that match the source environment’s directory structure.

• Mount the formatted volumes to these directories.

•  Persist Mounts Across Reboots

• Update the /etc/fstab file to ensure volumes are mounted automatically after reboot.

Steps for Preparing the Target Server for EBS and Database Migration

 

User and Group Setup

• Create required users: applprod and oraprod.

• Create necessary groups: oinstall, dba, and applmgr.

• Ensure that the user IDs (UIDs) and group IDs (GIDs) exactly match the source environment.

• Assign appropriate group memberships to the users as per the source system.

 

Host Configuration

• Add entries in /etc/hosts where the hostnames match the source system, but with the target environment’s new IP addresses.

• This ensures applications and scripts using hostname-based connections continue to work without changes.

 

System Parameters Configuration

• Update /etc/sysctl.conf to replicate the kernel parameters from the source server.

• Apply the updated settings using:

sysctl -p

 

Sendmail Configuration

• Configure sendmail to match the source system’s settings for outbound email.

• Update mail relay hosts, domain configurations, and restart the sendmail service.

 

CUPS Configuration

• Complete the CUPS (Common UNIX Printing System) setup.

• Replicate printer configurations and ensure all required printers and print queues are correctly set up.

 

Samba Installation and Configuration

• Install Samba packages on the target server.

• Configure smb.conf to match the shared folders and access settings from the source system.

Application and Database File System Migration

1. Stop the EBS Application on the source server.

2. Backup and Copy the Apps File System:

• Create a tar archive of the source apps file system (/apps/ebs/prod):

tar -cvf apps_prod.tar /apps/ebs/prod

• Copy the tar file to the target server and extract it under /apps/ebs/prod:

tar -xvf apps_prod.tar -C /

3. Backup and Duplicate the Database:

• Take an RMAN backup of the source database.

• Perform an RMAN duplicate on the target server to restore the database.

• Ensure that the database file system path is the same (/apps/oracle/prod) on both the source and target for consistency and ease of recovery.

 

⚠️ Important Note:

Both the EBS Apps file system (/apps/ebs/prod) and the Oracle Database file system (/apps/oracle/prod) are identical on the source and target.

This simplifies the migration process and minimizes post-migration configuration changes.

Update DNS and Verify Database Connectivity

DNS Update

• Update the DNS entries to reflect the new server's IP address for the application and database hostnames.

 

Verify Database Connectivity from Apps Tier

• Log in as the applprod user on the application server.

• Test database connectivity using SQL*Plus or similar:

sqlplus applprod/<password>@<TNS_ALIAS>

 

Check FND_NODES Table for Correct Server IP

• Run the following query to verify the server address:

SELECT server_address FROM fnd_nodes;

• If it still shows the old server IP address, perform the following:

 

Fix Incorrect Server IP in FND_NODES

1. Run the cleanup procedure on the apps user:

EXEC fnd_conc_clone.setup_clean;

2. Run Autoconfig on both the database and application servers to regenerate configuration files and update the node information:

$AD_TOP/bin/adconfig.sh contextfile=<path_to_context_file>

Now that the DNS has been updated and all configurations are complete, the Oracle E-Business Suite application should be accessible using the new DNS hostname.

Verify that you can log in to the EBS application through the web URL and that all services (Concurrent Manager, Workflow, etc.) are functioning as expected.

Conclusion

In this blog, we discussed the migration approach for moving Oracle E-Business Suite and its database from a legacy system to an OCI Virtual Machine (VM) environment.

This approach ensures that the new OCI environment mirrors the legacy system, helping to minimize application changes and enabling a smoother cutover to the cloud.

 

What’s Next?

In the next blog, we will cover the challenges encountered during this migration process, along with the solutions implemented to resolve them. Stay tuned to learn from real-world troubleshooting scenarios and best practices for a successful migration.