Skip to main content

Migration process for Hosted customers with local Bridge or Broker implementations upgrading to Moogsoft Version 9.0

Introduction

This document details the overall high-level process for both sides (Moogsoft Hosted and Moogsoft Onprem) of a deployment migrating to v9.0.x from v8.x.x.

Refer to Migrate Broker or Bridge deployments to v9 from v8.x.x for the actual steps.

Expected Downtime:

  • Event Ingestion: No event loss will occur but a processing delay of up to 4 hours is expected for customers who are ingesting events using local Broker or Bridge servers, or hosted LAMs.

  • UI access: Up to 4 hours of downtime is expected.

Prerequisites

Warning

An experienced Linux RHEL System Administrator is required to actually perform the installation or upgrade. If help is needed, contact Moogsoft Support in order to engage Moogsoft Professional Services

For customers running a local Moogsoft Bridge:

For customers running a local Moogsoft Broker:

  • Provision a new RHEL v8.6 (minimum) server on which the new v9.0.x Moogsoft Broker process will run.

High-Level Migration Process:

Note

This is a high-level process indicating the order things will happen. The detailed process is documented here: Migrate Broker or Bridge deployments to v9 from v8.x.x

  1. Moogsoft creates a "green" v9.0.x environment. This "green" environment has all the cloned configurations and data of the existing v8.x.x environment.

  2. Moogsoft informs customers about the upcoming migration to v9 maintenance window, and requests the following relevant steps to be carried out:

    • Customers running a local Moogsoft Bridge should do the following:

      1. Create a Rabbit Shovel by following step 4 of Migrate a Bridge-based v8.x.x deployment to v9.0.x.

      2. Stop any local v8.x.x bridge processes.

      3. Inform Moogsoft that the Hosted migration may proceed.

    • Customers running a local Moogsoft Broker should do the following:

      1. Stop any running brokers and integration-related Java processes on the v8.x.x server(s).

      2. Inform Moogsoft that the Hosted migration may proceed.

  3. Moogsoft notifies the customer when the maintenance window starts.

  4. Moogsoft performs the full migration of the hosted v8.x.x environment to v9.0.x. Moogsoft then performs various post-upgrade checks (ex. UI availability, core services status, etc.) to verify that the new environment is working.

  5. Moogsoft notifies the customer when the maintenance period has ended and all relevant validations are complete. Moogsoft requests that the Customer perform the final steps to get events flowing into the new v9.0.x hosted environment

    • If there are any unforeseen issues found with the upgrade during the maintenance window, Moogsoft will ask the customer if they would like us to continue troubleshooting, which might result in extending the maintenance window, or perform a rollback of the environment to v8.x.x until the issue can be more thoroughly investigated at a later time.

  6. Customers should then perform these final steps in order to get events flowing into their Moogsoft Hosted v9.0.x environment:

    • For customers running a local Moogsoft Bridge:

      1. Start the v9.0.x local Bridge.

      2. Start v9 LAMs on the local v9.0.x server.

      3. Confirm events are appearing in the Moogsoft Hosted v9.0.x instance.

      4. Switch across all event feeds to point to the v9.0.x Bridge server/LAMs.

      5. Shut down the local v8.x.x server.

    • For customers running a local Moogsoft Broker:

      1. Start the v9.0.x Broker process.

      2. In the Moogsoft Hosted v9.0.x UI, update the Polling integrations to run against the v9.0.x local Broker instead of the v8.x.x local Broker.

      3. Shut down the local v8.x.x server.

Rollback Plan:

If there is an issue with the upgrade that can’t be remediated in the migration maintenance window, Moogsoft will rollback to the old v8.x.x environment after consulting with the customer.

In case of local Broker or Bridge servers, customers would be informed to perform the steps for rollback to get the events buffered in the local v9 server back to the v8 server.

Once everything is back to normal as it was before the upgrade, we would move forward with rescheduling the upgrade to v9.0.x.

In this section: