Planview Hub Cloud Migration FAQ

Standard Hub Cloud Infrastructure

Below is a diagram of the standard Hub Cloud infrastructure:

Prerequisites

Before a cloud migration can begin, customers are required to upgrade their on-prem Hub deployments to a recent release. This is to ensure that no database schema changes need to be performed as a part of the cloud migration process (since, this would greatly impact the amount of downtime and therefore the size maintenance window required to perform the live migration).

In addition to upgrading Hub to a recent version, customers are requested to submit the following information:

• The vendor and version of the source database
• The current size of production database format
• The current format of database backups being used. This is particularly important in the case of Oracle, since there are several ways to back-up an Oracle database. For Oracle users, we require the database backup file to be in DataPump format
• Memory and CPU allocations for both the Hub and Database servers
• Total number of repositories and projects

General Process

The goal of the migration process is: Import the source database into a standard Hub Cloud Postgres database

The process to achieve this goal varies significantly depending on the size and source type of the database. For customers using Postgres with a backup size of 10GB or less, the process is relatively simple, as the database can generally be imported directly into the standard Hub Cloud database without the need for any intermediate steps or additional infrastructure. In this case, all that is required by the customer is to:

• Stop all of their integrations
• Take a backup
• Upload the backup to the Hub Support-Share web utility

When the source database is any of MySQL, Oracle or SQLServer, the process includes some additional steps:

• Some temporary infrastructure is created, which is used to import the backup provided by the customer. For MySQL users, this temporary infrastructure consists of an Amazon RDS instance which matches the version specification of the source database. For SQLServer and Oracle users, in addition to an RDS instance, an ec2 instance is created that contains utilities required to import a backup into the RDS instance. (MySQL RDS instances can be initialized during creation using an s3 bucket object)
• A migration tool (a component of the standard Hub Cloud instance - available only to Hub Engineering personnel) - is run in order to migrate the data from the temporary database containing the source data to the standard Postgres database used by Hub Cloud.

Temporary Migration Infrastructure (in purple)

For MySQL, Oracle and SQLServer users, we create a few temporary infrastructure components in order to ingest the source database backup. How the source database backup is delivered to our Hub Cloud Engineer depends on the size of the backup file:

• If the file is smaller than 2GB, it can be uploaded to Hub’s support-share service.
• If the file is larger than 2GB, it will need to be uploaded by the customer to an s3 bucket using the AWS CLI tools. The AWS Command-Line Interface provides the most-reliable means of delivering large payloads into the cloud

Below is a diagram of the temporary migration infrastructure:

Migration Procedure

This process is performed twice over the course of the migration engagement: Once as a proof-of-concept (PoC) and once for the production migration.

• PoC infrastructure is created
• Production infrastructure is created (both PoC and Production are standard/new Hub Cloud infrastructure situated in the Production environment)
• Temporary migration infrastructure is created (purple); Note: for MySQL users, the migration database creation is deferred until after database backup is placed in Planview’s secure s3 bucket
• Database payload delivery instructions are provided to the customer; this could be either:
  1. Instructions for uploading to Planview’s support-share service
  2. Instructions for uploading to Planview’s secure AWS s3 bucket
• On-prem integrations are stopped; this is to ensure that integrations are not performed concurrently by the on-prem Hub and cloud instances
• On-prem database backup is taken
• For the POC migration, the on-prem integrations are resumed
• Database backup is uploaded to a temporary folder in Hub’s secure s3 bucket; Note: this is either done directly by the customer using AWS credentials provided by Planview, or by the Hub Engineer in cases where the backup was uploaded by the customer to the support-share site
• For MySQL users, the migration database is created here
• For Oracle and SQLServer users, the migration database is initialized from the source database backup using the utility ec2 instance (purple)
• Hub is reconfigured into migration mode; at this point, data is translated from the source database format into the Hub Cloud-native Postgres format and placed into either the PoC or Production database
• Hub is reconfigured to run in normal mode; this step requires that the master password used to encrypt stored credentials the source database be reset, which invalidates all of the repository credentials
• The customer logs into the Hub instance and:
  1. Enters credentials for all of the repositories (to ensure connectivity is good)
  2. Checks that the configuration was correctly migrated
• In the case of the Production migration, all integrations are started
• Health checks and log aggregation are enabled and confirmed to be functioning normally
• The customer and Planview stakeholders agree/sign-off that the migration was indeed successful
• All temporary infrastructure, credentials and backup files are destroyed
• In the case of the Production migration, the migration engagement is concluded
• In the case of the PoC migration, a maintenance window is scheduled and any adjustments to the migration process are documented

Database backup instructions

The backups for each type of database must be created according to the following specifications.