Skip to main content
LinkedIn
Copied!

Assessing your infrastructure

+

This content applies to On-Premises Services and Cloud environments.

A Pega application installation requires a database, but also requires other infrastructure – operating system, web server software, Java software, and so on.  As part of your migration project, you must complete a comprehensive review of your non-database infrastructure.

Preparing to migrate to a Pega Cloud infrastructure

Before migrating, you must thoroughly review your on-premises infrastructure setup, to assess where you will need to make changes. Gather comprehensive details about your non-database infrastructure to determine:

  • Whether changes are necessary to your application, so it does not rely on an infrastructure component that isn’t supported in a Pega Cloud® Services environment
  • The sizing requirements that Pega Cloud Services requires to provision an environment infrastructure for your application that meets your computing needs

Gathering infrastructure information

To assist in this process, Pega provides the Client Cloud Migration Gap Assessment Worksheet, which lists all the information to be gathered, and highlights out-of-date functionality.  For your infrastructure, please complete the Infrastructure Analysis and the Other Requirements sheets.  Note that the Infrastructure Analysis worksheet also contains suggested remediations.

Details that must be gathered include:

  • the sizing of your current environment
  • whether SFTP is available for use by your Pega application
  • the JRE version
  • configuration settings information 

It is important to identify any custom functionality which is not supported in Pega Cloud Services environments.  (See Pega Cloud Services and Legacy Functionality in the Migration Overview article.)  For instance, operating-system-level or database-system-level structures must be identified and replaced with equivalent Pega functionality which is secure and guardrail-compliant for your migration to Pega Cloud Services.

Determining foundational infrastructure and connectivity

When planning your migration to a Pega Cloud Services environment, start by determining your environment requirements, by answering these questions: 

  • How large an environment do you need?  Do you just need a development environment, a staging environment, and a production environment, or do you need additional environments for other purposes (QA, UAT, etc.)?
  • How much database storage will you need?
  • How much files storage will you need?

Your Pega representative can help you determine the answers to these questions.

Connectivity

One of the vital parts of your new Pega Cloud environment is its connectivity.  You need to determine your required Pega Cloud environment connectivity and the type of security the connections use.

For most clients, a VPN will provide appropriate security; Pega Cloud provides VPN connections to securely connect your existing network to your PCS environment through an IPSec VPN connection.  For details, see the Pega Cloud VPN service article.

For a VPN alternative, Pega Cloud Services supports the Amazon Web Services (AWS) Direct Connect service between your PCS virtual private cloud (VPC) and your physical infrastructure.  For details, see Configuring Amazon Web Services (AWS) Direct Connect in your Pega Cloud Services virtual private cloud.

Pega also supports using a virtual private cloud (VPC) peering connection to access your systems of record or transfer data between your Pega Cloud Services VPC and your Amazon VPC.  VPC peering is a virtual connection within the AWS architecture that enables one-to-one networking connections between VPCs within the same region.  For details, see Requesting a virtual private cloud (VPC) peering connection.

Legacy infrastructure options only available for on-premises deployments

Certain infrastructure implementations have dependencies on specific deployment options and technology choices that work well with an on-premise data center, but are not supported in a cloud operational model. To identify an unsupported legacy infrastructure in your current deployment, review the criteria that drive compatibility with the Pega Cloud Services deployment model:

  1. No dependencies on third-party software that may alter the behavior of the Pega Platform runtime environment.  (Example:  Custom libraries added to the application server configuration file, like tomcat/lib.)
  2. No required customizations of container-level configuration - Pega requires that your application support the Pega Cloud Services auto-scaling of server nodes model.
  3. No database customizations that require unsecured manual changes to the data or database structures.   All database changes must be made through the Pega application.
  4. No use of non-standard ports or dynamic IP addresses that would necessitate the use of a private network connection.
  5. No reliance on a local file system for temporary or permanent file storage.  Since the Pega Cloud file system is transient, your Pega application could experience data loss if it requires access to a local file system.
  6. No reliance on a specific node (identified by a specific Host ID or IP address).  The Pega Cloud model uses transient nodes that can be automatically replaced for performance or other health or maintenance reasons.

If your infrastructure implementation violates any of the principles above, address the dependency configuration issue so that your system is compatible withPega Cloud Services environment.

Configuration settings in files on the server

In on-premises installations, there are a number of files containing configuration settings which reside on the server but are not supported for client use in Pega Cloud environments:

  • Prconfig.xml
  • Context.xml
  • Server.xml
  • Web.xml

As a best practice, you can prepare for a migration by reviewing your system configuration settings.  Any settings that you are currently managing in the unsupported, on-premises only files listed above should be replaced by Dynamic System Settings in your Pega application. For example, you can use a Dynamic System Setting to configure which fields are available in full-text search.  When Dynamic System Settings are set through the Dev Studio, they are stored in the Pega Platform database and are used by all nodes that share that database.

Other custom files on the server

Some clients may use custom folders in their webapps directory, or in their prweb directory.  Just like configuration settings files, custom folders that were not created from the Pega application are not supported in a Pega Cloud environment.  

Custom logging

Depending upon your Pega Platform version, there may be a different file containing the logging settings, none of which are supported in Pega Cloud environments:

  • Prlogging.xml
  • Log4j.xml
  • Log4j2.xml

To provide the parallel functionality, Pega Cloud Services allows you to download a log file bundle from My Pega Cloud for internal analysis or to share with Pega Global Customer Support (GCS).  You can also access server logs by using Kibana.

Suggest Edit
Did you find this content helpful?

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Ready to crush complexity?

Experience the benefits of Pega Community when you log in.

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us