Home | AIEnterprise Inc.

ATG 11.3 Upgrade

Approach & Best Practices

  • Site Search features that impact shoppers’ engagement

Oracle ATG Web Commerce

Support for ATG Versions

Oracle has announced its support options for your specific version of ATG

Oracle ATG v10.x
Oracle ATGv11.1 - v11.2
Oracle ATG V11.3.2
Premier Support
  • Ended in Feb 2019
  • Ended in Feb 2019
  • Available till Feb 2022
Extended Support
  • Ended in Dec 2018
  • Support available only for the terminal patch set releases of Oracle Commerce Platform/CSC and Oracle Commerce Guided Search 11.2
  • Available till April 2025
Sustaining Support
  • Access available to service requests, knowledge articles, documentation, & approved fixes
  • Oracle will not provide new fixes
  • Support is provided with no guarantee of problem resolution
  • No end date

All customers are entitled to lifetime Sustaining Support per Oracle's Lifetime Support Policies. Under Sustaining Support, customers are entitled to open service requests and access any knowledge articles, documentation, and approved fixes, but Oracle will no longer provide new fixes or update 3rd party certifications. All Sustaining Support is done on a "reasonable efforts" basis with no guarantee of problem resolution. Customers maintain the right to upgrade if they are current on their support and maintenance contract

Retailers who want to continue their investment can consider upgrading to the latest version

Effort involved in the Migration

Listed below are the high-level areas which typically impact the migration effort

  1. The extent to which BCC has been customized
  2. The extent to which CSC has been customized
  3. The migration effort increases if any Application Server related features have been used. e.g., JMS Messaging, JCA, SMTP etc.
  4. Migration of Core Commerce components
    • JDK and ATG version upgrades
    • Upgrading deprecated APIs
    • Migration of 3rd party jars
    • Migration of SOAP WSDL jars
  5. Endeca Experience Migration
    • As long as the ATG Out of the Box (OOTB) indexing mechanism has been used, the effort involved here is low

Migration Approach

The first step is to usually identify the target environment. Illustrated below is an environment which we usually typically encounter in the migration process:

Application Server
Web logic 12c
Oracle 12c
Win 10 for Development, Red Hat Linux 6.7
JDBC Driver
JDK 1.8.0_251 (64 bit)
Oracle Commerce MDEX Engine Release 11.3.2
Tools and framework
Oracle Commerce Tools and Frameworks Release 11.3.2
Guided search
Oracle Commerce Guided Search Platform Services Release 11.3.2
Content Acquisition System
Oracle Commerce Content Acquisition System Release 11.3.2 (CAS)


Special attention must be given to Database DDLs, DMLs, and indexes during the migration:

  • Modify DDLs which can potentially create read/write lock on tables
  • DMLs which can modify large number of records in a table can potentially create locks. Modify such scripts to apply changes in small chunks using stored procedures
  • Creating Indexes on existing columns which have large data can cause potential issues. This is a difficult issue. Even though Oracle 11 has “ONLINE” and “parallel” index build processes, we need to avoid such activities especially on the “Order” or “Profile” tables and low traffic periods or alternate options should be identified
  • “Drop” columns requirements should be eliminated and should be executed only after complete migrations

Pre-Migration Tasks

This section involves the following high-level steps:

  • Back up the Oracle Commerce 11.1 database
  • Complete all Content Administration projects
  • Backup the version file store in the ATG data folder
  • CA Server / ATG-Data/Publishing folder
  • Storefront / ATG-Data/Publishing Agent

CIM based migration

  • The CIM based migration is performed only once on local dev environment, to collect and consolidate SQL Scripts
  • Once this is done, new schemas can be created for Oracle Commerce 11.3.2 and existing tables and data can be imported
  • Data should be imported for PUB and CORE only
  • For Switching Schemas (CATA and CATB), import meta data
  • Table data will be pushed into CATA and CATB when a full deployment is done from BCC
  • At the end of the CIM based migration, consolidate the SQL scripts per schema and create the shell scripts to execute the SQL scripts.

Commerce and Merchandising

  • Create new schemas for Oracle Commerce 11.3.2 and import the existing tables and data\
  • Execute the migration scripts
    • db_migration_core.sh
    • db_migration_switching.sh
    • db_migration_pub.sh
    • db_migration_agent.sh
  • After the execution of the db migration scripts and full deployment, create the replicas of CORE, CATA, CATB for staging
  • Update the JDK to 1.8.0_251 reference in the environments (eclipse, build, environment variables)
  • Install Web logic 12c ( and configure the data sources and JNDI
  • Update the reference to Oracle Commerce 11.3.2 in the environments
  • Identify the hot fixes applied in the Oracle Commerce 11.1 application; and remove if it has been fixed in the newer version (Oracle Commerce 11.3.2)
  • Replace Commerce Reference store 11.3.2 with Commerce Reference store 10.1.2
  • Fix the deprecated API (ATG/JDK) errors
  • Update the WebLogic
  • Update / Add ojdbc8.jar to the lib folder and configure the same in the classpath
  • Execute the following script to cleanup tables which are no longer used in the newer version. This contains tables related to ATG search which are no longer applicable. However, data in these tables should be reviewed in each of the environments before running this
    • script.db_cleanup_core.sql
    • db_cleanup_pub.sql
    • db_cleanup_switching.sql
    • db_cleanup_agent.sql
  • Build and create the CA, Store and AUX ears
  • Update the deployment topology and agents in BCC to point to the new environment
  • Test the upgraded application and verify all functionalities including integration (Web and Mobile)

CSC (Commerce Service Centre)

  • Create new schemas for Oracle Commerce 11.3.2 and import the existing tables and data from the AGENT schema
  • Execute DB migration scripts

Endeca App Migration

The high-level steps in Endeca Migration will be as follows:

  • Take a backup of Endeca application and services (version 11.1)
    • Back up/Exporting Workbench users from Tools and Frameworks
    • Back up the Workbench configuration files
    • Back up application content from Workbench
    • Back up CAS configuration and CAS index configuration
    • Back up Endeca Script Files
  • Create new Endeca application by using the new deployment template
  • Incorporate the backup with newly created Endeca application and services (11.3.2 version)
    • Restore CAS configuration.
    • Initialize the Endeca application.
    • Import Workbench users to Tools and Frameworks.
    • Restore CAS Index configuration.
    • Restore script files.
    • Migrate application content to Workbench.
  • Address all Endeca application and scripts issues
  • Validate and fix API response issues

Custom changes to be handled as part of Development Phase

  • Commerce Custom Code Changes
  • CA/Merchandising Custom Code Changes
  • CSC Custom Code Changes

Planning the Migration

Listed below are the high-level aspects that must be factored into a migration project plan

Planning the Migration

In addition to these, there are many more steps that need to be considered to ensure that one has a holistic project plan in place

Specific Activities

The below listed factors are intended to provide a sampling of the kind of changes inherent in an Oracle ATG migration. They do not constitute an exhaustive list of issues to be considered

  • Changes / updates to JSP Tab Libraries
  • Changes / updates to external / third party jars used in the application
  • Changes to deprecated Methods
  • Changes to database related changes
  • Updates to configuration / build scripts to support web logic 12c
  • Potential changes due to a migration to JDK

Deployment in Local Environment

The below listed factors are intended to provide a sampling of the kind of changes inherent in an Oracle ATG migration. They do not constitute an exhaustive list of issues to be considered

  • Installation of 11.3.2 software stack on local server
  • Take a db dump from SIT
  • Take a copy of the version file store from SIT
  • Import database dump (mask the customer data) and copy the version file store
  • Execute migration steps as described in the document per section 2.1.7
  • Update build.xml For WebLogic
  • Build the EAR with ATG 11.3.2 and JDK 1.8.0_251 and make necessary changes in the code to make it compatible with ATG 11.3.2
  • Deploy the latest ears and resolve issues if any
  • Create new Endeca APP
  • WebLogic configurations, JMS queue
  • Setup XM cartridges and template
  • Rebuild the ears with latest code base
  • Deploy the latest ears with 11.3.2 code base
  • Run Baseline Index

Deployment Steps across Environments

  • SIT
  • UAT
  • PROD

Additional Steps

Listed below are specific steps that need to be considered in a migration project

Task description
Procure additional hardware required for production
Install newer version of the software stack
Prepare the environment (Network setup, router configuration, Apache setup, ATGDB tool setup, create domains / server instances for Web logic)
Take a DB dump from production
Take a copy of the version file store from production
Import database dump and copy the version file store
Execute migration scripts
Deploy the latest ears
Setup the XM cartridges and template, and do a baseline update
Verification, Smoke Testing
Performance testing / Penetration / Security testing
Refresh with new data from production and re-configure
  • Take a DB dump from production
  • Take a copy of the version file store from production
  • Import database and copy the version file store
  • Execute migration steps
  • Deploy the latest ears
  • Do a BCC full deployment if required
  • Do a Baseline update for Endeca indexing
Do a final build. Verification, Smoke Testing
Cut over and Go-Live
  • Shut down the servers
  • Copy the CORE (Transactional schema) from production
  • Execute the migration script on the CORE schema
  • Start the servers
Have a rollback strategy ready