Skip to main content

Planning for migration

Use the documented information you gathered in Research and analysis for migration to develop:

  • A test plan that can measure whether or not the old and new instances behave as expected

  • A backup and recovery plan

  • A change control plan to minimize downtime of the production system

  • A communications plan to prevent calls to the help desk during the process

Test plan

Write a test plan that systematically identifies use cases covering the required capability of the system. This test plan should cover all automated processing expectations, all end-user self-service cases, all help desk assisting user cases, and so on.

Test the plan on the current production system to ensure it is operating as expected.

Bravura Security Fabric has the potential to interact with nearly every other piece of computing equipment in the enterprise, and as such, the test plan ought to be comprehensive and well maintained.

After an upgrade or migration, systematically test the use cases on the newly upgraded system.

Develop test cases around all the various components of the system that you have implemented; for example:

  • End-user use of the self-service web interface, and help-desk-user use of the web interface to assist others to perform all possible operations, such as:

    • Identification of the profile during login

    • Authentication of the profile using each method

    • Resetting passwords for yourself and others

    • Unlocking accounts for yourself and others

    • Claiming unassociated accounts to your profile

    • Managing tokens, SmartCard, and/or hard disc encryption keys

    • Requesting access to a privileged account

    • Approving a request for access to a privileged account

    • Accessing a privileged account

    • Checking in access to a privileged account

    • Randomizing a password

    • Randomizing a local service

    • Assigning access and membership via user classes

    • Requesting a new account on a target system

    • Requesting attribute changes

  • Phone Password Manager functionality

  • Telephone interface for performing operations

  • Target system integrations

    There should be a test for each operation that is possible on each target system.

  • Ticket / issue tracking system integrations

    There should be a test for each operation that is possible on each ticketing or issue tracking system.

  • Technologies deployed on user workstations, such as:

    • Self Service Anywhere (SSA) / Login Assistant (formally Credential Provider / GINA) interface for domain attached users

    • Other local kiosk solutions for remote and/or local users

    • Lotus Notes ID file delivery mechanism

    • Cached credential controls for external users

  • Technologies deployed on other servers

    • Transparent synchronization triggers

    • Target system agent listeners

    • Bravura Security proxy servers that run connectors for targets

    • Notification service clients that run in user domain logon scripts

    • Reverse proxy servers that allow the web interface to be reached from external networks

  • High availability technologies

    • Load balancers that direct traffic to multiple Bravura Security servers either based on load or simple round robin

  • Redundancy technologies

    • Bravura Security replication servers

    • Third party systems that make periodic backups of the files and registry on the servers

    • Third party systems that make backups of the databases that the Bravura Security servers use

  • Automation and scheduled events

    • Nightly scheduled update

    • Automatically scheduled tasks such as auto discovery and log rotation.

    • Automated report generation and delivery

    • Notification of soon-to-expire and other bulk email events

    • Notifications delivered via plugin points or "exit traps" which trigger when certain conditions are met or actions are performed.

Migrate the instance data (both configuration and user data) from production into test. As you do this, document all the steps. This information will be useful later when you are building the production change control plan.

After the migration, systematically test the cases on the newly migrated test environment. Where a test case has problems, make the necessary changes to the system. Document the changes that were made to make a case work in the new system.

A comprehensive test plan could potentially take a very long time to run. Breaking it down into multiple smaller test plans for different purposes may have benefits; for example, you could use a comprehensive test plan while building a complete working system in the lab, then use a subset of the full plan, that tests only critical use cases, during the implementation of the production change control plan to minimize service disruption.

Production change control plan

Consider the following points to help reduce the production service outage:

  • Since production change control windows are usually small, and are typically scheduled during off-hours, extra attention to detail is required to compensate for the late hours.and disruption of routine. Upgrade plans should should be both explicitly documented and easy to follow. For each step:

    • Describe exactly what to do in clear, plain language, so the person implementing that step does not have to take time to analyze the wording.

    • Include a quick test to verify that this step was completed.

    • Include contingency procedures describing how to troubleshoot failure, back out the change, or redo the change.

    • Describe conditions to help the team decide if the entire migration has reached a critical impasse and must be backed out.

  • If you are performing a version migration, upgrade all software components to the same version.

  • You do not need to stop the old production system until you copy data from it, but it is recommended that you limit or stop access and usage of the old instance during migration.

    Depending on the steps that follow data export, you might want to immediately start it up again to handle certain transactions while the new production system is being finalized. Transactions on the old server, between the time you start it up again until the new system fully takes over, will not be known to the new system; therefore you need to carefully consider what transactions are necessary.

    For example, you might decide that it is more important for password strength checking to be enforced by transparent synchronization triggers than it is for users to have access to the web interface. In this case, the migration plan should indicate stopping all services on the old server (include the web server) before exporting its data, then once the export is complete, only starting the idpm /pushpass service so that transparent synchronization is operational, but the web interface is not.

  • If you are performing a production change control on a Bravura Security product instance that leverages authorization workflow, do not let the old server handle transactions between the time that the data was exported from the old server and the new server comes online.

    If the new server is not aware that the old server handled workflow-based transactions, it may attempt to run those transactions again, which could result in failures, or it might ask authorizers to perform actions that they already performed.

  • If your production change control plan requires that the web interface is not used, then consider solutions other than simply stopping it outright; for example, redirect the web traffic to a static page which explains that the outage was planned, when the site will be available again, and gives advice on what alternatives are available to them. Remember to add a task to the plan to eliminate the redirection when the new server is ready for use.

Communications plan

If the migration you are performing is going to affect the user interface in a dramatic way, or if it is going to alter functionality significantly, consider informing users well in advance of pushing changes into production, so that they do not swamp the help desk with questions once the change is in production.

Due to time format changes from Unix time to ISO date strings, there may be time skews in reports and active access requests.

In this section: