Migration overview

In enterprise applications, it’s best practice to have separate development, staging, and production instances so that you can:

Establish a transparent change management process.
Test changes before you go live.
Ensure that the production environment is not compromised by configuration changes.

As advocates of this best practice, Oomnitza will provide additional instances to customers when requested. You can then make configuration changes and test them thoroughly in your development instance before you migrate the configuration changes to your production instance.

Need more Oomnitza instances?
Contact your Oomnitza account executive or customer success manager. They’ll help you get more instances and deploy them.

To test configuration changes before you go live, it is normally sufficient to have two separate instances:

A development instance
A production instance

However, if configuration changes involve integrating with multiple environments, you might need multiple instances.

Whatever your change management process is, we’re here to help you migrate the configuration of an instance from development to production. You won’t have to make configuration changes manually in each production environment, which can cause data entry errors and the mismatching of IDs.

Migrating and syncing a development and a production instance

The purpose of configuration migration is:

To establish a change management process for your Oomnitza instance
To migrate a configuration from a source to a target instance such as migrating the configuration of your development instance to your production instance.
To restrict changes in the production instance to ensure that both instances stay in sync
To keep production and development in sync by migrating the configuration of the production instance to the development instance

Tip
Avoid adversely affecting the performance of your production instance by migrating configuration changes when your production instance is least busy. Major configuration changes, such as field changes to a large asset or user database, can take a significant amount of time to be processed.

Re-baselining your development instance

It is essential that both your development and production instances are in sync before configuration changes are made to your development instance. For example, if a workflow, saved search, or any other object references master or transactional data such as a specific asset, specific user, or specific location you must ensure that these objects are in sync in your development and production instances.

The best way to ensure that both instances are in sync is to use the re-baselining process.

Before you begin, you must raise a ticket with support@oomnitza.com to request a re-baselining of your development instance.

During the re-baselining process, historical data that is over 30 days old for the following objects is deleted:

Login historical data
Workflows historical data
Assets historical data
Users historical data
Saved searches historical data

If you want to keep historical data for more than 30 days, you must specify this in the support ticket that you raise.

Warning
When the migration module is enabled and the configuration of the production instance is migrated to the development instance, you must ensure that you create any new custom fields in your development instance, and not in your production instance. If you create new custom fields in your production instance, the instances will become out of sync.

Best practice

To avoid making changes in the target instance that prevent you from running the migration, you can disable configuration changes in the target instance, which in this case is the production instance. See
Disable configuration changes in the target instance in Planning the migration.

Standalone and package migrations

You can create standalone or package migrations.

Standalone migrations

You choose standalone migrations to migrate the configuration of one or more types of objects such as Data Model fields, which comprise assets, desktop software, SaaS software, and so on. It’s an iterative process whereby you test and migrate the configuration of types of objects in a specified order.

Standalone migrations allow you to select the configurations that you want to update. Say you want to add recently defined global settings to a migration. All you need to do is select Global Setting as the migration type and select the settings that you want to migrate.

Package migrations

Choose package migrations when you want to migrate the configuration of extended integrations such as:

Asset integrations
User and SaaS user integrations

Unlike standalone migrations, package integrations migrate the integration and all its associated objects together such as:

The credentials that are used in the integration
The integration user
The dashboard and saved searches
The workflows

Information
In standalone migrations, you must migrate the credentials, dashboard, saved searches, and workflows separately and in a certain order because of dependencies between the types of objects.

You can create your own packages and migrate them.

Planning the migration