Document Properties
Last Modified22-Jun-2020
Added to KB20-Sep-2016
Public AccessEveryone
Doc TypeGuidelines, Concepts & Cookbooks
ProductIOM 2.1

Guide - IOM Database Migration 2.1

1 Introduction

This document describes how to migrate the database from Intershop Order Management version 2.1.0 to version 2.1.x.

The guide mainly targets technical services e.g. administrators and consultants and developers.


No Migration of System

Please note that there is currrently no migration of the system itself. A new installation is required using the approriate Guide - Intershop Order Management 2.1 - Installation and the noted changes to IOM version 2.1.x.

1.1 Prerequisites

The installation of IOM version 2.1.x is required. Please see Guide - Setup Intershop Order Management 2.1.

1.1.1 Knowledge

Knowledge on following documents are required

1.2 Glossary

IOMThe abbreviation for Intershop Order Management
OMSThe abbreviation for Order Management System, the technical name of IOM
SQLStructured Query Language

1.3 References

2 Release Package

The release package contains all scripts to migrate the database.

Ensure you are familiar with the IOM properties and variables that are delivered as part of release package.

Refer section 3 Definition of Properties of Guide - Setup Intershop Order Management 2.1 - at least the following ones:

  • Installation Properties - $OMS_USER and $OMS_HOME
  • Cluster Properties -, is.oms.db.port, is.oms.db.user and is.oms.db.user

2.1 Extraction

Reuse the properties of cluster, deployment, and installation from 2.1.0 installation as much as possible. Hence, only specific contents are extracted from the release package on backend server.

Extracting specific contents from the IOM release package
# after placing the package in $OMS_HOME in backend server
# as $OMS_USER

# extract for database migration
tar -xvf IOM-2.1.X.X.tgz postgres/migrations 

3 Data Migration - dbmigrate

This sub-section explains the steps involved during data migration.

3.1 On a Test Server


Database Backup on Errors

The only way to roll back the database migration in case of an error is to replace the database with a backup.
It is thus essential to first test the migration against a recent copy of the database before running it against the live data.

  1. Extract the release package of the IOM.
  2. Execute the script located in $OMS_HOME/bin.

    Setting environment variables
    # as $OMS_USER
    cd $OMS_HOME/bin
    # mind the empty space after the first dot
    . ./

    This performs the required SQL migration scripts located within the folder $OMS_HOME/postgres/migrations.

    Performing the data migration
    # as $OMS_USER 
    # set variables
    IS_OMS_DB_HOST=<value of your test database server's IP address> # Example:
    IS_OMS_DB_PORT=<value of your test database server's port> # Example: 5432 
    IS_OMS_DB_USER=<value of your test database user> # Example: oms_user
    IS_OMS_DB_NAME=<value of your test database name> # Example: oms_db
    # calling migration script with parameters
    ./ -h $IS_OMS_DB_HOST -p $IS_OMS_DB_PORT -U $IS_OMS_DB_USER -d $IS_OMS_DB_NAME  2>&1 | tee dbmigrate.test.out

    Abort on connect error

    The script will abort immediately with a message if it cannot connect to the database, e.g., due to some missing entry within the postgres ph_hba.conf file.

  3. When the script runs without any error, the last line of the output will be success.

    next: /cygdrive/d/SVN/OMS/trunk/postgres/migrations/2.1.X.X/migrate_to_2.1.1.0_006.sql
    next: /cygdrive/d/SVN/OMS/trunk/postgres/migrations/2.1.X.X/migrate_to_2.1.1.0_007.sql
    next: /cygdrive/d/SVN/OMS/trunk/postgres/migrations/2.1.X.X/migrate_to_2.1.1.0_008.sql

    Errors will be displayed in the console output and logged in the dbmigrate.test.out file. The postgres log file may contain additional information.

    If any errors occurs, they must be analyzed and possibly fixed prior to the execution of against the live system.

3.2 On a Production Server


The following operation must not be performed until all IOM application server instances are stopped!

  1. Stop all server instances.

    Stopping WildFly service
    # as root user
    systemctl stop <wildfly-service-name>
  2. Set environment variables.
    By default, dbmigrate uses the connection parameters from environment variables which are set by

    Setting environment variables - later used by dbmigrate
    # as $OMS_USER
    cd $OMS_HOME/bin
    # mind the empty space after the first dot
    . ./
  3. Execute the database migration.

    Performing the database migration
    # as $OMS_USER
    ./ 2>&1 | tee dbmigrate.log.out

    Errors will be displayed in the console output as well as logged in the dbmigrate.log.out. The postgres log file may contain additional information.


The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources