Hi Experts,
Looking for guidance from the Blueprint community on addressing key risks identified in a client’s existing Pega application before accepting further development or starting new sprints.
Key challenges observed:
Heavy use of long lived branches in QA/Prod (200+ rules per branch), complex Activities (60+ steps), and instability when branches are removed.
High technical debt: Guardrail score ~71% in Prod with ~10K warnings; extensive use of deprecated rules.
QA and Prod branch/rule misalignment leading to deployment and testing risks.
Upgrade constraints: Pega v8.8 with UIkit v7.7
Ask:
From a Blueprint best practice standpoint:
Should stabilization/remediation be mandated before new development?
How would you sequence branch rationalization, guardrail cleanup, UI modernization, and platform upgrade?
Any proven patterns, artefacts, or assessment approaches to position these risks with business stakeholders?
Hello
Based on what you’ve described, the risks you’re seeing are structural, not incidental. Irrespective of Blueprint usage, the current state of the application is already outside Pega and Blueprint best‑practice guardrails, and continuing feature delivery without remediation will almost certainly compound cost, instability, and delivery risk.
Below is how I would respond from a Blueprint / modern Pega delivery standpoint.
Should stabilisation be mandated before new development?
Yes. This should be a firm prerequisite.
The current state (long‑lived branches in QA/Prod, low guardrail health, deprecated rules, and environment drift) represents systemic risk. These conditions are incompatible with:
Predictable sprint delivery
Safe deployments
Cost‑effective upgrades
Blueprint‑driven execution
Recommendation to sponsors:
Limited stabilisation must precede or explicitly gate new development. Every sprint delivered today without fixing these fundamentals increases future cost and risk.
Recommended sequencing (from my experience, as sequence matters )
This is the foundation. Nothing else is safe or sustainable without it.
2. Guardrail & Deprecated Rule Remediation
Address high‑severity guardrails first
Remove deprecated rules and refactor large Activities
Improve guardrail trajectory, not just the headline %
This directly reduces upgrade cost and production risk.
3. UI Modernisation
Incremental modernisation away from UI‑Kit dependency
Remove deprecated UI patterns
Prepare for Constellation‑aligned approaches
Doing this earlier causes rework; doing it later accelerates upgrades.
4. Platform Upgrade
Upgrade only once technical debt and branch discipline are under control
Significantly lower regression and testing effort
Faster post‑upgrade feature velocity
Bottom line
Blueprint accelerates delivery only when the execution layer is healthy.
In the current state, further delivery without stabilisation is a conscious risk decision — and an expensive one.