Inflight SLA Migration Strategy when enabling UseSLAQueueProcessor DSS

General
, ,
1

Hi everyone,

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?

Thanks in advance for your help!