Emergency Cloud Migration of a Core Banking Platform During the Outbreak of War in Ukraine

The challenge

When I joined, the mandate was a structured multi-year modernisation: careful evaluation of each component, proof-of-concept phases and 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 and above the modernisation plan itself.

The risk was physical. Data centers are buildings: they need power, cooling and staff access. From the first day of the invasion, connectivity disruptions were tracked across several Ukrainian regions, and in March 2022 Ukrtelecom, the national provider, had a major disruption linked to physical damage to its fiber network. The open question was whether the migration would finish before the physical infrastructure was hit.

There was also a legal barrier. Ukrainian banking rules required bank data to stay on servers physically located inside Ukraine, so a move to the cloud was prohibited. Within hours of the invasion the bank’s leadership approved the move anyway, and the National Bank of Ukraine formally allowed it on 8 March 2022.

There was no playbook. The high-level plan was to migrate the most critical components first. How to do that with distributed teams, intermittent connectivity, missile alerts interrupting work, and infrastructure that had never been designed for an emergency cloud exit was figured out in real time.

My task: as Technical Lead of the Core Banking Platform, move the platform and its critical databases to the cloud as fast as possible with the L2 (SRE) and L3 (DevOps) teams, without interrupting banking services for customers.

Why couldn’t Ukrainian banks simply move to the cloud?

Before the war, Ukrainian rules required banks to keep their data on servers inside Ukraine, so foreign public clouds were closed to them. On 8 March 2022 the National Bank of Ukraine adopted Resolution No. 42 on banks’ use of cloud services under martial law. It allows banks to process and store client personal data and bank secrecy information in cloud services whose equipment is in the EU, the UK, the USA or Canada, for the period of martial law and two years after it. Banks remain responsible for the confidentiality, integrity and security of the data, and the National Bank must be able to get access to it. By June 2022, according to the National Bank, 46 banks had moved or copied their data to foreign clouds.

What I did

1. Triaged core banking systems for an emergency cloud exit

   The first decision was what to migrate first, and it was made under invasion conditions. I triaged the core banking platform components by how critical they were for customer operations and by how physically vulnerable they were. Not everything could or needed to move at once. The order decided which bank operations were protected first and which stayed at risk during the transition. A wrong call under time pressure meant 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. Moved the bank to a multi-cloud and hybrid setup, with AWS as the main cloud

   The target was multi-cloud and hybrid. Most of the load went to AWS. The Microsoft stack, such as Active Directory, went to Azure, AIX and other legacy systems went to IBM Cloud, and dozens of Oracle databases went to Oracle Cloud. The database team was responsible for the Oracle migration, and I consulted them from time to time. We built connections between the clouds, and within two to three months AWS Direct Connect was in place, which gave us enough capacity to migrate everything.

   Technical details

   • AWS Direct Connect: a dedicated, private network connection between the bank’s network and AWS, with more predictable performance than a connection over the internet.
   • Inter-cloud connections: network links between AWS, Azure, IBM Cloud and Oracle Cloud, so systems that moved to different clouds could keep working together.

3. Migrated the Kubernetes-based core banking platform with zero downtime

   My direct responsibility was the core banking platform: a Kubernetes platform with more than 900 applications, together with critical databases holding personal and client data. Banking services cannot go down. In wartime Ukraine people relied on the financial system for everything from withdrawing cash to receiving international aid payments, so a banking outage would have harmed people directly. We migrated the platform with the zero-outage discipline that any banking migration requires, while the team worked around the clock, sometimes during active missile alerts, with engineers working remotely over disrupted connectivity. The migration completed without a single business outage.

   Technical details

   • Speed first: most components were moved as they were (rehost, or lift and shift), and modernisation came later.
   • Cutovers at night: systems were switched in night-time maintenance windows, so customers saw little or no impact.

4. Kept the migration within banking rules that changed during the war

   The migration started before the rules formally allowed it, with the approval of the bank’s leadership. When the National Bank of Ukraine published its emergency rules for cloud services on 8 March 2022, the migration had to meet them: where the cloud equipment could be, how the data was protected and how the regulator could get access to it. I managed these legal and compliance questions alongside the technical work, in a regulatory environment that was changing in real time.

   Technical details

   • What the emergency rules required: cloud equipment in the EU, the UK, the USA or Canada; encryption that meets Ukrainian law or the law of the country where the equipment is; the bank stays responsible for the confidentiality, integrity and security of the data; access to the data for the National Bank of Ukraine and the Deposit Guarantee Fund.

5. Led the SRE and DevOps teams and coordinated the bank through the crisis

   I managed the L2 (SRE) and L3 (DevOps) teams. The engineers were living through a war in their own country, with family members in danger, missiles falling within range of where they worked and no certainty about safe working conditions the next day. Keeping the team performing meant keeping decision quality and output up while managing fear and exhaustion alongside technical problems. A core banking migration also touches every part of the bank: payments processing, customer data management, regulatory reporting, risk systems and the operational teams who depend on the infrastructure every day. I coordinated across departments and bank leadership to keep shared situational awareness, manage dependencies and keep services running. The work continued around the clock, the team held, and the mission was completed.

Results

In about 6 months, under active conflict, the work delivered:

• The Kubernetes-based core banking platform, with more than 900 applications and critical databases with client data, moved from data centers under military threat to the cloud.
• A multi-cloud and hybrid setup: most of the load on AWS, the Microsoft stack on Azure, AIX and other legacy systems on IBM Cloud and Oracle databases on Oracle Cloud, linked by inter-cloud connections and AWS Direct Connect.
• Zero business outages: banking services kept running for customers through the first months of the war.
• A migration that met the National Bank of Ukraine’s emergency rules for bank data in the cloud.
• A reference case for banks: McKinsey, Euromoney and AWS covered the migration, and Raiffeisen Bank Ukraine became RBI Group’s centre of expertise for cloud migration.
• First-hand patterns for geopolitical risk that I now use when advising: dependency inventories before a crisis, tested restore procedures, executive thresholds for action and multi-region architecture that doesn’t share a geopolitical zone. They became my framework for architecture in an unstable world.

What I learned

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, but not for the physical location of the data centers becoming the main risk. Infrastructure that has never failed can still fail when the threat model changes. Organisations that build resilience before they need it have options; organisations that discover the gap on the first day of a crisis have only urgency. The second lesson: in a real crisis, speed of decision beats quality of analysis. When the risk is physical and time is measured in hours, you make reversible decisions fast and correct course as reality gives you feedback.

Evidence and further reading

• Article · this siteArchitecture in an Unstable World: a practical framework for geopolitical riskThe framework that grew out of this migration.
• Interview · McKinseyA cloud migration in wartimeThe bank’s CTO on the migration, in McKinsey’s Cloud Value Radio (2023).
• Article · EuromoneyBanking in Ukraine: theory and practiceThe bank’s CEO on banking through the first months of the war (2022).
• Related projectDORA compliance: benchmarking data center resilience for a Tier-1 Spanish bankBank resilience tested on paper, before a crisis.
• Service · this siteCloud migration consultingHow I plan and lead migrations to the cloud.

“Architecture in an Unstable World” was also published on CloudTweaks.

Skills and technologies

• Emergency cloud migration
• Core banking platform
• Banking cloud migration
• AWS migration
• Multi-cloud
• Hybrid cloud
• Kubernetes
• AWS Direct Connect
• Inter-cloud networking
• Azure
• IBM Cloud
• Oracle Cloud
• Zero-downtime migration
• Lift and shift (rehost)
• Business continuity
• Data residency
• Banking regulation and compliance
• Geopolitical risk
• Crisis leadership
• SRE and DevOps team leadership

← All projects