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.


Figure 1: 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

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.

Standalone and package migrations

You can migrate configurations as standalone objects or as packages.

Standalone migrations

You choose standalone migrations to migrate the configuration of one or more types of objects such as Business Objects, 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 connector 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

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 migrate the configuration of the following integrations as packages:

Asset Integrations User and SaaS User Integrations


Asana SaaS Users

Carbon Black



Google Users Group

Google Chrome OS Devices

Google Users

Google Mobile Devices

Okta Active Users


Slack SaaS Users


Zendesk SaaS Users

Jamf Mobile

Zoom SaaS Users







Workspace ONE



blue_link.svg Planning the migration

blue_link.svg Migration objects

blue_link.svg Migrating standalone objects

blue_link.svg Migrating packages





Have more questions? Submit a request


Article is closed for comments.
Powered by Zendesk