Execute the RPI v7.x upgrade

Overview

This page walks you through the process of upgrading RPI from v6 to v7, and assumes you’ve reviewed the content on the previous pages of this section:

• Upgrade to RPI v7.x: Provides benefits and other high-level information about the upgrade

• Plan your RPI v7.x upgrade: Helps you to plan for the upgrade detailed on this page

Step 1: Back up your v6 environment

Take comprehensive backups of your current v6 environment, including databases, configuration files, and application data. While we are not familiar with your specific set up and cannot mandate how you back up your RPI v6.x environment, we strongly recommend creating backups of the following RPI components:

RPI Node(s):

• Snapshots of the RPI VM(s)

Or

• Back up the following folders, assuming you use the default locations:

  • C:\Program Files\RedPoint Global

  • C:\inetpub\wwwrpi

Operational Databases:

• Pulse

• Pulse_Logging

• Interaction_xxx

• InteractionAudit_xxx

• RPIRealtime (if used)

Once you’ve ensured that you meet the prerequisites and backed up your v6 environment, follow the steps outlined below, first for your non-production (staging) environment, and then for your production environment.

Step 2: Upgrade your non-production (staging) environment

Step 2a: Perform initial testing in non-production environment

1. Deploy v7 in staging: Follow the steps outlined in the GitHub readme to deploy v7 in your staging environment.

The key differences between the upgrade installation and a new (greenfield) installation are:

• SQL server configuration: Ensure your SQL server configuration, caches, and queue provider settings all point to your current RPI v6 environment.

• Helm chart customization: Modify the Helm Chart to incorporate the details provided in the Upgrade Assistant output. Update the values.yaml file with the relevant environment variables and configuration settings from the output to ensure compatibility with v7.

2. Validate: Perform thorough testing to validate the upgrade. Check all integrations, customizations, and functionalities.

3. Performance test: Conduct performance testing to ensure the new version meets your performance requirements.

Step 2b: Address Issues

1. Identify issues: Document and remediate any issues encountered during the staging upgrade for following production environment upgrade.

2. Solve issues: Develop solutions for any issues. This may involve tweaking configurations, updating integrations, or contacting Redpoint Service Desk for clarification. If you need further assistance, please reach out to our Client Services team, your Customer Success Director, or Technical Account Manager (if assigned).

Step 2c: Make final preparations for upgrading production

1. Update scripts and automations: Update your deployment scripts and automations to support v7 in a production environment.

2. Communicate to users: Inform users about the upgrade schedule and any expected downtime or changes in functionality.

Step 3: Upgrade your production environment

Step 3a: Schedule downtime

1. Plan downtime: Determine how much downtime you’ll need and when to schedule the downtime so that it will have the least impact on your users.

   1. As a default, you can plan for a four hour maintenance window. Although the upgrade can take less time, variance in your infrastructure, personnel, approach, etc. could impact the amount of time it takes.

   2. Another approach could be to prescribe a project management scoping effort prior to undertaking the migration. The necessary maintenance window would be established as an output of that scoping effort.

   3. Schedule the upgrade during a low-traffic period to minimize impact on users.

2. Notify users: Notify users in advance about the planned downtime.

Step 3b: Execute upgrade

1. Step-by-step upgrade: Proceed with the upgrade, following the upgrade steps precisely as done during the non-production upgrade. Deploy RPI v7, following the steps outlined in the GitHub readme to deploy v7 in your staging environment, and remediate documented issues which occurred during the staging upgrade.

The key differences between the upgrade installation and a new (greenfield) installation are:

• SQL server configuration: Ensure your SQL server configuration, caches, and queue provider settings all point to your current RPI v6 environment.

• Helm chart customization: Modify the Helm Chart to incorporate the details provided in the Upgrade Assistant output. Update the values.yaml file with the relevant environment variables and configuration settings from the output to ensure compatibility with v7.

Alternative: Mirror/duplicate staging environment and promote to production.

2. Monitor: Monitor the upgrade process closely to catch any issues immediately.

Step 3c: Perform post-upgrade validation

1. Comprehensive testing: Perform comprehensive testing to ensure the upgrade was successful.

2. User acceptance testing (UAT): Allow a select group of users to perform UAT to identify any user-facing issue.

Have a contingency plan in place to roll back to the existing RPI v6 environment if you encounter issues. If required, restore from the backups taken before the upgrade.

Wrapping up

1. Monitoring and support

   1. Ongoing monitoring: Monitor the system closely for the first few days after the upgrade to catch any lingering issues.

   2. User support: Provide support to users to help them adapt to the new version and address any issues they encounter.

2. Feedback and iteration: Gather feedback from users and stakeholders about the upgrade process and the new version, and resolve and/or communicate issues as appropriate.