Question
LK
Last activity: 20 Jan 2026 11:13 EST
Pega 24 Upgrade on Kubernetes – Clarification on Base vs Skimmed Schemas and Batch Health Issues
Hi Pega Support Team,
We have already migrated our on-prem Pega 8 environment to Kubernetes, and we are currently in the process of upgrading this environment to Pega Platform 24.x. We need your guidance regarding schema usage and upgrade behavior.
In our original Pega 8 production environment, the application was running successfully using only skimmed schemas:
-
customer_skimmed
-
pegadata_skimmed
-
pegarules_skimmed
All database system settings were mapped to these skimmed schemas via JNDI, and the application functioned without issues. The base schemas (pega_rules, pega_data, customer) were not actively used.
During the Pega 24 upgrade on Kubernetes, we are observing the following behavior:
-
When the deployment is configured to use skimmed schemas directly, the batch pod becomes unhealthy, with errors such as “Enterprise tier failed to initialize properly, PegaRULES not available.”
-
When the deployment is configured to use base schemas and the upgrade is executed, both web and batch pods become healthy; however, existing operator credentials from the Pega 8 environment cannot be used to log in, which suggests a schema or data alignment issue.
We would appreciate clarification on the following:
Hi Pega Support Team,
We have already migrated our on-prem Pega 8 environment to Kubernetes, and we are currently in the process of upgrading this environment to Pega Platform 24.x. We need your guidance regarding schema usage and upgrade behavior.
In our original Pega 8 production environment, the application was running successfully using only skimmed schemas:
-
customer_skimmed
-
pegadata_skimmed
-
pegarules_skimmed
All database system settings were mapped to these skimmed schemas via JNDI, and the application functioned without issues. The base schemas (pega_rules, pega_data, customer) were not actively used.
During the Pega 24 upgrade on Kubernetes, we are observing the following behavior:
-
When the deployment is configured to use skimmed schemas directly, the batch pod becomes unhealthy, with errors such as “Enterprise tier failed to initialize properly, PegaRULES not available.”
-
When the deployment is configured to use base schemas and the upgrade is executed, both web and batch pods become healthy; however, existing operator credentials from the Pega 8 environment cannot be used to log in, which suggests a schema or data alignment issue.
We would appreciate clarification on the following:
-
Does Pega 24 require base schemas to be present and upgraded first, even if the source Pega 8 environment was operating entirely on skimmed schemas?
-
What is the supported and recommended upgrade/migration approach for a Pega 8 environment (already migrated to Kubernetes) that uses only skimmed schemas, to ensure both batch pod health and correct access to existing operator data?
-
Are there any mandatory post-upgrade steps or schema-mapping actions in Pega 24 to properly align skimmed schemas with base schemas?
Additionally, if there is any official Pega documentation, upgrade guide, or reference material that specifically covers upgrading environments using skimmed schemas (especially for Kubernetes deployments), please share it with us.
Your guidance on the supported architecture and best-practice upgrade path for this scenario will help us proceed correctly.
Best regards,
Buddhika Perera