Moving a core banking or financial system off legacy infrastructure is one of the highest-stakes technical projects a financial institution can run — the failure modes aren't just downtime, they're compliance exposure, data integrity gaps, and regulatory scrutiny that can outlast the project itself. This checklist walks through the questions and steps that matter most before, during, and after cutover, built for CTOs, CDOs, and compliance leads planning a migration.

Who this is for: fintech and financial services teams evaluating or planning a migration of core systems, ledgers, or customer data off legacy on-premise infrastructure to the cloud.

Before You Start: Map What You Actually Have

  • [ ] Inventory every application, batch job, and integration point that touches the legacy system — including undocumented point-to-point integrations that accumulated over years.
  • [ ] Identify data dependencies: what feeds the legacy system, and what downstream systems consume its output.
  • [ ] Classify data by sensitivity and regulatory scope (PII, payment card data, AML/KYC records, transaction ledgers).
  • [ ] Document which regulatory frameworks apply — Basel III, PCI DSS, SOX, GDPR, local central bank directives — and what each requires for data handling during a migration, not just after.

Compliance and Data Residency

  • [ ] Confirm data residency requirements for every jurisdiction you operate in — some regulators require data to stay within national borders even in a cloud environment.
  • [ ] Verify the cloud provider's compliance certifications match your regulatory obligations (SOC 2, ISO 27001, PCI DSS, relevant regional certifications).
  • [ ] Check whether your regulator requires pre-notification or approval before migrating core systems to cloud infrastructure — several banking regulators now ask specifically about cloud vendor management during examinations.
  • [ ] Plan for auditability: can you reconstruct a full audit trail of the migration itself, not just post-migration operations?

Architecture Decisions

  • [ ] Decide hybrid vs. full cloud — for many institutions, regulated or latency-sensitive workloads (core ledger, real-time payments) stay on private infrastructure while reporting, analytics, and customer-facing apps move to public cloud.
  • [ ] Determine whether a lift-and-shift, re-platform, or full rebuild is the right approach for each system component — they rarely all take the same path.
  • [ ] Plan for disaster recovery and business continuity in the new environment before go-live, not as a follow-up project.
  • [ ] Confirm encryption standards for data at rest and in transit meet or exceed your current on-premise baseline.

Data Migration Execution

  • [ ] Run a full data quality audit before migration — legacy financial systems commonly carry decades of inconsistent formatting, duplicate records, and orphaned data.
  • [ ] Define a reconciliation process that validates record counts and key financial totals match exactly between old and new systems post-migration.
  • [ ] Plan the migration in phases with defined rollback points rather than a single all-at-once cutover, especially for core ledger systems.
  • [ ] Test with a full production-scale data set in a staging environment before the real cutover — sampled test data hides scale-related bugs.

Vendor and Partner Evaluation

  • [ ] Does the migration partner have direct experience with regulated financial institutions, not just general cloud migration?
  • [ ] Who owns the risk if the migration causes a compliance gap or reporting error — is that liability addressed in the contract?
  • [ ] What's the rollback plan if a critical issue surfaces after cutover, and how quickly can it be executed?

Cutover and Post-Migration

  • [ ] Schedule cutover during a low-transaction-volume window, with a communicated freeze period for non-critical changes.
  • [ ] Keep the legacy system available in read-only mode for a defined period as a safety net and audit reference.
  • [ ] Monitor system performance and error rates closely for at least the first full reporting cycle post-migration.
  • [ ] Update your compliance documentation and risk register to reflect the new infrastructure — regulators will expect this to be current.

Red Flags to Watch For

A migration partner who can't clearly answer data residency questions, a plan with no rollback strategy for the core ledger, or a data quality audit skipped to save time are the issues that turn a migration project into a compliance incident. If your regulator hasn't been looped in and the project is already underway, that's worth pausing to fix.

How to Use This Checklist

Work through each section in order — mapping and compliance scoping first, architecture second, execution third. Treat unchecked compliance items as blockers, not follow-ups; retrofitting compliance after a financial system has already moved is far more expensive than building it into the plan.