All articles

Bank migrated its core systems to the cloud

A bank migrated its core systems to the cloud, maintained 100% uptime during the transition and reduced the time needed to launch new products by approximately 80%.

Azure migration
View full image ↗

A bank migrated its core systems to the cloud, maintained 100% uptime during the transition and reduced the time needed to launch new products by approximately 80%. What interests me most is how the transformation was delivered.

Microsoft recently published a case study on OYAK ANKER Bank in Germany, which modernised its ageing legacy systems with a cloud-native banking environment. The bank faced familiar enterprise transformation challenges: difficult-to-maintain infrastructure, complex integrations, manual processes and slow product launches.

Rather than simply transferring its existing systems to the cloud, the bank made a more fundamental decision. It chose to re-architect its technology environment, even though a straightforward migration might have offered a faster route to implementation.

What I find particularly interesting from a programme delivery perspective is the approach that followed. Before migrating production workloads, the team assessed its technology landscape, mapped business processes, evaluated regulatory requirements and established the target architecture. Proofs of concept and pilot workloads helped validate the solution before the final transition.

The production migration took place in May 2025 using a big-bang cutover approach, following earlier preparation and implementation phases. According to Microsoft's September 2026 case study, the bank maintained 100% uptime during migration, automated approximately 55% of previously manual operational workloads and reduced incident resolution time by about 50%.

For project and programme professionals, there is an important lesson about delivery speed, technical decisions and long-term business value. A faster implementation is not necessarily better if it creates operational complexity or limits the organisation's ability to adapt. Equally, a one-time cutover does not automatically mean poor sequencing. Here, substantial assessment, testing and architectural preparation preceded the transition.

Of course, the results are specific to this programme, and the same migration strategy would not suit every organisation. The appropriate approach depends on operational dependencies, regulatory requirements, technical complexity and acceptable business risk. But the case demonstrates something worth considering: delivery decisions should account for the capabilities the organisation needs after implementation, not just the effort required to reach go-live.

The bank's reported improvements in product delivery speed and operational efficiency suggest value beyond replacing its technology infrastructure. For me, this shows how deliberate programme planning and technical modernisation can support continued business improvement.

Good ideas get better in conversation.

Continue the conversation