For banks running Temenos Transact/T24, an upgrade is often viewed as a release exercise: move to the new environment, validate the platform, complete testing, and go live.
But much of the real complexity sits beneath the release itself.
It sits in the local routines, versions, table extensions, interfaces, and dependencies accumulated over years of business requirements, regulatory changes, integrations, and operational needs.
The problem is not customization itself.
The problem is how that customization is engineered, governed, documented, and maintained over time.
When Customization Becomes Technical Debt
Temenos standard functionality cannot always accommodate every bank-specific product rule, regulatory requirement, or operating model. Carefully designed L3 enhancements can therefore be necessary.
Risk begins to accumulate when these changes are introduced without a consistent engineering and governance framework.
Warning signs often include:
- Ad hoc customizations that create upgrade regressions
- Inefficient routines affecting COB or real-time transactions
- Legacy developments with incomplete documentation
- Hidden dependencies across applications and interfaces
- Changes that do not follow Temenos layer standards
- Critical knowledge concentrated among a small number of developers
- Code that becomes difficult to test and maintain across releases
The environment may continue to support the business, but the underlying complexity grows.
Over time, this creates technical debt that is not always visible during day-to-day operations but becomes highly visible when the bank prepares for its next release.
Why Upgrades Expose Hidden Dependencies
An upgrade changes the technical context in which every local routine, version, interface, and table extension operates.
A customization that worked reliably in one release may behave differently in another. It may introduce a regression, affect data integrity, extend a COB process, or expose an unexpected dependency between applications.
This is why customization governance needs to be considered before the upgrade begins.
The key question for technology leaders is not:
“How much customization do we have?”
It is:
“Can every required customization be identified, impact-assessed, tested, deployed, and supported with full traceability?”
Answering that question starts with visibility.
A complete customization inventory should identify local routines, versions, interfaces, table extensions, COB dependencies, ownership, documentation, and regression coverage.
Without that visibility, upgrade planning becomes an exercise in discovering dependencies as problems occur.
The Cost of Weak Customization Governance
When customization is not governed consistently, banks can fall into a repeating cycle:
Business requirement → local development → undocumented dependency → upgrade impact → expanded testing → production defect → emergency fix → additional technical debt
As this cycle repeats:
- Testing becomes more complex
- Release windows become harder to manage
- Support teams spend more time rediscovering dependencies
- Developers spend more time understanding legacy changes
- Critical system knowledge becomes concentrated within limited resources
Eventually, each new release or business change becomes more difficult than the previous one.
The result is not necessarily a system that fails.
It is a system that becomes increasingly expensive and risky to change.
What an Upgrade-Ready Customization Model Looks Like
A sustainable approach treats every customization as an engineered and traceable change not simply as a piece of local code.
An upgrade-ready model should be built around five core controls:
1. Assess
Map customization impact across applications, versions, tables, interfaces, COB processes, and dependencies.
2. Engineer
Design changes using Temenos-aligned standards and controlled TAFJ/TAFC development practices.
3. Validate
Apply code review, static analysis, SIT, regression testing, and mock COB validation.
4. Deploy
Use controlled, version-aware deployment with OFS-based mechanisms and release documentation.
5. Govern
Maintain ownership, documentation, knowledge capture, and post-deployment monitoring.
This approach changes the role of customization.
Instead of becoming a recurring upgrade liability, it becomes a governed engineering capability.
How Lera Helps Banks Reduce Customization Risk
Lera brings more than 20 years of T24 core engineering experience across 25+ Temenos landscapes.
Our L3 Customization practice is built around a simple principle:
Every change should behave like a Temenos feature not a local patch.
Lera has implemented and maintained 500+ production-grade customizations across multiple T24 releases, supported by TAFJ, TAFC, and Temenos Upgrade Mechanisms expertise.
Our delivery lifecycle combines impact assessment, Temenos-aligned design, performance-focused development, code review, regression and mock COB validation, controlled deployment, and post-release knowledge capture.
The objective is straightforward:
Preserve the business value of required customization without making the core harder to upgrade, support, or scale.
Is your T24 customization landscape ready for the next release?