Close Menu

    Migrate Oracle applications and databases using AWS Application Migration Service

    Migrating an Oracle application and its underlying database to the cloud can be inherently complex. Complexity is significantly amplified by various factors, including operating system compatibility, database and application version, software availability, database storage technologies such as Automatic Storage Management (ASM), and stringent business downtime requirements. The challenges become even more significant when dealing with sophisticated, enterprise resource planning (ERP) applications. Successfully navigating these complexities demands meticulous planning and precise execution to achieve a seamless transition.

    AWS Application Migration Service accelerates the migration of applications to Amazon Web Services (AWS) by automatically replicating entire servers at the block level. This continuous block-level replication helps ensure that any changes made to the source servers are efficiently captured and replicated in near real time. By using this method, Application Migration Service minimizes data loss and supports cutover to AWS with minimal downtime. This process is automated and scalable, making it an ideal solution for migrating complex, mission-critical workloads to the cloud.

    In this post, we show you the process of migrating Oracle E-Business Suite to AWS using Application Migration Service.

    Source environment configuration

    The migration process begins with an Oracle E-Business Suite setup that includes:

    • One dedicated application server
    • Oracle E-Business Suite version R12.2.10
    • One dedicated database server
    • Oracle Database version 19.0.0.0

    Target AWS environment

    The AWS target environment is designed to replicate the source architecture, maintaining:

    Solution overview

    The following diagram shows the solution architecture for migrating from Oracle E-Business Suite to AWS.

    This solution uses the following AWS services:

    The high-level steps to implement this solution are as follows:

    1. Create a VPC endpoint for Application Migration Service
    2. Create an AWS Identity and Access Management (IAM) user and roles
    3. Create temporary credentials for Application Migration Service
    4. Install the AWS Replication Agent in the source server
    5. Create and configure an Amazon EC2 launch template
    6. Activate post launch settings for AWS Systems Manager Agent (SSM Agent) installation
    7. Check data replication status in the AWS Management Console for Application Migration Service
    8. Launch an Application Migration Service test instance for Oracle E-Business Suite database and application servers
    9. Configure the Oracle E-Business Suite database tier on the target database server test instance
    10. Configure the Oracle E-Business Suite application tier on the target application server test instance
    11. Mark as ready for cutover in the Application Migration Service console
    12. Launch cutover Instances in the Application Migration Service console
    13. Configure the Oracle E-Business Suites database and application tier on the cutover instances
    14. Finalize cutover in the Application Migration Service console

    Prerequisites

    To follow along with this post, you must have the following prerequisites:

    Because this solution involves setting up and using AWS resources, it will incur costs in your account. See AWS Pricing for more information. We strongly recommend that you set this up in a non-production instance and run end-to-end validations before you implement this solution in a production environment.

    Solution walkthrough

    In this section, we’re going to walk you through the steps required to migrate an Oracle application and database to AWS using Application Migration Service.

    Create a VPC endpoint

    Start by creating a VPC endpoint for Application Migration Service using the instructions at Access an AWS service using an interface VPC endpoint.

    IAM user and roles setup

    Create an AWS Identity and Access Management (IAM) user, and then assign the AWS Replication Agent permissions policy to the IAM user. For more information on IAM resources, see Permissions required to access IAM resources.

    Generate temporary credentials

    Follow the instructions to generate temporary credentials. You will use the generated credentials to install the AWS Replication Agent in the source servers.

    Install the AWS Replication Agent

    Install the AWS Replication Agent on the source servers. After the AWS Replication Agent is installed on both the database and the application servers, it captures data changes and metadata, replicating the entire environment to the AWS Cloud. This ensures a consistent and reliable migration process.

    To install the AWS Replication Agent on the source server:

    1. Create the Application Migration Service installation directory on the source server. Make sure there is at least 2 GB of free space on the install directory.
    2. Download the agent installation files using the following command 
      sudo wget -O ./aws-replication-installer-init https://aws-application-migration-service-us-east-1.s3.us-east-1.amazonaws.com/latest/linux/aws-replication-installer-init
    3. Install the agent on the installation directory using the following command 
      sudo chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init --region us-east-1
    4. During the installation process, the installer identifies volumes for replication and displays them. You’ll be prompted to select which disks to replicate. The root volume is automatically replicated, regardless of your selection. To replicate additional data disks, enter their paths, separated by commas, as shown in the following screen shot. The paths will be similar to /dev/sda, /dev/sdb. To replicate all disks, press Enter. The installer will then confirm the selected disks and display their sizes.
      Example screenshot showing AWS Replication Agent installation. It includes AWS credentials, region, and identified volumes for replication.

      Example screenshot showing AWS Replication Agent installation. It includes AWS credentials, region, and identified volumes for replication.

    5. After all of the disks to be replicated have been successfully identified, the installer will download and install the AWS Replication Agent on the source server.
    6. After the AWS Replication Agent is installed, the server will be added to the Application Migration Service console and will undergo the initial sync process.
      Example screenshot showing the initiation of the sync with the Application migration services console.

      Example screenshot showing the initiation of the sync with the Application migration services console.

    7. Check the log file for any installation errors

    For additional instructions on the AWS Replication Agent installation, see the AWS Replication Agent installation instructions.

    Configure the EC2 launch template

    AWS Application Migration Service uses EC2 launch templates to launch, test, and cutover EC2 instances for each source server. The EC2 launch template is created automatically for each source server that’s added to Application Migration Service upon installation of the AWS Replication Agent. An EC2 launch template defines the configuration for EC2 instances created during the migration process. It specifies details such as instance type, security groups, subnets, and other settings. Essentially, it’s a blueprint for the target Oracle E-Business Suite environment. The default EC2 launch template needs to be edited to satisfy the target EC2 application and database server requirements.

    To set the new version of your launch template as the default:

    1. Navigate to the EC2 Launch templates page on EC2 console
    2. Choose your launch template by selecting the toggle to the left of the Launch template ID.
    3. Choose Actions and select Modify template (Create new version).
      Example screenshot of “Launch template version details” screen with "Modify template (Create new version)" selected in Actions dropdown menu.

      Example screenshot of “Launch template version details” screen with “Modify template (Create new version)” selected in Actions dropdown menu.

    4. Template version description – Enter a meaningful template description that fits your organization standards.
      Example screenshot of "Modify template (Create new version)" with fields for template name, version description, and Auto Scaling guidance.

      Example screenshot of “Modify template (Create new version)” with fields for template name, version description, and Auto Scaling guidance.

    5. For launch template contents leave the default Don’t include in launch template radio button selected as shown
      Example screenshot showing the "Launch template contents" where you can specify an Amazon Machine Image (AMI) for your instance. Default option of Don’t include in launch template selected.

      Example screenshot showing the “Launch template contents” where you can specify an Amazon Machine Image (AMI) for your instance. Default option of Don’t include in launch template selected.

    6. Make sure that you select an instance type that matches the hardware requirements of your source server. AWS Application Migration Service always uses the instance type that is set on the EC2 launch template unless the instance right-sizing feature is activated.
      Example screenshot showing the EC2 instance type selection as part of Launch template configuration.

      Example screenshot showing the EC2 instance type selection as part of Launch template configuration.

    7. Select the VPC and subnet for the target application and database servers.
      Example screenshot showing the Network settings for the EC2 instance type as part of Launch template configuration.

      Example screenshot showing the Network settings for the EC2 instance type as part of Launch template configuration.

    8. Choose Create template version.
      Example screenshot showing the Create template version button.

      Example screenshot showing the Create template version button.

    9. Choose View launch templates to set the default version to the latest.
      Example screenshot showing the successful creation of launch template and option to view the launch templates page.

      Example screenshot showing the successful creation of launch template and option to view the launch templates page.

    10. You can now see that the default version is 1 and the latest version is 2.
      Example screenshot showing the different versions of launch templates.

      Example screenshot showing the different versions of launch templates.

    11. To set the new version of your launch template as the default, select the launch template ID and:
      1. In Version, select 2.
      2. Choose Actions and select Set default version.
      3. The Amazon EC2 console will confirm the version change.
      Example screenshot showing the “Launch template version details” page with Set default version selected in Actions dropdown menu

      Example screenshot showing the “Launch template version details” page with Set default version selected in Actions dropdown menu

    12. Choose Set as default version.
      Example screenshot showing the “Set default version” popup window with Template version 2 selected.

      Example screenshot showing the “Set default version” popup window with Template version 2 selected.

    The AWS Application Migration Service provides a comprehensive set of launch settings that you can use to customize the target environment for your migrated instances, helping to optimize them for your specific requirements. You can use these settings to select the appropriate EC2 instance type, configure the storage volumes, and define the networking parameters.

    Disk settings – For the Oracle E-Business Suite database and application servers, the disk settings are customized to ensure the target storage volumes have the appropriate size, type (for example, SSD or provisioned IOPS), and IOPS capacity to meet the performance requirements of the Oracle E-Business Suite workload.

    The Disk settings tab shows a list of all the disks on the source server and information about each disk, as shown in the following figure.

    Example screenshot showing the “Disk settings” along with the list of disks to be replicated from source to target servers.

    Example screenshot showing the “Disk settings” along with the list of disks to be replicated from source to target servers.

    Replication settings – The replication settings are configured to optimize the data synchronization process, such as adjusting the replication frequency, bandwidth throttling, and enabling encryption to ensure a secure and efficient transfer of data from the on-premises environment to the AWS Cloud.

    Launch settings – The launch settings are edited to select the appropriate EC2 instance types for the Oracle E-Business Suite application servers and database, configure the network settings (VPC, subnets, or security groups) to integrate the migrated instances into the existing AWS infrastructure, and apply relevant tags and IAM roles to align with organizational policies.

    Post-launch settings – After the instances are launched, additional post-launch settings and configurations are often required, such as installing custom software, applying specific security hardening, and integrating the migrated Oracle E-Business Suite environment with other AWS services (such as for monitoring, backup, or disaster recovery) to ensure a fully operational and well-managed solution in the AWS Cloud.

    For more details, see Migration dashboard in the Application Migration Service documentation.

    Configure the SSM agent

    Activate post-launch settings for AWS Systems Manager agent installation in Application Migration Serviceby following the steps in Activating post-launch settings.

    Verify data replication

    Use the Data replication status section in MGN console to verify the overall source server status. The following figure shows the rapid replication of 16 GB of data from an on-premises server to an Amazon EC2 instance accomplished in only 3 minutes. The duration of initial replication is influenced by the data volume, network bandwidth, and the size of the EC2 replication instance. When dealing with multi-terabyte datasets, it’s advisable to begin with a larger EC2 instance for the initial replication, then downsize for continuous replication tasks.

    Example screenshot showing the “Data replication status” and the Replication progress with Total replicated storage, Backlog, Elapsed replication time, Last seen time and Replication start time.

    Example screenshot showing the “Data replication status” and the Replication progress with Total replicated storage, Backlog, Elapsed replication time, Last seen time and Replication start time.

    Information on the Data replications status page includes:

    • Replication progress– The percentage of the server’s storage that was successfully replicated.
    • Rescan progress– The percentage of the server’s storage that was rescanned (in the event of a rescan).
    • Total replicated storage– The total amount of storage replicated (in GiB).
    • Lag– Whether the server is experiencing any lag. If it is, the lag time is indicated.
    • Backlog– Whether there is any backlog on the server (in MiB)
    • Elapsed replication time– Time elapsed since replication first began on the server.
    • Last seen– The last time the server successfully connected to Application Migration Service.
    • Replication start time– The date and time replication first began on the server.

    Launch test instance

    After the initial replication completes, the status changes from Not ready to Ready for testing, as shown in the following screenshot. This step launches a test instance for your replicated server for validation before cutover from Oracle E-Business Suite to Amazon EC2.

    Example screenshot showing the AWS Application Migration Service interface with tabs for migration dashboard, server info, and settings. The lifecycle status indicates "Ready for testing."

    Example screenshot showing the AWS Application Migration Service interface with tabs for migration dashboard, server info, and settings. The lifecycle status indicates “Ready for testing.”

    On the Test and cutover dropdown menu, select Launch test instances. This process launches a test instance that you can use to validate the migration process, application compatibility, and performance before the final cutover.

    Example screenshot showing the AWS Application Migration Service interface with option to Launch test instances selected under Replication dropdown menu.

    Example screenshot showing the AWS Application Migration Service interface with option to Launch test instances selected under Replication dropdown menu.

    Configure the Oracle E-Business Suite database tier on the test instance

    When replicating an entire server with Application Migration Service, the service continuously copies the server’s data, including the hostname, operating system, applications, and settings, to a staging area in AWS. This real-time replication ensures that the target environment is consistently updated, minimizing downtime during the cutover. After replication is complete, the server is launched in AWS, maintaining the original server’s configuration, allowing for a seamless transition to the cloud.

    At this stage, the entire server is successfully replicated to AWS, and you’re ready to start the database and application. However, the replicated server in AWS still contains the source machine data such as the names and IP address details in the /etc/hosts file. To ensure proper functionality in the AWS environment, you need to edit the /etc/hosts file and update the IP address accordingly. This step is crucial to align the server’s network configuration with its new AWS environment before proceeding with the database and application configuration.

    In this section we use the following placeholders:

    <DB_OS_USER>: Operating system user of Oracle E-Business Suite database.
    <CONTAINER_DB_NAME>: Container database name (CDB)
    <PLUGGABLE_DB_NAME>: Pluggable database name
    <HOSTNAME>: Hostname of Oracle database.
    <LISTENER_NAME>: Listener name of Oracle E-Business Suite database.

    Replace these with your actual configuration values.
    To edit the /etc/hosts file and configure the Oracle E-Business Suite database server:

    1. Connect to the EC2 instance by following the instructions in Connect to Your Amazon EC2 instance using Session Manager.
    2. Edit the /etc/hosts file to set the IP address to reflect the new IP address assigned to the server in AWS. The Application Migration Service replication process maintains the same hostname as your source environment. 
      bash
sudo vi /etc/hosts
    3. Locate the line with the old IP address of your source server and replace it with the new IP address assigned to the target EC2 instance. Make sure the hostname remains the same. Save the changes and exit the editor.
    4. Set the environment variables for Oracle Grid and start the ASM instance and listener. For this step, make sure that you’re signed in to the database server and execute the command as the owner operating system user of the ASM instance. In the example command that follows, we assume that the operating system user is grid. 
      bash
sudo su – grid
export ORACLE_HOME=<GRID_ORACLE_HOME_PATH>
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export SID=+ASM
srvctl start asm
srvctl start listener
    5. There are multiple ways to check if the ASM instance and its listener is up and running. The following is a sample command to check the status. 
      ps -ef | grep pmon | grep ASM
srvctl status listener

      Make sure that both are up and running before moving ahead.

      If the listener is configured with an IP address, then you need to update the

      listener.ora file with the IP address of your current EC2 instance. Use the following

      command to edit the listener.ora file:

      vi $ORACLE_HOME/network/admin/listener.ora

      Locate the line with the old IP address of your source server and replace it with the new IP address assigned to the target EC2 instance. Save the changes and exit the editor.

    6. Set the appropriate environment variables for Oracle Home and start the database instance and listener. For this step, make sure that you’re signed in to the database server and execute the command as the owner operating system user of the Oracle database. As mentioned previously, Application Migration Service maintains the same hostname and the database name as your source environment. 
      bash
sudo su – <DB_OS_USER>
export ORACLE_HOME=<ORACLE_HOME_PATH>
cd $ORACLE_HOME
#Source the environment file of the Container database
. ./<CONTAINER_DB_NAME>_<HOSTNAME>.env
sqlplus / as sysdba
startup database
lsnrctl start <LISTENER_NAME>
    7. There are multiple ways to check if the Oracle database and its listener are up and running. The following is a sample command to check the status. 
      ps -ef | grep pmon | grep <CONTAINER_DB_NAME>
srvctl status <CONTAINER_DB_NAME>
sqlplus / as sydba
show pdbs
exit
lsnrctl status <LISTENER_NAME>

      Make sure that all the pluggable databases and the database listener are up and running before moving to the next step.

      NOTE: If the listener is configured with an IP address, then you need to update the listener.ora file with the IP address of your current EC2 instance. Use the following command to edit the listener.ora file.

      vi $ORACLE_HOME/network/admin/listener.ora

      Locate the line with the old IP address of your source server and replace it with the new IP address assigned to the target EC2 instance. Save the changes and exit the editor.

    8. Run autoconfig on the database tier. For this step, the environment file of the pluggable database is sourced. 
      bash
sudo su – <DB_OS_USER>
export ORACLE_HOME=<ORACLE_HOME_PATH>
cd $ORACLE_HOME
#Source the environment file of the pluggable database
. ./<PLUGGABLE_DB_NAME>_<HOSTNAME>.env
cd $ADMIN_SCRIPTS_HOME
# Run autoconfig using the below script. This script would prompt for apps password
sh adautocfg.sh

    After the autoconfig is executed, check the log to ensure there are no errors. For assistance with troubleshooting autoconfig errors, see the How to troubleshoot autoconfig errors (Doc ID 845700.1).

    Optional: Carry out any additional steps specific to your environment, such as updating database initialization parameters and validating database links, which are standard tasks in database administration.

    Configure the Oracle E-Business Suite Application Tier on the test instance

    Similar to the database server, the application server has also been fully replicated to AWS. And similar to the database server, you need to edit the /etc/hosts file on the application server to update the IP address to its new value in the AWS environment. This step makes sure that all network references are correctly aligned for the server’s new location.

    In this section we use the following placeholders:

    <APPL_OS_USER>: Operating system user of Oracle E-Business Suite application.
    <APPL_BASE_PATH>: Application base path

    Replace these with your actual configuration values.

    To edit the /etc/hosts file on the application server and configure the Oracle E-Business suite application:

    1. Connect to the EC2 instance by following the instructions in Connect to Your Amazon EC2 instance using Session Manager.
    2. Edit the /etc/hosts file to set the IP address to reflect the new IP address assigned to the server in AWS. The Application Migration Service replication process maintains the same hostname as your source environment. 
      bash
sudo vi /etc/hosts

      Locate the line with the old IP address of your source server and replace it with the new IP address assigned to the target EC2 instance. Make sure that the hostname remains the same. Save the changes and exit the editor.

    3. Source the Oracle E-Business Suite Environment of the run file system and run the autoconfig. For this step, make sure that you’re signed in to the application server and execute the command as the owner operating system user of the application instance. 
      bash
sudo su – <APPL_OS_USER>
cd <APPL_BASE_PATH>
#Source the run file system
. ./EBSapps.env run
cd $ADMIN_SCRIPTS_HOME
# Run autoconfig using the below script. This script would prompt for apps password
sh adautocfg.sh

      After the autoconfig is executed, check the log to make sure that there are no errors before moving to the next step. For assistance with troubleshooting autoconfig errors, see How to troubleshoot autoconfig errors (Doc ID 845700.1).

    4. Start the Oracle E-Business Suite application services. 
      bash
sudo su – <APPL_OS_USER>
cd <APPL_BASE_PATH>
#Source the run file system
. ./EBSapps.env run
cd $ADMIN_SCRIPTS_HOME
# Start application using adstrtal.sh. The script prompts for apps and weblogic password
sh adstrtal.sh

      Check the application startup log at $INST_TOP/logs/appl/admin/log to make sure there are no errors.

    5. Open the application URL to make sure that the application is running smoothly and is accessible without errors.

    Optional: Complete any additional application post-configuration steps specific to your environment.

    Mark as ready for cutover

    After the testing is completed, choose Test and cutover  and select Mark as “Ready for cutover”. This state indicates that a source server has been successfully replicated to AWS and is prepared for the final transition to the AWS environment.

    Example screenshot showing the AWS Application Migration Service interface with option to Mark as “Ready for cutover” selected under Replication dropdown menu.

    Example screenshot showing the AWS Application Migration Service interface with option to Mark as “Ready for cutover” selected under Replication dropdown menu.

    Launch the cutover instance

    To launch the cutover instance, choose Test and cutover and select Launch cutover instances.

    Configure the Oracle E-Business Suite database and application tier on the cutover instances

    When the cutover instances are launched, the EC2 instances will mirror the state achieved in the Launch Test Instance section. Subsequently, you need to configure the Oracle E-Business Suite database and application tier on the cutover instances, following the procedures outlined in the Configure the Oracle E-Business Suite database tier on the test instance and Configure the Oracle E-Business Suite Application Tier on the test instance.

    Finalize and verify cutover

    This action changes the server’s migration lifecycle status to Cutover complete, stops data replication, and terminates the AWS resources used for replication. The AWS Replication Agent will be uninstalled from the source server within 10 minutes.

    Clean up

    To avoid incurring unnecessary future charges, clean up the resources you created as part of this solution:

    1. Select the source server. Choose Actions and select Mark as archived. The server should no longer be visible in the Application Migration Service console.
    2. OPTIONAL: If you followed this with the intent of using the cutover instance, skip this step. If you followed this guide as a learning exercise, then delete the target EC2 instance to avoid incurring costs for it and the associated Amazon EBS volume. On the EC2 dashboard, select your instance. From the Instance state dropdown, choose Terminate instance.

    Conclusion

    In this post, we shared how to migrate an Oracle E-Business Suite application and database using Application Migration Service.

    The process outlined in this post helps you to successfully migrate the environment, including the critical Oracle ASM disk group, from on premises to the AWS Cloud. Using the Application Migration Service capabilities, you can achieve a seamless migration of both application and database tiers while effectively addressing the challenges of migrating Oracle ASM. Your thoughts and experiences are valuable, feel free to share them in the comments section.

    About the Authors

    Kavita Vellala is a Senior Database Consultant with AWS and brings a vast experience of database technologies. At AWS, she helps empower customers with their digital transformation and accelerate migration of their database workload to the AWS Cloud. She enjoys adapting innovative artificial intelligence and machine learning (AI/ML) technologies to help companies solve new problems and solve old problems more efficiently and effectively.

    Sridhar Mahadevan is a Specialist Solutions Architect at AWS, specializing in serverless technologies and ERP migration. He excels in architecting and automating ERP workloads on AWS, leveraging his expertise in ERP use cases. His strong background in serverless solutions, databases, and middleware enhances his ability to deliver efficient cloud solutions.

    Naor Alves is a Database Consultant with AWS with more than 20 years of experience on database technologies on multiple database engines. At AWS, he helps customers on their journey of database migration to the AWS Cloud and supports customers to adopt proper database on application modernization.

    Source: Read More

    Hostinger

    Related Posts

    Leave A Reply