Migrating between instances
This chapter explains migrations between two unrelated instances. The most common case for doing this is synchronizing changes between test and production environments to update or upgrade the production version or to add or change the capability in an existing deployment.
By validating changes on a test environment before pushing changes to production, you can reduce the chances that a change will negatively impact the production environment.
Ideally, the test environment is identical to the production environment in all ways: the same hardware characteristics, the same operating system, the same installed software, and the same networking architecture. If it is not possible to have identical environments, be certain that you are not including test expectations that are unrealistic; for example, load testing on a test environment which uses weak hardware and no replica servers can not be compared to a production environment using powerful hardware and multiple replicas.
Maintaining a test environment requires moving data between the test and production environments. In simple cases, synchronizing environments could require copying files and exporting the registry from one environment to another. In more complex cases where data in databases must be synchronized, the process is complex enough to require some server downtime. The typical process for pushing a change into production might go like this:
Migrate the current production system into a test environment.
Implement the changes in the test environment and then test everything that might be affected.
Migrate the changes into production.
Avoid a situation where the same systems are targeted by two instances, which will split the history and account data. This may lead to password expiry notices being sent from one instance even after, on the other instance, the password was already reset. Account data (like profile attributes) will exist on one instance, not on the other. Passwords on managed systems will be reset by both instances, resulting in race conditions and each instance losing control over the managed systems that the other instance has randomized. One way to work around this is to target a different set of accounts from the test instance; for example, create a test OU on an Active Directory system and target that.
Many migrations can be complicated, involving complex components that require an in-depth knowledge of Bravura Security Fabric . It is highly recommended you contact support@bravurasecurity.com for assistance.