Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Review Legacy Infrastructure Options and Implementations

Updated on December 12, 2023


This content applies to On-premises, Client-managed cloud and Pega Cloud environments

Attention: This documentation has been moved to the new documentation site:
This documentation is no longer being maintained. It is out of date and pending deletion. Please update your bookmarks.

Several legacy options, features, and implementations are, or were, supported in on-premises or client-managed cloud, but may not be supported on Pega Cloud.  Review these unsupported and deprecated features and options.  Identify any required changes needed to comply with Pega Cloud infrastructure policies and include them in your Migration Project Plan.    

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 on Pega Cloud. To identify unsupported legacy infrastructure in your current deployment, review the criteria that drive compatibility with the Pega Cloud:

  1. No dependencies on third-party software that may alter the behavior of the Pega Platform runtime environment.  (For example:  Custom libraries added to the application server configuration file, such as tomcat/lib.)
  2. No required customizations of container-level configuration.  Pega requires that your application support the Pega Cloud auto-scaling of server nodes.
  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 require using a private network connection.
  5. No reliance on a local file system for temporary or permanent file storage.  The Pega Cloud file system is transient, so 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).  Pega Cloud 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 issue so that your system is compatible with Pega Cloud.  Add the items to the Migration Project Plan.

Configuration settings in files on the server

In on-premises installations, there are several files containing configuration settings that reside on the server, but are not supported on Pega Cloud:

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

Review your system configuration settings.  Any settings that you currently manage in the unsupported, on-premises-only files listed above must 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.  Unlike settings in configuration files, Dynamic System Settings are set through 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

Hosting custom folders or files in the webapps or prweb directories is not supported on Pega Cloud.   These files must be hosted elsewhere, either outside of Pega Cloud, or on the Pega Cloud File Storage.

Custom logging

Depending on your Pega Platform version, one or more of the following files may have been used to configure custom logging settings for the Pega Platform.

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

Custom logging settings are configured through the Pega Platform on Pega Cloud. For more information, see:

Identify Custom System Objects and OS Level Dependencies

Determine whether there are custom system objects that will not function properly on Pega Cloud.  The Pega Cloud file system is transient, and may cause data loss if relied upon.  Therefore, any Pega application functionality that writes files or other information to disk must be updated to modern strategies that support standard cloud operations.

When migrating to Pega Cloud, operating-system-level or database-system-level structures must be identified and replaced with equivalent Pega functionality which is secure and guardrail-compliant.

Security dictates that there is no command-line access on Pega Cloud.  Therefore, update these types of customizations to use Pega application functionality instead:

  • Custom shell scripts
  • Cron jobs
  • Custom schedulers
  • Custom scripts to move files
  • Configuration file customizations

Identify any custom functionality that is not supported on Pega Cloud.  Identify the appropriate remediation.  Add that to the Migration Project Plan.  



Have a question? Get answers now.

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

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us