Migrating Oracle E-Business Suite 12.2 to AWS
Migrating Oracle E-Business Suite version 12.2 to AWS was a challenge that we undertook for Mitsubishi Development Pty Ltd based in Brisbane in the year 2018. The complexity is setting up a working environment on the AWS cloud a it existed when the entire application was on-premise. Copying the application code and the database is usually the easiest of the tasks. A four pgase process was followed before succesfully completing the migration involving a Proof of concept, Test Migration, Production igration and finally Post Migration support.
Migration of the application from on-premise to the AWS is never the most difficult aspect.Invariably the integrations in a hybrid architecture, application extenions and customizations which were written when cloud was not a reality pose the biggest risk to such projects
The Critical Components
The contractual understandings and SLAs between the Aws and the client Mitsubishi were outside our scope and our brief was restricted to the technical aspects of the migration. A brief summary of critical component setup during such a move is listed below and explained in subsequent paragraphs.
- Preparation for the Project
- Provisioning a VPN between AWS and Client Site
- Provisioning Firewall Rule for Security
- Ensuring Monitoring is setup to match on-site setups
- Setting up Backups and Testing Restore functionality
- Provisioning Network File Shares
- Reworking Customizations and Integrations that require changes
- Enable and test extensions to the Oracle E-Business Suite
- Setups to meet printing requirements
- The Actual Lift and Shift
Critical Component Planning , Setup and Migration
As mentioned earlier the project followed a four phase approach to the migration project ensuring ITIL procedures were followed and the involvement and engagement of all stakeholders. In the first phase a POC environment was created to demonstrate the proposed solution. The second phase involved the migration Mitsubishi’s test environment to AWS. All customizations and integrations were enabled and tested and reworked as needed. In the third phase the production environment was shifted to AWS over a long weekend, followed up by user verification and sign-off. The final phase involved post go-live heightened support for a brief period of two weeks to ensure that the application continued to function as expected without any issues or bottleneck and also iron out any issues that cropped up.
Preparation for the Project
Early in the planning phase it was worked out that a “like for like” migration approach would be adopted in terms of OS, OS version, CPU, Memory and Disk Capacities. This was to ensure the significant change is not clouded by issues that are peripheral to the migration project. The on-premise server operating systems (Oracle Enterprise Linux) and versions were brought to supported levels to also match any AWS side restrictions.
Provisioning a VPN between AWS and Client Site
A VPC was established on AWS as the first step along with the subnet that would be associated with Mitsubishi’s VPN endpoint (including the CIDR ranges). There are certain restrictions for customer side VPN the limitations are explained here. The identified subnet was then associated with the Mitsubishi VPN endpoint. A route was added to allow AWS Site-to-Site VPN connection followed by an authorization rule to allow clients access to AWS site-to-site VPN connection.
Provisioning Servers and Firewall Rules
Each environment of Oracle Ebusiness Suite required two servers (one for the application and one for the database) to be provisioned. The servers were provisioned “like for like” with required packges for supporting Oracle E-Biz on the database and application servers, as was decided in the planning phase in the relevant subnet. Server capacities, in terms of CPU, Memory, Filesystems were atleast matched while selecting the server size during server provisioning at AWS. IPTables were setup on the server to restrict access to the servers and insecure utilities like telnet disabled, while ssh was enabled and logins to the server were allowed only using encrypted keys from nominated IP addresses on the client side. Strict firewall rules were also established to restrict access to the application ports from inside MDP’s network and SSL was enabled for application access.
Ensuring Monitoring is setup to match on-site setups
Mitsubishi had been using “Logic Monitor” as their tool for monitoring the servers and the oracle databases. While on premise, snmp packages were enabled and were used to communicate with Logic Monitor. Required packages were setup and enabled once the migration of the application was completed.
Provisioning Network File Shares
Mitsubishi Development Pty Ltd used NFS shared mounted on the E-Business application server for the Concurrent Programs to pick up input files and create output file for specific programs for which teh users needed access. The same setup was provisioned to enable easy drag and drop of files for end users.
Reworking Customizations and Integrations that require changes
All customizations and integrations were thoroughly tested by engaging the user community during the test phase and issues identified were fixed in the rare cases by fixing code.
Enable and test extensions to the Oracle E-Business Suite
It is very common for Oracle E-Business Suite to be used in conjunction with ADi (Application Desktop Integrator) browser based and also tools such as GLWand (also called Excel4Apps. Despite these running from the application server or database they tend to spring surprises. These are tools extensively used by accountants to upload journals and thir month end , year end activities are bound to be ruined should they not work. So special care was taken to ensure that sufficient testing was done with the Excel4Apps extension in particular.
Setups to meet printing requirements
Commincations were restricted at the MDP firewall as well to ensure that inward communications to the On-Premise resources were from known sources. Thus special firewall rules had to be put in place to allo thw application server to cummunicate with the printers on premise though the CUPS protocol.
The Actual Lift and Shift
Pre migration reports including trial balance, open purchase orders, invoices for receivabke and payabes were all run and reports taken prior to actual migration. All integration sources were turned off and monitoring turned off for the duration of the migration activity. The actual lift and shift followed using the standard cloning procedure. The well worn path of pre-clone activities, transfer of code and database to target locations and execution of post clone activities was performed in appropriate sequence. Special mention must be made that backups of the database were taken using RMAN. The binaries were packaged utilizing the tar and gzip unix utilities and transferring to AWS. Post migration a limited number of users ran the same reports to compare that the before and after status of the application for sign-off. The rollback plan was to revert back to using the on premise database and application which had been quiesced for the migration activity. The activity was completed over a long weekend successfuky and teh on-premise database and application servers decommissioned in due course after appropriate backups.
Talk to us if you need our help.