Case StudiesBlog
Talk to an Expert
Banking & Fintech

Core Banking Modernization with Zero Downtime

A mid-size European bank with 2M+ customers needed to escape its legacy COBOL core banking system. Strict PSD2 compliance deadlines and a 24/7 uptime mandate meant failure was not an option.

70%

Lead Time Reduction

99.99%

Uptime During Migration

14

Months Duration

Industry

Banking & Fintech

Model

Dedicated Team

Duration

14 months

Team

6 engineers

Key Result

70% faster deploys

Client Context

The Client Situation

The client is a mid-size European retail bank serving over two million customers across multiple countries. Their core banking platform, built on COBOL mainframe systems in the early 2000s, had reached a critical inflection point. New product launches took 6-9 months, integrations with fintech partners required expensive middleware layers, and the internal engineering team lacked cloud-native and microservices expertise.

The European Central Bank's PSD2 compliance deadline was approaching, requiring open banking APIs, strong customer authentication (SCA), and real-time transaction monitoring. The bank's legacy architecture could not support these capabilities without significant rework. Simultaneously, PCI-DSS recertification was underway, adding another layer of audit and security requirements to any changes made to the core platform.

The CTO's mandate was clear: modernize the core banking system to a microservices architecture while maintaining 24/7 service availability. No planned downtime windows were acceptable — every migration step had to be executed with zero customer impact. The internal team of 12 engineers needed external reinforcement with deep experience in distributed systems, event sourcing, and regulated financial environments.

A failed modernization attempt 18 months prior with a different vendor had eroded executive confidence. Stakeholders required detailed risk mitigation plans, weekly progress visibility, and a governance framework that would keep the board informed without micromanaging the technical team.

Scope & Approach

What Envadel Was Engaged to Do

Envadel was brought in to design and execute a phased migration from the monolithic COBOL core to a domain-driven microservices architecture running on Kubernetes. The engagement followed the Dedicated Team model: a self-managing squad of 6 engineers operating under Envadel's governance framework, integrated with the client's existing Jira and Confluence environment.

The approach was strangler fig pattern — progressively replacing legacy modules with new microservices behind an API gateway, using Kafka event streaming to maintain data consistency between old and new systems during the transition period. Each module (accounts, payments, lending, compliance) was migrated independently with canary deployments and automated rollback capabilities.

The 14-month roadmap was divided into three phases: Foundation (months 1-4) covering infrastructure, CI/CD, and the first two microservices; Core Migration (months 5-10) for the critical banking modules; and Optimization (months 11-14) for performance tuning, PSD2 API certification, and knowledge transfer to the client's expanded internal team.

Team Composition

Team Structure

The dedicated squad consisted of 6 Envadel engineers working full-time alongside the client's existing 12-person engineering team. Clear ownership boundaries were defined: Envadel owned the new microservices layer and migration execution, while the client's team maintained the legacy system and business logic validation.

Tech Lead / Architect (1) — 12+ yrs, distributed systems

Sr. Backend Engineer (2) — Java/Spring Boot, event sourcing

DevOps / Platform Engineer (1) — K8s, Terraform, AWS

QA Automation Engineer (1) — Contract testing, performance

Sr. Backend Engineer (1) — Kafka, data migration

Delivery Manager (shared) — Governance, reporting

Architecture & Technology

Architecture & Technical Decisions

The new architecture was built on Java 17 with Spring Boot 3, following domain-driven design (DDD) principles. Each bounded context (Accounts, Payments, Lending, Compliance, Customer) was implemented as an independent microservice with its own PostgreSQL database, enforcing the database-per-service pattern to eliminate cross-service data coupling.

Apache Kafka served as the event backbone, implementing event sourcing for all state changes in the Accounts and Payments domains. This enabled real-time data synchronization between the legacy COBOL system and new microservices during the transition period, and provided a complete audit trail required for PCI-DSS compliance. Kafka Connect managed CDC (Change Data Capture) from the legacy DB2 database.

Infrastructure was fully codified with Terraform on AWS. The Kubernetes cluster ran on EKS with Helm charts for standardized deployments. The CI/CD pipeline (GitHub Actions) included SAST scanning (SonarQube), container vulnerability scanning (Trivy), automated contract tests (Pact), and canary deployment orchestration. Every microservice deployment was staged: 5% canary → 25% → 50% → 100%, with automated rollback triggered by error rate thresholds.

An API gateway (Kong) handled routing, rate limiting, and authentication (OAuth 2.0 / OpenID Connect) for both internal services and the PSD2-mandated open banking APIs. Observability was built on Prometheus, Grafana, and distributed tracing via Jaeger, with PagerDuty integration for on-call alerting.

JavaSpring BootPostgreSQLApache KafkaKubernetesTerraformAWSDockerHelmPrometheusGrafanaSonarQube

Security & Compliance

Regulatory Compliance & Security Measures

Given the regulated financial environment, security was embedded at every layer. All engineers accessed the client's infrastructure through a dedicated VPN with hardware MFA tokens. Code repositories used branch protection rules, mandatory code review by at least two reviewers (one from each team), and signed commits. No engineer had production database access — all data interactions went through versioned APIs with comprehensive audit logging.

PSD2 compliance was validated through the implementation of Strong Customer Authentication (SCA) flows, transaction risk analysis APIs, and the open banking interface certified against the Berlin Group NextGenPSD2 specification. PCI-DSS controls were maintained throughout: network segmentation, encryption at rest (AES-256) and in transit (TLS 1.3), secrets management via AWS Secrets Manager with automatic rotation, and quarterly vulnerability assessments.

Envadel's team participated in two external penetration tests during the engagement, addressing all findings within the agreed SLA. A mutual NDA and DPA were executed before engagement start, with data residency within the EU guaranteed. All Envadel engineers completed the client's mandatory security awareness training and passed background checks.

Delivery Process

Sprint Cadence & Governance

The team operated in 2-week sprints with a well-defined ceremony cadence: sprint planning on Mondays, daily standups at 09:30 CET, mid-sprint review on Wednesdays, sprint review and retrospective on alternate Fridays. The client's Product Owner participated in all planning and review sessions, ensuring alignment with business priorities.

Reporting followed a structured cadence: weekly status reports delivered every Friday covering velocity, blockers, risk assessment, and upcoming milestones. Monthly executive summaries were presented to the CTO and VP Engineering, including burn-down charts, quality metrics (defect escape rate, test coverage), and a RAG-status roadmap view. Quarterly Business Reviews (QBRs) with C-level stakeholders covered strategic alignment, ROI tracking, and team continuity planning.

Formal change management was enforced for any scope modification. Change requests required impact assessment (effort, risk, dependencies), approval from both Envadel's delivery manager and the client's Product Owner, and documented scope adjustments. This process prevented scope creep while allowing legitimate pivots — 4 change requests were processed over 14 months, all within the governance framework.

Results & Impact

Measurable Outcomes

70%

Reduction in deployment lead time (from 6 weeks to 1.3 weeks)

99.99%

Uptime maintained throughout the 14-month migration

PSD2

Full PSD2 compliance achieved ahead of regulatory deadline

45%

Reduction in infrastructure and operations costs

12→4 hrs

Mean Time to Recovery (MTTR) reduction

94%

Automated test coverage across all new microservices

Lessons Learned

Key Insights from This Engagement

1

The strangler fig pattern was critical for managing risk in a zero-downtime environment. By running legacy and new systems in parallel with Kafka-based event synchronization, we could validate each migration step with production data before cutting over — eliminating the "big bang" migration risk that had derailed the previous attempt.

2

Canary deployments with automated rollback proved essential in a regulated financial environment. The ability to deploy to 5% of traffic and automatically revert on anomaly detection gave the compliance team confidence that no regulatory violation could persist in production.

3

Investing in comprehensive observability from day one (not as an afterthought) dramatically accelerated the team's ability to diagnose issues across the distributed system. The correlation between deployment events and system metrics was invaluable during the critical migration phases.

4

Structured governance and transparent reporting rebuilt executive confidence after a previously failed vendor engagement. The weekly reports and QBR format became the template the bank adopted for all subsequent vendor relationships.

Discuss a Similar Challenge

Schedule a confidential discovery call to explore how we can deliver measurable outcomes for your organization.

Schedule a Call