Technical debt remediation approach

[nizar_tliba]

Hi everyone,

Customers often raise concerns about low Health Scan scores that don’t seem to improve, even when remediation activities are carried out during continuous improvement cycles. In many cases, the root cause is simple : new technical debt is being introduced at the same pace, or even faster than existing debt is being remediated.

Why Health Scan Scores Don’t Improve in your opinion ?

Even with structured remediation stories, Health Scan scores will stagnate if development teams continue to introduce technical debt during release cycles. Without governance, the platform becomes a “leaky bucket”—you fix one issue while two new ones appear.

How to Strengthen Release Management and Governance ?

To break this cycle, it’s essential to implement stronger controls within the release process. Practices that I recommend include:

• Mandatory peer reviews to catch issues early.

• Asking SN Support to configure the feature of running a Health Scan per update set and blocking completion if any ACT findings are detected.

• Requiring business justification for any finding that must be accepted rather than remediated.

These steps help ensure that technical debt is not silently reintroduced into the platform.

Now how to manage customizations and avoid unnecessary debt ?

Some business requirements genuinely require customization, and technical debt may be unavoidable. However, before development begins, proposed customizations should be reviewed by a technical governance board. This ensures that:

• An out‑of‑the‑box (OOTB) solution isn’t overlooked.

• The long‑term impact on maintainability and upgrades is understood.

• Customizations are introduced only when truly necessary.

 

How to handle skipped records during upgrades ?

Another common challenge arises during upgrades when skipped records must be addressed. Customers often hesitate to revert to the OOTB version because they fear losing business functionality. In these cases :

• Merging with the OOTB version is usually the best compromise, allowing the instance to stay aligned with the baseline while preserving required functionality.

• If the business feature is no longer relevant, the upgrade becomes an opportunity to fully revert to the OOTB version and eliminate unnecessary customizations.

Please feel free to add any additional thoughts !

Thanks,

Nizar