Wolf&Grayson EditorialIn March 2026, the European Banking Authority issued its first formal findings under DORA’s Critical Third Party Provider supervision framework — citing documentation gaps, untested recovery assumptions, and concentration exposures that financial entities had self-reported as managed. The findings did not name institutions. They did not need to. Every regulated firm running material workloads on a designated hyperscaler received the same message: the supervision is live, the expectations are concrete, and the migration period itself is now an examination focus area.
David Fapohunda has been preparing for this moment for some time. A cloud transformation leader with deep experience inside regulated financial institutions, he starts migration programs somewhere most leaders do not. Before deciding what to migrate, he decides what he is not migrating — and why. “If the steering committee cannot articulate the tiering logic in one slide,” Fapohunda states, “the program is not ready to launch.”
The First Decision Is Not Vendor Selection. It Is What Does Not Move.
Most cloud migration programs in regulated financial firms fail at the framing stage, not the execution stage. The vendor gets selected, the landing zone gets designed, and the steering committee gets excited — but nobody has made the first decision that actually determines whether everything else goes right.
That decision is portfolio segmentation: applying a clear, regulator-defensible filter that separates what must move, what should be re-architected, what stays on premise, and what gets retired entirely. It determines the total cost of ownership model, the concentration risk profile, the regulatory engagement plan, the talent demand, and the capacity to handle exceptions when something inevitably breaks.
Fapohunda tiers the estate by criticality and regulatory weight. Critical ICT functions under DORA Article 28 follow one playbook. Customer-facing but non-critical workloads get another. Internal productivity tools get a third. The architectural target is decided before the cloud target: cloud-native, refactored, re-platformed, re-hosted, or retired. A lift-and-shift of legacy COBOL into a managed virtual machine is a more expensive version of the same problem, not modernization.
He also briefs the regulator before the program launches, not after. Under OCC Bulletin 2025-24, examiners now treat the migration period itself as a supervisory focus area. In his experience, institutions that engage early get materially more predictable examination outcomes. Those that do not find themselves explaining decisions retrospectively, under examination pressure, with fewer options.
When leaders skip this framing work, they land in what EY identifies as the three- to five-year dual-run trap — paying for both estates simultaneously, with cost-benefit erosion becoming visible only at year three. At a mid-size financial institution running a $500 million technology estate, an 18-month dual-run extension translates to $40 million to $70 million in unplanned infrastructure carry cost, before accounting for the talent and governance overhead of managing two parallel environments. The sequence is the difference between a program that delivers and one that quietly stalls.
Multi-Cloud Is a Procurement Strategy. It Has Never Been a Resilience Strategy.
The 2025 hyperscaler outage record made the theoretical concrete. The AWS US-EAST-1 event in October ran 12 to 15 hours, taking down Lloyds Bank, Coinbase, Robinhood, and Venmo and affecting roughly 32% of global cloud infrastructure traffic. Azure Front Door failed on October 29th. Google Cloud caused a global authentication lockout in June. One industry analysis documented 38 AWS incidents and 78 GCP incidents in the first eight months of 2025 alone. Taken together, these were not isolated failures. They were a systematic demonstration that concentration risk in cloud infrastructure is not a theoretical concern — it is a live operational exposure that no single firm’s architecture fully controlled.
The regulatory response followed. The European Supervisory Authorities formally designated 19 Critical Third Party Providers under DORA, including AWS, Microsoft Azure, Google Cloud, IBM, and Oracle. Hyperscalers are now under direct EU supervision. Financial entities are operationally responsible for their resilience against those providers’ failures. The two facts sit together with significant consequence: the firms that experienced outage impact in 2025 and cannot demonstrate tested fallback capability are, in 2026, the firms with the most difficult supervisory conversations ahead.
“Untested DR is paper resilience to me,” Fapohunda states. The regulator’s calculus is straightforward — a firm that experienced a major outage but can demonstrate a documented, tested fallback faces materially less regulatory heat than one presenting only architectural diagrams.
That reframing extends to the multi-cloud assumption most boards are currently operating on. Running production in AWS and analytics in Azure is a procurement diversification. It is not a hedge against a primary provider going dark for 15 hours. Thomas Olsen, a partner at Kearney advising European financial institutions on DORA compliance architecture, puts it plainly: “The question regulators are now asking is not whether you use multiple clouds. It is whether your business can actually operate when the one that matters most goes down.”
Fapohunda builds concentration risk documentation explicitly, treats DORA Article 30 contractual obligations as non-negotiable, and pushes the board to consciously decide which workloads will tolerate single-provider exposure and which warrant the resilience premium. That decision gets documented, revisited annually, and stress-tested — not filed and forgotten.
Where Programs Lose Momentum, and Why the Governance Gap Is the Actual Cause
The firms that failed their DORA readiness assessments in early 2026 shared a common pattern: their technical migration had progressed, but their governance infrastructure had not kept pace. Workloads were in the cloud. The documentation, the tested recovery procedures, and the board-level risk ownership were not. That gap — between technical progress and governance maturity — is precisely where Fapohunda sees programs lose momentum, and where regulatory exposure accumulates quietly until it becomes visible all at once.
Getting to the cloud is the relatively straightforward part. Getting business outcomes from the cloud is where roughly 70% of programs stall. The failure mode is organizational. IT marks technical milestones complete. Finance sees costs not yet declining. Product sees release velocity unchanged. Three groups, three different definitions of success, no shared scoreboard.
The dual-run cost spiral compounds the problem. EY 2025 data shows decommissioning timelines extend 12 to 24 months beyond original program estimates in the majority of programs. That extension directly erodes the TCO case the program was sold on — and creates the conditions under which boards begin questioning whether the investment thesis was sound, rather than whether the execution sequence was wrong.
Fapohunda’s response to a stalling program is to reset the scoreboard before anything else: three to five shared outcome metrics owned jointly by IT, finance, and the business line, made board-visible monthly. He also forces decommissioning into the critical path rather than treating it as a phase that follows migration. No new workload moves until the prior wave’s legacy footprint is dark.
He then finds a lighthouse — one team or product where cloud and DevSecOps are genuinely embedded — and resources it disproportionately. One McKinsey case study showed a European bank achieving delivery teams 20% to 30% smaller once this model was in place. That internal proof point recruits the rest of the organization in a way that no steering committee presentation can.
The Migration Office Needs to Become a Permanent Function. Most Institutions Have Not Made That Shift.
Cloud migration in 2026 is no longer a one-time program. It is a permanent operating discipline, binding together portable workloads, sovereign data planes, agent governance, continuous resilience testing, and board-level operational risk reporting. The institutions that understand this are building the infrastructure — organizational, not just technical — to sustain it indefinitely. The institutions that do not are running time-limited programs against a permanently moving regulatory and architectural landscape.
The first DORA supervisory findings clarified what was already implicit in the regulation: the examination focus does not end when the migration does. It begins there. Leaders still treating cloud migration as a project with a completion date are, at this point, not behind on a program. They are behind on a function that should already be permanent.
The gap between those two positions is not closing on its own.
Follow David Fapohunda on LinkedIn for more insights on cloud migration leadership, regulated financial services transformation, and building the governance frameworks that make large-scale programs deliver.
