Migrate PPM to SaaS

This section provides instructions on how to migrate PPM from on-premises to SaaS. It's relevant only when you are planning to run PPM in a SaaS environment.

In this topic:

Determine migration prerequisites

Determining the migration prerequisites is the most important step. This step identifies the scope of the migration. For example, the following factors have a significant impact on the scope:

• Current PPM version. Only PPM 9.2x and later versions can be migrated to SaaS.
• PPM implementation at the customer site. Includes customizations and integrations with the on-premises system.
• PPM user base. This determines the hardware sizing in the SaaS environment. A large implementation and user base may require additional time to setup on SaaS.

Determine the following migration prerequisites before the migration:

1. Determine the scope of professional services (PS) engagement.

   The scope and effort of PS engagement required to perform the preparatory and migration activities depend on the on-premises implementation, integration and other requirements such as security and support protocols. The following must be considered:

   Number of custom objects that need additional configuration and verification	This requires capturing all configuration information, customizations, and automation built to support the implementation. Complicated customizations require additional time to understand and validate after the migration to SaaS. It is essential to document these customizations.
   Number and type of integrations that need to be configured after the implementation is migrated to SaaS	This includes the following: PPM-supplied integrations: Document Management, SiteMinder, and LDAP Version 3 compliant systems such as LDAP and Active Directory. Custom integrations: Remedy, Peregrine, Crystal Reports, Business Objects, Data Warehouses, and Custom on-premises systems. Note: Review the custom integrations at an early stage for feasibility and any potential costs associated with maintaining the integrations. Assess the integrations on the on-premises systems to verify if the integrations can be supported.
   Number of instances that need to be enabled and copied during and after the migration	These instances include: Development, Test, and Production in the SaaS environment. Additional instances will take additional costs and effort, such as training, QA instance, and so on.

2. Determine the hardware sizing based on the current and projected licensed user requirements.

3. Provide customers with a list of required firewall configurations that need to be done at their end.

   The following is a list of ports that are opened up INBOUND on the SaaS firewall to allow access to customer's application server. Customers should configure the same ports on their firewall for OUTBOUND traffic, from the specified source IP, IP addresses or range of IP addresses.

   Access	Port
   PPM standard user access	TCP 443 for all instances
   PPM administrator access to the PPM Workbench	TCP 1200, 1201 for production instance Additional ports may be required based on sizing. TCP 1200 for development instance TCP 1200 for test instance
   PPM DEV application server access	TCP 3389. Microsoft Remote Desktop / Terminal Services Client

   Exceptions to these general guidelines can be discussed during the pre-sales phase or during service initialization. Typical exceptions include integrations to customer systems such as Lightweight Directory Access Protocol (LDAP) servers, and CA SiteMinder integrations and other custom integrations defined in the State of Work (SOW) and approved by the SaaS team.

4. Determine training needs.

   If an upgrade is required when migrating from on-premises to SaaS, determine the cost and time necessary for the trainings to administrator users, configuration personnel, and end users.

5. Gather metrics for comparing and measuring performance.

   Capture the performance metrics of essential functionality (such as login and logout) and critical business processes at peak usage to do a comparative analysis so that when PPM goes live on SaaS, similar results can be emulated. Do this in the context of both average user application access and peak user concurrency.

   Note: The SaaS deployment may result in application performance metrics that are different from customer deployment. That's because the customer uses the application across the internet.

Back to top

Schedule migration activities

Migration activities should be scheduled in a project plan. If not, a check list of activities with owners assigned to each activity should be addressed.

The following is an example of the migration project plan.

Activity (*Customer resource required)	Details
*Project kick-off meeting	Have a project kick-off meeting with the following project stakeholders: Customer representatives. PPM project manager or sponsor, designated PPM administrator. SaaS representatives. Customer success SaaS Onboarding team and the SaaS operations PPM Lead or the SaaS project manager. OpenText representatives. Customer sales representative, customer support (CS) representative (if relevant), and assigned PS representative (if relevant).
*Provide trainings to customers	If required, the SaaS team provides customers with trainings that are necessary to complete the migration. The training for the new PPM version should also be included if an upgrade is performed during the migration. You need to provide the training attendee list, training plan and delivery details.
Acquisition of required hardware and software	The SaaS team makes sure that all the required hardware and software are in place.
*Pre-validation activities	Work with Professional services (PS) to determine the pre-validation activities.

Back to top

Perform pre-migration activities

The next step is to perform the following pre-migration activities.

Validation activities

Validation activities include the following:

Activity (*Customer resource required)	Details
*Pre-migration validation activities	PS works with customer to perform the following pre-migration validation activities: Document the configuration, customizations, and implementations and provide this information to the CSM. Prepare required test plans and procedures for post migration testing. Perform infrastructure related configurations, including firewall configuration and VPN setup with in the SaaS environment, if relevant. You should initiate a process with your networking team to set up a site to site VPN. We recommend that you make this a standard process with your networking team because this defines both the process and time required to complete the migration. Your SaaS customer success manager will coordinate activities required for the SaaS team.
Validation checkpoint meeting	The SaaS team initiates the validation checkpoint meeting to: Validate that all software and hardware required for the migration are in place. Verify that requisite firewall and other infrastructure configurations are requested and open for integration (if applicable).

SaaS setup

The SaaS team sets up the following:

1. Install the required hardware and software.
2. Obtain the required PPM license keys.
3. If required, install vanilla PPM versions on all relevant instances.
4. Integrate with customer systems such as LDAP, SiteMinder, or Document Management, if relevant.
5. Configure firewall and other infrastructure configurations that are required for the migration.
6. Perform vanilla software validation tests.

Initial migration run

Initial migration run includes the following activities:

1. *The SaaS team performs an initial migration by importing your production PPM file system and database to the SaaS development instance.

   1. You should work with PS to prepare an initial production file system and database and export the archives on an FTP site for the SaaS team to download.

      • Resources required from your side include DBA, PPM administrators and project manager.

      • You should schedule a downtime of your PROD instance to take a snapshot of the PROD schema (DBA) and to zip the PPM installation directory from one of the application servers.
   2. If your PPM version is below the supported version, the SaaS team will install a vanilla of your PPM version, and then import your PPM archives to this vanilla instance.

   3. *Verify the implementation when the import is completed.

      • Resources required from your side include the PPM administrator, project manager, and testing resources. You should schedule appropriate resources to perform the validation on the instance that is live on SaaS.

      • The validation includes data validation, functional testing of the custom solution configuration, and technical validation of the integrations.
   4. When your verification is done, the SaaS team upgrades your development instance to the currently supported PPM version (if applicable).

   5. *When the new development instance is available, the SaaS team will notify you to perform the verification (if applicable).

      • Resources required from your side include PPM administrator, project manager and testing resources. You should schedule appropriate resources to perform the validation on the instance that is upgraded on SaaS.

      • Validation includes data validation, functional testing of the custom solution configuration, and technical validation of the integrations.
   6. PS team troubleshoots any application upgrade issues by logging tickets with customer service.
2. *Work with PS to perform a thorough validation by testing all configurations, process flows, integrations, and customizations (if applicable).
3. Micro SaaS or PS documents all the issues and resolutions and make necessary adjustments to the migration activity list.

Trial production migration run

Work with PS to prepare a second production file system and database for a trial production migration run. The process of the trial production migration run is the same as that of the initial migration run. For the process details, see Initial migration run.

Back to top

Perform migration activities

The production migration activities are described as follows.

Migration notifications

The following notifications should be sent before and during the migration.

*Notifications sent by customers

Notify PPM users of the downtime before the scheduled migration. When the PPM file system and database archives are available on the FTP site, notify the SaaS team and provide the access information for the file download.

Notifications sent by SaaS team

Notify the customer when the production PPM file system and database archives are obtained from the customer FTP site. Notify professional services when the production migration process starts so that they can stand by to resolve any application installation and upgrade issues. Notify the customer when the monitoring setup starts. If the migration fails, notify the customer to restart the on-premises PPM production instance and reschedule the migration on a future date.

Production migration run

The production migration run includes the following tasks:

1. The SaaS team performs the production migration by importing the latest production PPM file system and database archives into the SaaS setup production infrastructure.
2. *The customer performs required validations by testing the configurations, process flows, integrations, and customizations.
3. The SaaS team copies the DEV and TEST instances from the production instance.

This process is similar to that of the trial migration run. See Trial production migration run for more details.

Back to top

Perform post-migration activities

Send the following notifications after the migration:

Notifications sent by SaaS team	Notify the customer of the availability of PPM services when migration is completed. Notify the customer to restart the on-premises PPM instance if the migration fails.
*Notifications sent by customers	Notify PPM users of the new access information. Provide PPM users with the tier 1 level support information.

Back to top