Cloud Migration for Banks: Why Finance Needs a Different Approach

Why Cloud Migration for Banks Is Different

Gartner forecasts that by 2028, over 60% of all banking workloads will run in the public cloud — a dramatic increase from today (Gartner Research). Yet the migration velocity in banking lags well behind other sectors. Three structural barriers explain this gap.

The first barrier is regulatory complexity. Banks operate under a dense web of requirements: national banking laws, supervisory authority IT requirements (Germany's BAIT), DORA, GDPR, and — for large institutions — EBA guidelines on outsourcing and ICT risk. Every cloud outsourcing arrangement is potentially subject to notification or approval.

The second barrier is technical debt. Core banking systems (often COBOL-based, IBM Mainframe) were built in the 1980s and 1990s — long before APIs, microservices, or cloud architectures existed. Untangling these systems requires years of careful planning.

The third barrier is risk aversion. The management body of a bank bears personal liability for IT outages that harm customers or markets. This liability creates a strong incentive to maintain the status quo.

Step 1: Regulatory Preparation and Supervisory Communication

Before a single workload moves to the cloud, the regulatory framework must be established. In Germany, the relevant obligations include notification of the BaFin (Federal Financial Supervisory Authority) for material outsourcing arrangements, maintaining a complete ICT third-party register under DORA Art. 28, and ensuring the cloud security concept meets the BaFin's BAIT requirements.

DORA Art. 28 requires financial institutions to keep a full register of all ICT third-party service arrangements, distinguishing between arrangements for critical or important functions and those for non-critical functions. AWS provides templates and guidance through the AWS Financial Services Competency partner network.

Step 2: Discovery and Data Classification

Before migration begins, a complete inventory of workloads and their data is essential. This is especially demanding in banking, where historically grown systems are rarely fully documented.

The data classification framework for banks should cover at least four levels:

Amazon Macie automatically discovers and classifies sensitive data in S3 buckets — including PII, financial data, and credentials. For banks, Macie can recognize IBAN numbers, credit card data, and other banking-specific data patterns.

Step 3: Migration Strategy — The 7 Rs in FSI Context

The standard 7-R migration strategies apply to banking but with sector-specific modifications:

1. Retire: Banking systems are rarely fully decommissionable. Even apparently obsolete systems may hold legally required data from closed contracts (retention: up to 10 years). Digital archiving in Amazon S3 Glacier Instant Retrieval with Compliance Lock is the typical alternative.
2. Retain: Core banking on IBM z/OS or AS/400 is frequently retained initially. AWS Outposts or VMware Cloud on AWS enables a hybrid architecture where modern cloud services extend legacy systems without requiring immediate replacement.
3. Rehost (Lift & Shift): The simplest option for non-critical Windows and Linux servers. AWS Application Migration Service (MGN) replicates servers automatically into AWS and enables cutover with minimal downtime.
4. Replatform: Databases (Oracle, SQL Server) are moved to Amazon RDS or Amazon Aurora. The AWS Schema Conversion Tool (SCT) and AWS Database Migration Service (DMS) automate schema and data migration. Multi-AZ deployments ensure the high availability required by banking regulators.
5. Refactor/Re-Architect: The most important long-term step — breaking monolithic core banking applications into microservices. In banking, this requires close coordination with the core banking system vendor and typically a multi-year horizon.
6. Repurchase: Moving from self-hosted to SaaS (e.g., Salesforce for CRM, Workday for HR). Constrained in banking by strict data residency requirements — European SaaS providers preferred.
7. Relocate: VMware-based workloads can be moved seamlessly via VMware Cloud on AWS — without reconfiguration or new operating models.

Audit Trails: Ten-Year Traceability on AWS

Banks must maintain traceable records of transactions and system access over long periods. Requirements vary: credit files 10 years, payment data 5 years, securities transactions 7 years (MiFID II). AWS provides a tiered approach:

AWS CloudTrail with S3 Object Lock

CloudTrail records all AWS API calls immutably. Combined with S3 Object Lock (Compliance Mode), these logs can be frozen for the required retention period — no administrator can delete or modify them. This satisfies logging integrity requirements under banking supervision rules.

Amazon Security Lake

Centralizes security logs from AWS services and third-party sources in a standardized format (OCSF — Open Cybersecurity Schema Framework). Enables efficient search and analysis over long time periods — essential for post-incident forensics and regulatory inquiries.

Amazon CloudWatch Logs

Application and system logs are aggregated in CloudWatch Logs. Log groups can be configured with immutable retention policies and KMS encryption. For banking requirements, log data can be automatically transitioned to S3 Glacier for long-term archiving.

AWS MAP for the Financial Sector

The AWS Migration Acceleration Program (MAP) is the structured migration program developed specifically for complex enterprise migrations. For the financial sector, MAP offers FSI-specific playbooks, compliance frameworks, and financial support (Migration Credits):

As an AWS Premier Partner with Migration Competency, Storm Reply leads MAP projects in the financial sector and coordinates the application for Migration Credits that can significantly reduce AWS costs during the migration phase.

Frequently Asked Questions: Cloud Migration for Banks

Do banks need regulatory approval before migrating to the cloud?

Yes. Material outsourcing arrangements — including cloud hosting of critical applications — must be notified to the supervisory authority (e.g., BaFin in Germany) before going live. Since DORA, ICT third-party service contracts must also meet the minimum requirements of DORA Art. 30.

What is AWS MAP for the financial sector?

The AWS Migration Acceleration Program (MAP) is a structured three-phase migration program (Assess, Mobilize, Migrate/Modernize) with FSI-specific playbooks and financial Migration Credits. AWS Premier Partners like Storm Reply lead MAP projects and coordinate credit applications.

How long does a typical cloud migration take for a mid-sized bank?

Typically 18–36 months for a full migration of non-critical workloads. Core banking systems often require a longer horizon (3–7 years) with parallel modernization steps. Storm Reply recommends an iterative approach: first successes within 6 months, then stepwise expansion.