We are currently running on Pega 26.1.0 and are planning to enable the UseSLAQueueProcessor Dynamic System Setting (DSS) to switch our SLA management from the legacy agent architecture over to modern queue processing.
Currently, we have a significant volume of inflight queue items sitting in the System-Queue-ServiceLevel table, which are being processed by the standard ServiceLevelEvents agent.
Based on our research, our understanding of the migration behavior is as follows:
Phased Coexistence: Once we set UseSLAQueueProcessor to true, all newly created assignments and case SLAs will route directly to the pyProcessSLA queue processor.
Legacy Item Processing: The existing inflight queue items in System-Queue-ServiceLevel will not automatically migrate. Instead, we must keep the legacy ServiceLevelEvents agent running until that database queue table is completely drained.
No OOTB Migration Utility: There is no out-of-the-box (OOTB) setting, script, or tool provided by Pega to bulk-migrate these specific inflight database records into the Kafka-backed queue processor stream (System-Message-QueueProcessor-DelayedItem).
Could someone please confirm if this understanding is correct? Additionally, if anyone has executed this switch recently, are there any hidden gotchas or performance impacts we should watch out for while running both the agent and the queue processor simultaneously?
Your understanding of the migration behavior is accurate.
Setting UseSLAQueueProcessor to true changes the destination for newly created assignments and case SLAs. Future SLA processing bypasses System-Queue-ServiceLevel and routes directly to System-Message-QueueProcessor-DelayedItem managed by the pyProcessSLA queue processor.
Inflight items currently sitting in System-Queue-ServiceLevel will not migrate. You need to keep the legacy Pega-ProCom: ServiceLevelEvents agent active until the System-Queue-ServiceLevel table drains completely.
Pega does not offer an out-of-the-box utility or script to move existing relational database queue rows into the Kafka stream.
Usual Recommendations-
Do not disable ServiceLevelEvents when you flip the DSS. Disabling it will halt processing on all existing inflight SLAs created before the change. Monitor the table until the record count reaches zero, then turn off the agent.
pyProcessSLA uses the Stream service and Kafka back-end to handle delayed items. Ensure your Stream nodes are healthy in Admin Studio and have adequate disk space before toggling the setting.
Verify that pyProcessSLA is mapped to run on BackgroundProcessing node types across your environments.
Monitor the reduction of rows in System-Queue-ServiceLevel via DB query or Report Definition and also monitor PDC for lock contention alerts, which can occur if both processing engines happen to evaluate cases around the same time during the cutover window.