Skip to main content

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.