Every CIO in a regulated industry has a system the business depends on, that no one fully understands and that must be replaced. In banking, it is often a core platform that predates the internet. In my own career, that system took two distinct forms: first, a VAX minicomputer running a parking operator’s entire business across nearly 200 New York City locations; later, the on-premises core of a global financial technology company supporting payments, banking and card issuing. Both had to move to the cloud without interrupting the customers that depended on them. The technology differed each time. The reasons the migrations succeeded did not.
Why regulated migrations fail differently
Migration failures come in two kinds. The loud kind takes a website down, engineers fix it and customers move on. The quiet kind — a pricing discrepancy, a missed filing, a mismatched reconciliation or a lost audit trail — may not surface for weeks. Its cost is measured in regulatory findings and lost client contracts rather than in hours of downtime.
Regulated migrations face both. The loud kind can be ruinous, as TSB learned in 2018 when a big-bang platform migration locked customers out for weeks and, after regulators found insufficient contingency planning and untested cutover configurations, drew a £48.65 million fine. The loud kind is at least visible. The quiet kind breaks the business without anyone noticing.
This changes what “without breaking the business” means. It does not mean zero outages. It means that at every point during the migration, the organization can prove that the new system produces the same outcomes as the old one for the cases that matter, or a difference the business has approved, and has a tested way to recover if it does not. That standard is stricter than most migration plans are written to, and it determines whether the program survives its first serious incident. Meeting it comes down to five operational disciplines.
Map the dependencies you were not told about
The formal dependency map in the architecture repository is always incomplete. The dependencies that break a migration are the informal ones, which grew up around the legacy system without ever being documented. A team in another department builds a nightly job that reads a file the legacy system happens to produce at 2 a.m., without the system’s owners knowing. An analyst in finance writes a spreadsheet macro that queries a database table directly, bypassing every official interface. A report goes to a regulator every quarter, generated automatically for so long that no one remembers how to produce it by hand.
Finding these dependencies takes careful observation. Configure the legacy environment to record every connection, every file it produces or consumes, and every scheduled job. Collect this data over a full business cycle, including month-end and quarter-end processing, before relying on the dependency map. This step is often dismissed as unnecessary, but it provides the evidence needed to plan the migration sequence. A workload should move only when its dependencies have moved, remain reliably accessible, or are confirmed to be no longer required.
The map must also account for people. Behind every critical legacy workload is a group of engineers or business analysts who know why an undocumented parameter exists or why a batch job runs only on the third Thursday of the month. Identify them at the outset, protect their time and capture what they know in reproducible test suites before they retire or move on.
A thorough map also reveals what to prune. Over decades, legacy estates accumulate dormant batch jobs, deprecated extracts and orphaned interfaces. Retiring these before cutover shrinks the migration scope and removes testing cycles spent on workflows that no longer serve anyone. Never decommission an idle process based solely on the monitoring window; verify with the responsible business owner and check historical run schedules for low-frequency jobs first.
Sequence cutovers around the business calendar, not the project plan
A project plan wants cutovers on a steady cadence. A regulated business has dates on which nothing may change, such as settlement days, filing deadlines, rate resets and month-end close. Build the migration calendar from the business calendar outward, placing cutover windows where you can detect and recover from failure before the next immovable date.
The discipline that makes this work is proving it at every stage before scaling to the next. Start with one workload, such as monthly billing or a single settlement feed, in the incremental style the Azure Architecture Center calls the strangler fig pattern. Run it on the new system in shadow mode alongside the legacy system for a full business cycle. Keep the legacy system as the system of record during this period. Capture the new system’s intended actions, such as payments and client messages, without sending them. Next, compare both systems’ outputs for each transaction and resolve any differences. Test external integrations, peak-load performance and recovery procedures separately, since shadow running never exercises the actions it suppresses.
Only then make the new system authoritative for that workload. Retain a tested recovery path through an agreed stabilization period, with a method for handling transactions recorded after cutover, and move on to the next workload. Where the architecture does not allow workloads to move independently, apply the same discipline to a coordinated group of them, with rehearsed cutovers and explicit acceptance criteria in place of the workload-by-workload sequence. Where even shadow running is not feasible, establish readiness through representative transaction replay, end-to-end testing and full cutover rehearsals, against the same acceptance criteria and with the same tested recovery path.
This is slower than a big-bang migration by a factor that sometimes makes executives uncomfortable. It is also the approach that produces evidence, rather than hope, before each increase in production exposure.
Keep the old system running until the new one has earned trust
The strongest temptation in any migration is to switch off the legacy system early, because running two systems costs money and because the old one is what the program exists to eliminate. Resist it. In a regulated environment, the legacy system is the reference implementation. It is the baseline against which every output of the new system is evaluated. Explain and resolve every material difference between the two systems, never mistaking agreement for correctness; then check the results against the business rules and the authoritative records.
When we moved a parking operator’s business from a VAX minicomputer to a cloud platform, the VAX ran alongside the cloud platform for months, and we reconciled every transaction between them until the new system earned the business’s trust. The parallel run let us catch and resolve issues before they reached customers. The cost of the parallel run was visible and budgeted. Had we skipped it, our customers would have discovered the errors, such as mischarged accounts and failed payments, before we did.
Rehearsal matters at every scale. When Commonwealth Bank of Australia moved its core banking platform to the cloud in 2025, it conducted five full dress rehearsals of the cutover, having originally planned for three. During the actual cutover, it kept customers online throughout the three hours the core was down.
Reconciling parallel outputs exposes discrepancies, and not every discrepancy is a defect in the new platform. Shadow running frequently uncovers latent bugs in the legacy system, such as rounding oddities, edge-case truncations or mishandled time zone changes, that went unnoticed because no independent system had ever checked the arithmetic. Classify each discrepancy as a new-system defect, an undocumented legacy defect or a deliberate change in method. New-system defects must be fixed. Legacy defects need an impact assessment, remediation and, where required, disclosure. Deliberate changes require approval from the business and, where applicable, the regulator. Working through that classification transparently earns the consensus needed to retire the legacy host.
Reconciling transactions does not prove that the migrated data is complete. Before retiring the legacy system, validate balances, record counts and relationships between records, and confirm that historical records and audit evidence remain retrievable, whether in the new system or in a validated archive.
Build the controls into the platform, not around it
Regulated migrations often treat security, resiliency and auditability as a compliance workstream that runs beside the technical one. That is how gaps appear at cutover. Build the required controls into the target platform before the first workload arrives: automated data residency enforcement, encryption with customer-managed keys where the data classification calls for them, continuous monitoring, immutable audit trails and granular identity and access management. Every migrated system then inherits these controls from the start, and each workload’s use of them is verified. Compliance is not a post-deployment audit; it is a primary design constraint that dictates the perimeter of the technical solution.
This matters doubly when the platform is intended to host AI. Models and agents will act on the data the migrated systems hold. Audit trails must be immutable and retrievable for years, and decisions that affect customers will need an explainability that many AI systems do not provide by default. If data lineage, access controls and the audit trail are not in place at migration, retrofitting them afterward is costly and often incomplete. Evidence that was never captured cannot be reconstructed, and the AI program will inherit a foundation that cannot withstand regulatory scrutiny.
Govern with standards the business can read
Enterprise architecture frameworks, such as TOGAF, provide the architecture team with a process; industry reference models, such as BIAN, give the business a vocabulary. The Banking Industry Architecture Network (BIAN) publishes a standard model that partitions a bank’s work into named business capabilities, such as payment execution or customer agreement, each with a standardized interface. When migrated services are mapped to that taxonomy rather than to legacy program names, a product owner or risk officer can read the migration plan, verify that a capability functions and sign off without needing to know what the old modules were called. The same artifacts, tied to test results and control evidence, can be presented to a regulator without translation. That shared language is what turns a migration from an IT project the business tolerates into a modernization the business owns.
What it takes
The five disciplines set out above hold whatever the technology: build a dependency map from observed system behavior; plan the cutover around the business calendar; prove correct transaction processing, through parallel running where feasible and through replay testing and rehearsed cutovers where it is not; establish platform controls before workloads arrive; and define governance in terms the business and its regulators understand.
None of these practices is new. What is rare is the resolve to keep to them when delivery schedules tighten. The organizations that modernize successfully are not those with the most sophisticated target architecture. They treat careful planning, respect for legacy knowledge and business continuity as engineering requirements rather than aspirations, refusing to sacrifice verification for speed.