@LionelGuillouroux

Here’s the fix in plain steps. First, confirm you’re on SRS indexing only: in Admin Studio or Search landing page, SRS should be enabled and the legacy FTS agent disabled on all nodes. If SRS is enabled but items still land in System-Queue-FTSIncrementalIndexer, something in your app is still calling the old FTS path. Search your rules for any reference to FTSIncrementalIndexer, pxFTSIncrementalIndexer, or Queue-For-Agent to System-Queue-FTSIncrementalIndexer and remove or update those calls to use pySASIncrementalIndexer or rely on the platform’s out-of-the-box SRS hooks. Check any custom Declare-OnChange, activity post-save logic, or listeners that may queue legacy FTS. Also review data-admin-system-settings (DASS) or prconfig you may have carried over from upgrades; remove any legacy “indexing/FTS” toggles that re-enable FTS. Make sure the FTSIncrementalIndexer agent schedule is disabled in all environments and not re-created by a pipeline step. For the existing million items, do not let them sit. If this is non-prod, truncate the legacy queue table (often pr_sys_queues or the specific FTS queue table) after a snapshot. If this is prod, coordinate with your DBA to purge in batches using Admin Studio → Queues or a controlled SQL delete with where clause on queue type, to avoid long locks. After purge, monitor that the queue stays near zero; if not, you missed a legacy enqueuer. Run a short load test that creates and updates cases and verify only pySASIncrementalIndexer grows. Rebuild the SRS index once to be safe and clear any drift. Lock down deployments so no older rulesets reintroduce the legacy calls. Document the decision: “SRS only, legacy FTS disabled and queues purged.” Finally, add a guardrail check in code review to block any future use of System-Queue-FTSIncrementalIndexer.