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.
Note: Activities marked with * indicate that customer resources are required. You should make sure that the resources are available for the activity.
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:
-
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.
-
Determine the hardware sizing based on the current and projected licensed user requirements.
-
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.
-
-
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.
-
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.
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:
|
*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. |
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:
|
Validation checkpoint meeting |
The SaaS team initiates the validation checkpoint meeting to:
|
SaaS setup
The SaaS team sets up the following:
- Install the required hardware and software.
- Obtain the required PPM license keys.
- If required, install vanilla PPM versions on all relevant instances.
- Integrate with customer systems such as LDAP, SiteMinder, or Document Management, if relevant.
- Configure firewall and other infrastructure configurations that are required for the migration.
- Perform vanilla software validation tests.
Initial migration run includes the following activities:
-
*The SaaS team performs an initial migration by importing your production PPM file system and database to the SaaS development instance.
-
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.
-
- 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.
-
*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.
-
- When your verification is done, the SaaS team upgrades your development instance to the currently supported PPM version (if applicable).
-
*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.
-
- PS team troubleshoots any application upgrade issues by logging tickets with customer service.
-
- *Work with PS to perform a thorough validation by testing all configurations, process flows, integrations, and customizations (if applicable).
- 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.
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 |
|
Notifications sent by SaaS team |
|
Production migration run
The production migration run includes the following tasks:
- The SaaS team performs the production migration by importing the latest production PPM file system and database archives into the SaaS setup production infrastructure.
- *The customer performs required validations by testing the configurations, process flows, integrations, and customizations.
- 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.
Perform post-migration activities
Send the following notifications after the migration:
Notifications sent by SaaS team |
|
*Notifications sent by customers |
|