Author: Calimere Point – calimerepoint.com
As the 2027 SAP support deadline approaches, the UK investment and fintech sector faces unique challenges in preserving decades of mission-critical custom code
The financial services industry stands at a critical technology crossroads. With SAP’s 2027 end-of-support deadline for legacy systems rapidly approaching, UK financial institutions and investment firms are accelerating their migration to SAP S/4HANA. But beneath this technical transition lies a more fundamental business challenge: how to preserve and modernize decades of custom business logic that forms the backbone of these organizations’ competitive advantage.
Our recent collaboration with the UK’s largest building society revealed both the scope of this challenge and a pathway forward that maintains operational integrity while embracing cloud transformation. When their critical customer data deduplication process—built on COBOL forward congruency logic dating back generations—met modern cloud architecture requirements, the technical complexities demanded innovative solutions that balanced legacy stability with future flexibility.
For investment professionals and fintech leaders weighing their SAP migration strategy, this case study offers valuable insights into preserving business-critical functionality while embracing technological evolution.
The stakes were exceptionally high. Any failure in this code during migration would result in serious consequences: corrupted customer data, transaction failures, and potentially significant financial and reputational damage.
Systematic Code Analysis and Translation
Our approach began with a comprehensive analysis of the legacy system. With COBOL developers becoming increasingly scarce in the industry, we assembled a specialised team to methodically deconstruct the existing code structure.
The analysis required meticulous attention to detail as we examined each component to understand both its function and purpose within the larger system. Much of the logic originated in the 1980s, characterised by minimal documentation and domain-specific nomenclature. We encountered numerous instances of specialised business rules with limited explanation, such as region-specific processing requirements added decades ago.
The technical challenge extended beyond simple code translation. We needed to bridge fundamentally different programming paradigms: COBOL—a procedural language designed for sequential batch processing on mainframes—and PySpark, a distributed processing framework engineered for parallel cloud-scale data operations.
Architectural Transformation
As the project developed, it became evident that this initiative extended beyond straightforward code translation. We were undertaking a fundamental architectural transformation to achieve identical business outcomes in a substantially different computing environment.
The technical differences were significant: COBOL processes records sequentially in a linear fashion, while PySpark distributes data processing across numerous parallel processors. This required completely rethinking the execution flow while preserving the exact business logic.
Our testing methodology addressed this complexity through comprehensive validation. We developed a testing framework that generated over 10,000 distinct test scenarios covering every possible combination of input variables. Each scenario was processed through both the original COBOL and our new PySpark implementation, with outputs systematically compared using automated validation tools to verify complete functional equivalence.
Performance Optimisation Beyond Functional Equivalence
A significant challenge emerged after achieving logical equivalence. While our implementation made identical decisions to the original code, initial performance metrics were suboptimal. The distributed nature of PySpark revealed that operations efficient in sequential COBOL created processing bottlenecks in a parallel computing environment.
This necessitated a sophisticated optimisation approach: maintaining absolute functional equivalence while restructuring data flow operations to leverage distributed computing capabilities. The solution required precise preservation of decision logic while completely redesigning the underlying data processing architecture.
The final implementation delivered exceptional results: 100% functional equivalence with the legacy system while processing data approximately 15 times faster than the original COBOL code, providing both business continuity and significant performance improvements.
Lessons for the SAP Migration Wave
1. Business logic preservation requires expertise in both old and new paradigms.
The most dangerous migrations are those where the team understands the destination technology but not the origin.
2. Testing must be exhaustive, not representative. When migrating critical business logic, testing a few scenarios isn’t enough—you need to validate every possible path through the code.
3. Performance can’t be an afterthought.
The architecture of modern distributed systems fundamentally differs from legacy mainframes, requiring careful consideration of how logic flows through the system.
4. Documentation is your future-proofing strategy.
We created comprehensive documentation mapping the old logic to new implementations, ensuring the client wouldn’t face the same archaeology expedition during their next migration.
Beyond Forward: The Future of Master Data Management
While this project focused specifically on forward congruency (how incoming data integrates with existing records), it opened conversations about the broader data ecosystem. Our client is now engaging us for reverse congruency implementation—ensuring data flowing out from the master database to downstream systems maintains consistency.
The larger trend is clear: as organisations modernise their core systems, they’re simultaneously raising their ambitions for what their data can do. Legacy modernisation isn’t just about maintaining existing capabilities—it’s about establishing the foundation for future innovation.
This article is based on our recent work with the world’s largest building society. For a more detailed case study of this SAP S4 HANA migration project, including our methodology and outcomes, download our comprehensive Use Case.
