I joined Raiffeisen Bank Ukraine as Technical Lead of the Core Banking Platform two days before the full-scale Russian invasion began on 24 February 2022. The plan I had been given was a carefully structured multi-year modernisation roadmap. Within 72 hours of my arrival, that plan became irrelevant. Our data centers were physically located in Ukraine – under active military threat. The mission became singular and urgent: migrate the most critical parts of the bank’s infrastructure, including client and financial data, to the cloud before physical harm could reach it. This was not a technical project. It was infrastructure survival under wartime conditions.
Wartime emergency migration
Core banking platform
Regulatory constraint waiver
On-prem → Cloud under fire
Zero business outages
Crisis leadership
Core banking platform
Regulatory constraint waiver
On-prem → Cloud under fire
Zero business outages
Crisis leadership
OrganisationRaiffeisen Bank Ukraine
ScopeCore banking platform migration
EnvironmentOn-premise (Ukraine) → Cloud
Timeline~6 months under active conflict
My roleTechnical Lead – Core Banking Platform
OutcomeCritical infrastructure protected, zero outages
2 days
after joining, invasion began
~6 months
critical systems migrated to cloud
Zero
business outages during migration
Legal
barrier waived by central bank in hours
24/7
under missile alerts during execution
This migration became a globally referenced case study · Featured by McKinsey, Euromoney, and AWS · Raiffeisen Bank Ukraine became the RBI Group’s cloud migration centre of expertise
The Context No Case Study Template Accounts For
There is no framework for this scenario. Every cloud migration methodology assumes you have time to plan, a stable operating environment, and decision-making capacity that isn’t interrupted by air raid alerts. None of those assumptions held here.
The plan I arrived with became irrelevant in 48 hours
When I joined Raiffeisen Bank Ukraine, the mandate was a structured multi-year modernisation: careful evaluation of each component, proof-of-concept phases, strong customer continuity protections. That plan assumed a stable operating environment. Two days later, speed of migration became the absolute priority – above cost, above stability, above the modernisation plan itself. The carefully designed multi-year roadmap became irrelevant overnight.
Ukrainian law required bank data to stay on servers inside Ukraine
This is the constraint that makes this migration categorically different from any other. Ukrainian banking regulation prohibited cloud migration: bank data had to be stored on servers physically located inside Ukraine. The moment war started, those legal protections became a liability – not a safety net but a trap. The National Bank of Ukraine waived the restriction within hours of the invasion. Banks moved immediately. Legislation followed the emergency action, not the other way around.
The risk was physical, not theoretical
Data centers are buildings. They require power, cooling, and staff access. From day one of the invasion, connectivity disruptions tracked across multiple Ukrainian regions. Ukrtelecom, the national provider, suffered a major disruption linked to physical damage to fiber infrastructure. This was not risk modelling – it was operational reality. The question was not whether physical infrastructure would be threatened but when, and whether the migration would complete before that happened.
There was no playbook – decisions were made during execution
The high-level plan was: migrate the most critical components first. How exactly to do that under wartime conditions – with distributed teams, intermittent connectivity, missile alerts interrupting work, and infrastructure that had never been designed with emergency cloud exit in mind – was figured out in real time. Every architecture and sequencing decision was made under conditions that no migration methodology had accounted for.
What I Did
1
Triage and prioritise critical infrastructure for immediate cloud exit
The first decision – made under invasion conditions, not in a planning meeting – was what to migrate first. Core banking platform components were triaged by criticality to customer operations and by physical vulnerability. Not everything could or needed to move immediately. The sequencing decision determined which bank operations remained protected and which were still at risk during the transition. Getting this triage wrong under time pressure would mean either exposing critical customer data to physical harm or disrupting banking services that millions of Ukrainians depended on during the worst days of the war.
2
Execute migration of core banking systems – with zero tolerance for downtime
Banking services cannot go down. In wartime Ukraine, with citizens relying on the financial system for everything from withdrawing cash to receiving international aid payments, a banking outage was not just a service degradation – it was a human harm. The migration of core banking infrastructure was executed with the same zero-outage discipline that any banking migration requires, under the additional constraint that the team was operating around the clock, sometimes during active missile alerts, with distributed engineers working remotely across disrupted connectivity. The migration completed without a single business outage.
3
Coordinate across bank leadership and departments under crisis conditions
A core banking migration does not happen in isolation. It intersects with every part of the bank: payments processing, customer data management, regulatory reporting, risk systems, and the operational teams who depend on the infrastructure daily. Coordinating across departments and bank leadership – maintaining shared situational awareness, managing dependencies, and keeping continuity of services intact – while the country’s infrastructure was under active attack required a quality of cross-functional leadership that no normal project environment demands. The organisational challenge was as significant as the technical one.
4
Lead the team through sustained performance under extreme psychological pressure
The engineers on the migration team were not just employees under stress. They were people living through a war in their country – with family members in danger, with missiles falling within range of where they worked, with uncertainty about whether they would have safe operating conditions the next day. Keeping the team performing – maintaining decision quality, sustaining output, managing fear and exhaustion alongside technical problems — was its own form of leadership. The work continued around the clock. The team held. The mission completed.
What This Engagement Demonstrates
🆘
Crisis decision-making for critical infrastructure – without a playbook
There is no textbook for emergency migration of core banking infrastructure under active military attack. Every sequencing decision, every architectural trade-off, and every team management call was made in real time, under conditions where the consequences of error were not “we need to roll back” but “client data is physically at risk.” This is decision-making at a quality and speed that no peacetime project environment produces.
🏦
Banking infrastructure continuity under the hardest possible conditions
Zero business outages in a wartime banking migration is a result that stands independently of the circumstances. Banking infrastructure does not get simpler to migrate under missile alerts. The fact that the migration completed with full continuity of service – while the operating environment was actively hostile – is evidence of technical and organisational discipline that no stress-test can fully replicate.
⚖️
Navigating regulatory constraints that changed overnight
The migration started as an illegal act – Ukrainian banking law prohibited exactly what we needed to do. The National Bank of Ukraine’s emergency waiver changed that, but it happened within hours of the invasion. Understanding the regulatory landscape, acting decisively the moment the constraint was lifted, and managing the legal and compliance dimensions of the migration alongside the technical ones – in a legal environment that was evolving in real time – is a dimension most architecture engagements never encounter.
🧭
Geopolitical risk – from theory to live operational reality
Most architects who write about geopolitical resilience have not actually led infrastructure operations during a geopolitical event. I have. The patterns I now apply when advising on geopolitical risk – dependency inventories before crisis, tested restore procedures, executive thresholds for action, multi-region architecture that doesn’t share a geopolitical zone – are not frameworks I designed in a quiet office. They were learned under the conditions that make them necessary. This experience directly informed my published work on geopolitical resilience architecture.
🤝
Leading people through the hardest conditions any team can face
Technical leadership during crisis is not just about architecture decisions. It is about maintaining team function, decision quality, and morale when the people you’re leading are personally at risk, exhausted, and uncertain about their own safety. The engineering discipline that delivered zero outages was inseparable from the human leadership that kept the team operational through weeks of round-the-clock work under conditions nobody signed up for when they joined the bank.
Skills This Engagement Evidences
Crisis infrastructure leadership
Led critical infrastructure migration under active military threat with no established playbook. Decision-making under conditions where error consequences are irreversible – not recoverable.
Core banking platform migration – zero outages
Migrated the most critical components of a major bank’s core infrastructure to cloud over ~6 months without a single business outage. Under wartime operating conditions.
Regulatory navigation under emergency conditions
Managed migration that began as legally prohibited – activated immediately when the central bank issued an emergency waiver. Compliance and legal dimensions managed in parallel with technical execution, in a regulatory environment changing in real time.
Geopolitical risk – first-hand operational experience
Not theoretical. Led infrastructure operations during an active geopolitical event – physical infrastructure under missile threat, national connectivity disruption, regulatory waiver within hours of invasion. Source of the published geopolitical resilience framework on CloudTweaks.
Infrastructure triage and crisis sequencing
Prioritised what to migrate first when everything was at risk simultaneously. Sequencing decisions under existential time pressure – balancing physical risk to data, continuity of banking services, and team capacity – with no margin for analysis paralysis.
Cross-functional leadership under sustained crisis
Coordinated across bank departments and leadership to maintain banking service continuity during migration. Sustained team performance through weeks of around-the-clock work under conditions of direct personal risk to team members.
Instant strategic pivot from long-term plan to emergency execution
Transitioned from multi-year structured modernisation planning to emergency mission in 48 hours. Discarding a carefully designed roadmap when the operating context changes fundamentally – and executing against a new one under pressure – is a specific cognitive and leadership capability.
Real-time decision-making without complete information
Architecture and sequencing decisions made with degraded information, intermittent communication, and no precedent to follow. The ability to make good-enough decisions fast – rather than waiting for perfect information that never comes – is a crisis capability distinct from analytical planning skill.
The Core Insight from This Experience
Geopolitical risk is not a planning input until it suddenly becomes the only input.
Before the invasion, the multi-year modernisation plan was technically sound and well-sequenced.
It accounted for performance, compliance, cost, and customer continuity. It did not account for
the physical location of the data centers becoming the primary risk.
The lesson I carry from this: infrastructure that has never failed is not infrastructure that
will hold when the threat model changes. Every assumption about what “normal operations”
looks like is a latent risk. Organisations that build resilience before they need it have options.
Organisations that discover the gap on day one of a crisis have only urgency.
The second insight: in a real crisis, speed of decision beats quality of analysis.
Waiting for a complete picture is not an option when the risk is physical and time is measured in
hours. The capacity to make reversible decisions fast, and course-correct as reality provides
feedback, is what crisis leadership actually looks like.
This experience became the foundation of my published framework on geopolitical resilience architecture, specifically for organisations with infrastructure in or dependent on regions of elevated geopolitical risk.
→ Architecture in an Unstable World — CloudTweaks
Who This Is Relevant For
Most organisations will never face a wartime migration. But the underlying challenges – crisis decision-making, infrastructure resilience, regulatory constraints, and geopolitical risk – are universal.
Your infrastructure has geopolitical exposure you haven’t formally assessed
Data centers in regions of political or military instability, hardware supply chains concentrated in specific geographies, operations dependent on connectivity through conflict-adjacent routes – these are risks that appear theoretical until they are not. The question is whether your organisation discovers them in a planning meeting or on the day they become operational reality.
You operate critical infrastructure where downtime is not recoverable
Banking, healthcare, utilities, emergency services, financial markets – platforms where an outage is not a service degradation but a harm. The discipline required to migrate critical infrastructure without business disruption is the same regardless of whether the pressure comes from a business deadline or a military threat. The wartime conditions here tested this discipline at its absolute limit.
You need crisis-tested leadership, not just project management experience
Most technology leadership has been tested in difficult projects. Some has been tested in genuine crises. The difference is significant: in a crisis, the normal levers of authority, timeline, and information quality all degrade simultaneously. Leadership that has held under those conditions transfers to any high-pressure situation – a failed migration, a regulatory deadline, a production incident that threatens the business.
You’re building a resilience case to present to your board
Boards increasingly recognise geopolitical infrastructure risk – especially for companies with significant operations in Asia, the Middle East, Eastern Europe, or with hardware dependencies on specific regions. Having a framework that is grounded in direct operational experience – not theoretical modelling – changes the quality of the conversation.
Your migration plan exists on paper but hasn’t been stress-tested
Most disaster recovery plans, cloud exit strategies, and business continuity documents are tested against theoretical scenarios. The difference between a plan that works and a plan that looks good is only visible when the scenario is real. An architect who has executed a genuine emergency migration knows where the assumptions in standard plans break down.
You work in financial services and understand what Ukrainian banking proved
Raiffeisen Bank Ukraine’s migration became a globally referenced case study – covered by McKinsey, AWS, and Euromoney – because it proved that core banking infrastructure can be migrated to cloud at emergency speed without business outages. It changed the conversation about what’s possible in regulated financial institutions worldwide. That experience is directly applicable to any financial institution assessing cloud migration risk and feasibility.
Assessing infrastructure resilience, planning a critical migration, or preparing for geopolitical risk?
In 30 minutes I can tell you whether your situation maps to what I do – what the real risks are in your specific infrastructure context, and what a structured approach looks like when the stakes are high and the timeline isn’t flexible.
No pitch. A direct conversation about your infrastructure, its vulnerabilities, and how to address them before they become incidents.