Migration use cases

Deployment migrations involve creating new instances with the same version and initial configuration as existing instances. This is typically done in the context of maintaining development, test and production Bravura Security Fabric servers. This is a recommended best practice.

The production server provides reliable services to users while new configurations are developed and tested.

The test server is a replica of the production server. The test server allows configuration changes to be tested without interrupting or affecting the operation of the production server. Once testing is completed, the tested configuration parameter changes need to be migrated to the production server.

The development server provides a facility to experiment with new features, targets, versions, and so on, without affecting the test or production servers. Migration from development to test is performed when the configuration changes have passed initial testing on the development server.

If you currently do not have a development or testing version of your production instance, it is highly recommended that you set up one prior to starting any migration.

Configuration migrations involve synchronizing configuration parameters between existing instances of the same version.

For example; when you want to have a development version to test user interface changes without affecting the main instance. After testing, you migrate those changes to production.

In some cases, more than one instance may be required on the primary server. When multiple instances are maintained, there are often configuration parameters that are common to all instances. When a configuration change to all instances is required, it is necessary to migrate the configuration parameter change from one instance to all other instances.

In cases where a Bravura Security Fabric instance is moved to a different network, all nodes will have new IP addresses. 

Given the following assumptions, provided the DNS is up-to-date, it is okay to update the IP address without any configuration changes within itself:

If there are Connector proxies set up with IP addresses that are affected by the network change, you may need to update those manually.  You can use instdump output to check for any IP address configurations.

Database migrations are needed if the backend database server is upgraded or moved, or when the database is restored from backup after disaster recovery.

The majority of configuration parameters are stored in the database, and upgrades require consideration of differences in tables, schema, and data encoding.

There may be situations where the upgrade involves a migration of data from old servers to new servers at the same time as the upgrade. A migration with upgrade is recommended where:

A migration with upgrade ensures the current production version of Bravura Security Fabric remains available as long as possible during the change of versions.

When performing a migration with upgrade, you must install a second instance that will become the new version. Then you can manually copy or migrate configuration files and data from the databases to this new version instance.

It is possible to perform a migration with upgrade on a single server. The only limitations are that the second instance – the new version – must have a unique instance name and all the port numbers of the services for the second instance must be changed from their default values. Thus, you will need to modify any configuration parameters that contain the instance name or port numbers. This includes both the Bravura Security Fabric server, targets with local agents, or transparent password synchronization triggers, and clients with Bravura Security Fabric components. It is recommended that you use two servers to perform all manual migrations to avoid these complications.

Migrations with upgrade, including those that are migrating to a new instance at the same time, involve many complex components that require an in-depth knowledge of Bravura Security Fabric . It is highly recommended you contact support@bravurasecurity.com for assistance.

Before migrating any data, ensure you have taken the following into consideration:

A clean install can avoid the problems of unwanted or obsolete data being transferred from the old instance, and prevent any unexpected results in the conversion process. Obvious configuration items like target systems, templates, roles, and so on are easily observable and can be duplicated in the new instance. Implementing a new version without carrying forward the old version’s configuration provides a good opportunity to leverage new features and re-engineer components in a better way.

If the old instance contains unique data such as profile attributes that cannot be constructed from target system lists, security question data from user registrations, password reset history, or product usage statistics in the session log, then that can strengthen the argument for mass migration of the old instance. However, pinpoint migration of only the unique data is possible and should also be considered.