Migration Pathways — Where Should Each Workload Actually Land

"Migrate to the cloud" is the answer everyone reaches for and no auditable plan can accept.

Part 1 of this series made the case for treating the 2012 and 2016 EOL dates as a single 15-month remediation window. Now the harder question: where does each workload actually land?

The starting state at most mid-tier CUs

•Physical: legacy line-of-business apps, appliance-tied workloads, older AML systems

•Virtual on-prem: the bulk — Active Directory, file servers, SQL, IIS, reporting stacks

•Private cloud: newer hosted-application workloads (Celero, Central 1 API endpoints)

The target state isn't "public cloud for everything"

It's a portfolio decision made once per workload [source] class:

•Physical → retire or replace. If a workload is still on physical hardware in 2026, the modernization opportunity is often elimination, not migration. Refresh what's needed; retire what isn't.

•Virtual on-prem → modernized virtual estate or public cloud IaaS. Choice depends on regulatory-scope proximity and residual on-prem investment. Newer estates go public; existing investment goes modernized.

•Private cloud → evaluate for public cloud managed services. Where a hosted app has a SaaS equivalent, the compound cost usually favors SaaS. Where it doesn't, private cloud is often the right answer.

The regulatory framing

FSRA doesn't specify deployment topology. It specifies control effectiveness. Public cloud with weak controls is worse than on-prem with strong ones. The wrong migration is worse than a delayed one.

This portfolio logic applies to any regulated FI. Credit unions have a specific advantage: the core is already hosted, which reduces the surface of workloads that need to move.

Ask your CIO to categorize every Server 2016 host into one of four target states — retire, modernized virtual, private cloud, public cloud — with rationale. That's the migration plan. A spreadsheet of dates isn't.

Part 2 of 3. Next: what to do if the server can't move in time.