As Lead DevOps and Infrastructure Solutions Architect at R&D Center of SIXT – the international Austrian mobility and leasing group – I was responsible for the Cloud and DevOps transformation that supported the decoupling of Sixt Leasing SE’s legacy COBOL mainframe monolith into modern microservices. My scope covered the architecture and hands-on implementation of a unified Kubernetes platform for all projects on AWS, a single CI/CD solution for all development teams, monitoring and security architecture, and direct team leadership of five DevOps engineers. I participated in architectural discussions with Team Leads and Executive managers on the strategic direction of the full IT landscape.
COBOL mainframe modernisation
AWS EKS Kubernetes Platform
Monolith → Microservices
Jenkins CI/CD standardisation
Security architecture
SIXT Leasing SE
Penetration testing
OrganisationSIXT / SIXT Leasing SE (Austrian international group)
Legacy sourceCOBOL mainframe monolith
TargetMicroservices on AWS EKS
My roleLead DevOps & Infrastructure Architect
Team5 DevOps engineers managed
COBOL
mainframe monolith – the starting point
1
unified Kubernetes cluster for all projects
1
CI/CD platform for all dev teams
Kops → EKS
Kubernetes platform evolution
The Mainframe Context – Why This Is Harder Than Standard Cloud Migration
Most Cloud migrations move enterprise applications – databases, web services, APIs – to cloud infrastructure. COBOL mainframe modernisation is a categorically different problem. It is the hardest class of legacy transformation in enterprise IT, and it remains one of the most strategically urgent.
What COBOL mainframes represent in enterprise organisations
COBOL systems – typically running on IBM mainframe hardware (IBM z Series) – are the systems-of-record for mission-critical business processes in industries including financial services, insurance, leasing, automotive, and retail. They were built for reliability at scale, and they deliver it: an estimated 250 billion lines of COBOL remain in production globally, processing over $3 trillion in daily commerce. Mainframes cost up to $4,500 per MIPS per year in licensing alone, and that figure rises continuously as workloads grow.
The challenge is not that mainframes stop working. The challenge is that they become progressively impossible to evolve: shrinking COBOL developer talent pools, proprietary hardware lock-in that makes scaling expensive, near-zero interoperability with modern cloud services and APIs, and the accumulation of decades of tightly coupled business logic that cannot be safely extracted without understanding systems that may have lost their original authors.
Why mainframe modernisation requires infrastructure leadership, not just software development
Decoupling a COBOL monolith into microservices is not primarily a software rewrite problem – it is an infrastructure, platform, and DevOps problem. The extracted microservices need somewhere to run: a cloud platform designed to support independent deployment, scaling, and operation of dozens of independent services simultaneously. Without a production-grade Kubernetes platform, a standardised CI/CD mechanism, monitoring, and security architecture already in place, the microservices have nowhere safe to land. Infrastructure readiness is the prerequisite for application modernisation at enterprise scale.
The strategic inflection point: from CapEx-heavy mainframe to cloud-native OpEx
The business case for mainframe modernisation is structural: move from a capital-intensive, hardware-dependent, skills-scarce operating model to a cloud-native, elastic, developer-friendly one. For a leasing business like Sixt Leasing SE – where product features, pricing models, and regulatory requirements change continuously – the ability to deploy changes in hours rather than quarters is not just an operational convenience. It is a competitive necessity. The modernisation programme at SIXT was not an IT cost-reduction exercise. It was a strategic business capability transformation.
What I Did
1
Unified Kubernetes platform – Kops on AWS, then migrated to AWS EKS
Designed and implemented a single Kubernetes cluster to serve as the runtime platform for all Sixt Leasing SE projects. The initial cluster was built using Kops on AWS, providing fast initial capability. As the platform matured and operational requirements became clearer, I led the migration to AWS EKS – a managed Kubernetes service – to improve reliability, reduce operational overhead, and align with AWS-native operations. A single shared cluster for all projects replaced fragmented per-team infrastructure setups, eliminating the duplication of operational effort that had accumulated across independently-managed environments.
2
Single CI/CD platform for all development teams – Jenkins with dynamic build agents
Designed and implemented a unified CI/CD solution based on a Jenkins server with dynamic Jenkins agents (slaves), providing elastic build capacity that scaled with demand rather than requiring fixed build infrastructure. This single platform replaced multiple inconsistent delivery pipelines across development teams – standardising the path to production for all projects simultaneously. Dynamic agents meant build resources were provisioned on demand and released after use, removing the cost and maintenance burden of permanent build infrastructure.
3
Monitoring and reporting solution – operational visibility across all projects
Designed and implemented a comprehensive monitoring and reporting solution covering all projects running on the shared platform. When multiple teams share a single Kubernetes cluster, visibility becomes both more important and more complex: metrics, logs, and alerts need to be namespaced by project while remaining aggregated for platform-level health assessment. The monitoring solution provided teams with their own operational visibility while giving platform and security teams an enterprise-wide view.
4
Security architecture and internal penetration testing
Owned the security architecture for the full platform – covering network security, access control, secrets management, and the security posture of the Kubernetes cluster and CI/CD pipeline. Participated in internal penetration testing activities to validate the security controls in practice rather than just in design. In a financial services context (leasing and mobility), security architecture is a regulatory requirement, not just good practice, and it must be built into the platform from the start, not retrofitted after incidents reveal gaps.
5
Architecture discussions with Team Leads and Executive managers + DevOps team leadership
Participated directly in discussions with Team Leads and Executive managers regarding the future direction of the IT landscape at Sixt Leasing SE – representing the infrastructure and DevOps perspective in strategic architecture decisions. Simultaneously managed a team of five DevOps engineers, responsible for their direction, delivery, and professional development. Holding both the strategic architectural advisory role and the operational team leadership role in the same engagement is the combination that makes platform transformations coherent from top to bottom.
What This Engagement Demonstrates
🖥️
Understanding the full mainframe modernisation problem – not just the cloud side
Most cloud architects understand microservices and Kubernetes. Fewer understand where those microservices come from in a mainframe modernisation context – the business logic extraction from COBOL, the data migration from mainframe-native storage, the integration patterns needed to run hybrid during the transition period, and the specific constraints of regulated financial services environments where continuity of processing is non-negotiable. This engagement required both.
🏗️
Building a shared platform that serves all teams – not one team at a time
The standard approach to DevOps platform build is to start with one team and expand. The approach here – one Kubernetes cluster, one CI/CD platform, one monitoring solution for all projects from the start – is operationally harder but architecturally correct for organisations transitioning from fragmented legacy setups. It forces decisions about shared infrastructure governance, multi-tenancy, and platform reliability to be made explicitly rather than discovered through accumulated inconsistency.
📐
Kubernetes platform evolution – knowing when Kops is the right answer and when EKS is
Starting with Kops and migrating to AWS EKS is an architectural journey that reflects real operational learning, not indecision. Kops provides control and flexibility for initial cluster design and rapid deployment. AWS EKS reduces the operational burden of Kubernetes control plane management as the platform stabilises and the priority shifts from flexibility to reliability. Knowing when to make that transition – and executing it without disrupting running workloads – is a specific expertise that comes from having done it.
🔒
Security architecture embedded in platform design – not added after incidents
Participating in internal penetration testing while also designing the security architecture of the platform is an uncommon combination. Most architects design security controls; penetration testing validates them under adversarial conditions and reveals the gaps that design reviews miss. In a leasing and financial services context where customer data and financial processes are at stake, security architecture that has been adversarially tested is a materially different assurance than security architecture that has only been reviewed on paper.
Skills This Engagement Evidences
Mainframe modernisation – COBOL to cloud
Infrastructure leadership for COBOL mainframe modernisation – understanding the source system’s constraints, the business logic extraction challenge, and the hybrid-period integration patterns that allow mainframe and microservices to coexist during transition.
AWS EKS / Kubernetes platform architecture
Designed and operated a unified Kubernetes platform on AWS – initial Kops implementation, then EKS migration. End-to-end ownership from cluster design through operational maturity, supporting multiple independent teams on shared infrastructure.
CI/CD platform standardisation
Built a single Jenkins-based CI/CD platform with dynamic build agents for all development teams – replacing fragmented per-team delivery pipelines with a shared, elastic, maintainable standard across the organisation.
Security architecture + penetration testing
Designed and owned platform security architecture. Participated in internal penetration testing to validate controls under adversarial conditions. Security embedded in platform design, not retrofitted after incidents.
Monolith → microservices infrastructure support
Provided the Kubernetes runtime, CI/CD delivery, monitoring, and security platform that made microservices extraction viable – the infrastructure prerequisite that most modernisation programmes underinvest in before attempting application decomposition.
Monitoring and operational visibility
Designed and implemented monitoring and reporting covering all projects on the shared platform – namespaced by team, aggregated at the platform level. Operational visibility as a shared infrastructure service.
Executive-level architecture involvement
Participated in architectural discussions with Team Leads and Executive managers on the strategic IT direction of Sixt Leasing SE. Infrastructure and DevOps perspective represented at the level where strategic decisions are made.
DevOps team leadership – 5 engineers
Managed a team of five DevOps engineers during a complex platform transformation. Direction, delivery accountability, and professional development – in parallel with hands-on architecture and implementation responsibility.
The Core Insight from This Engagement
Mainframe modernisation fails at the infrastructure layer more often than at the application layer.
Organisations invest heavily in understanding which parts of the COBOL monolith to extract,
how to decompose business logic into service boundaries, and how to migrate data out of
mainframe-native storage. These are hard problems. But they cannot be solved if the platform
where the microservices land doesn’t exist, or exists in inconsistent, per-team configurations
that create more operational complexity than the mainframe they replaced.
The second insight: standardisation across teams must come before decomposition of the monolith,
not after. If each team builds its own Kubernetes cluster and its own CI/CD pipeline while
migrating components, the organisation ends up with microservices fragmentation on top of
infrastructure fragmentation – which is harder to operate than the original monolith.
The single unified platform built here was the prerequisite that made incremental
decomposition safe and manageable.
The third: for organisations still running COBOL mainframes, the question is not whether to modernise –
the shrinking talent pool, rising licensing costs, and inability to integrate with modern cloud services
and AI platforms make it inevitable. The question is whether modernisation is approached as a
strategic programme with proper infrastructure foundation, or as a series of reactive application
rewrites that create new forms of complexity.
Who This Is Relevant For
You’re planning or executing COBOL mainframe modernisation
The infrastructure and DevOps layer of mainframe modernisation – the platform that extracted microservices run on — is where these programmes most commonly stall. Building the cloud-native foundation before or in parallel with application decomposition, rather than after, determines whether modernisation progresses smoothly or accumulates its own technical debt.
Your teams each have their own infrastructure and CI/CD, and it’s becoming unmanageable
Fragmented per-team infrastructure is the natural result of teams solving their own problems independently. It works until the organisation is large enough that the duplication of effort and inconsistency of practice creates more cost than the alternatives. A unified platform – one Kubernetes cluster, one CI/CD system – consolidates that effort while raising the baseline for all teams simultaneously.
You’re migrating from a legacy monolith to microservices
Monolith decomposition produces new services continuously throughout a multi-year programme. Those services need a home: a Kubernetes platform that can accept new services quickly, a CI/CD pipeline that can onboard them without per-service configuration overhead, and monitoring that covers them automatically. The platform must be ready before decomposition begins, not built incrementally as services are extracted.
You operate in financial services, leasing, or other regulated industries
Security architecture in regulated industries is a compliance requirement, not just best practice. The combination of security architecture design and adversarial penetration testing – where you both design the controls and attempt to break them – produces materially higher assurance than either alone. This is the standard for environments where customer data and financial processes are at stake.
Your organisation needs infrastructure architects who can operate at executive level
Platform transformations that are designed in the architecture forum and executed by a separate implementation team frequently diverge. Having the same person who participates in executive architectural discussions also lead the DevOps team implementing the decisions eliminates the gap that normally produces that divergence.
You’re evaluating Kubernetes options — managed vs self-managed
The Kops → EKS evolution here reflects a real architectural decision: self-managed Kubernetes provides initial flexibility and control; managed EKS reduces control-plane operational burden as the platform stabilises. Understanding the right transition point, and executing it without downtime – comes from having operated both in a production context.
Planning a mainframe modernisation, building a unified DevOps platform, or migrating a monolith to microservices?
In 30 minutes I can tell you whether your situation maps to what I do – the infrastructure and DevOps foundation your modernisation programme needs, and whether the platform you’re building today will support the microservices you plan to extract tomorrow.
No pitch. A direct conversation about your legacy system, your modernisation ambitions, and where the real infrastructure complexity lives.
Book a 30-min consultation →
