Should a Financial Services Firm Move More Systems to the Cloud?

Moving more systems to the cloud can give a financial services firm greater flexibility, scalability, accessibility, and resilience. But those benefits do not make every workload a good candidate for migration.

The goal of cloud computing for financial services should not be to move as much technology as possible. The goal should be to place each workload in an environment that best supports the organization’s business requirements, client responsibilities, security needs, risk tolerance, and ability to recover from disruption.

For leadership, the better question is not simply, “Should we use more cloud services?”

It is: Which systems should move, which should not, and what conditions need to be satisfied before we approve a migration?

This framework can help answer that question.

Financial services organizations often depend on technology to handle sensitive information, maintain client-facing operations, communicate with customers, access financial applications, retain records, and work with a network of technology and business-service providers.

That makes a cloud decision more than an infrastructure decision.

For organizations subject to financial-sector regulation, changing where an application or its data is hosted does not automatically change the organization’s underlying obligations. FINRA, for example, advises broker-dealers considering cloud environments to evaluate areas such as cybersecurity, data governance, vendor management, business continuity, and recordkeeping.

It also makes clear that moving technology to a cloud provider does not relieve a member firm of applicable regulatory responsibilities.

The specific requirements depend on the organization. An independent insurance agency, investment adviser, broker-dealer, community financial institution, accounting-related firm, or other financial organization may operate under different legal, regulatory, contractual, and industry requirements.

That is why leadership should begin by identifying what actually applies to the organization and the workload under consideration not by assuming that one compliance framework covers the entire financial services industry.

The decision should also account for operational dependencies. A cloud platform may reduce dependence on equipment located in the office while increasing dependence on internet connectivity, cloud-provider availability, identity systems, integrations, or outside vendors.

The risk does not necessarily disappear. It changes shape.

A well-designed migration recognizes that change before a system is moved.

Cloud adoption should start with a business reason.

A financial services organization may benefit from moving an appropriate workload when cloud services provide a meaningful improvement in areas such as scalability, accessibility, resilience, infrastructure lifecycle management, or the ability to support changing business requirements.

FINRA has identified potential cloud benefits in the securities industry including agility, efficiency, resiliency, scalability, and the ability to support business continuity. At the same time, FINRA cautions firms to consider the operational and regulatory implications of migration rather than viewing those benefits in isolation.

For leadership, potential business value might include:

• Scalability: Resources can be adjusted as workloads, users, locations, or business requirements change.
• Accessibility: Appropriate cloud applications can make systems easier to access securely across offices or distributed teams.
• Resilience: Properly architected cloud environments may use redundant infrastructure or geographic distribution to reduce dependence on a single physical location.
• Infrastructure lifecycle management: Some cloud service models reduce the organization’s responsibility for maintaining physical servers or portions of the underlying platform.
• Operational flexibility: Organizations can adopt supported capabilities without necessarily building and maintaining equivalent infrastructure internally.

These benefits are not automatic.

Cloud does not inherently mean less expensive, more secure, or more reliable.

For example, a poorly configured cloud environment can introduce significant security risk. A cloud service with inadequate redundancy may not satisfy the organization’s availability requirements. Subscription, licensing, data-transfer, management, or integration costs can also change the financial case over time.

NIST guidance emphasizes that moving services to a public cloud does not eliminate the organization’s responsibility to oversee security, privacy, performance, and provider risk.

The business case therefore needs to answer a straightforward question:

What specifically becomes better if this workload moves?

If leadership cannot identify a meaningful improvement, migration may be solving a technology problem the organization does not actually have.

Moving a system to the cloud changes who performs certain technology functions, but it does not mean the cloud provider assumes every responsibility.

The division of responsibility depends on the service model, provider, contract, application, and architecture.

NIST describes cloud environments as involving different allocations of control and responsibility between the cloud consumer and cloud provider. Financial-sector guidance likewise emphasizes understanding that division clearly.

Before migration, leadership should evaluate three interconnected areas.

Start with identity.

Who will be able to access the system? How will accounts be authenticated? Who has administrative privileges? How are permissions reviewed? What happens when someone changes roles or leaves the organization?

These considerations should be evaluated alongside the organization’s broader cybersecurity controls for financial services, including identity, endpoint protection, monitoring, data protection, incident response, and recovery.

Important areas may include:

• multi-factor authentication
• least-privilege access
• privileged-account management
• user provisioning and termination
• secure configuration
• encryption
• logging and monitoring
• vulnerability management
• incident response

Organizations that need additional expertise evaluating, implementing, or managing these safeguards may also need broader IT security services supporting the cloud environment.

Security should also extend beyond the organization's own controls. If a cloud provider or other vendor can access sensitive information or critical systems, its controls become part of the organization's risk picture.

Before deciding where a workload should operate, determine what information it contains and what requirements apply to it.

Leadership may need to understand:

• the type and sensitivity of the information
• applicable privacy obligations
• regulatory requirements
• contractual obligations
• record-retention requirements
• audit or evidence requirements
• encryption requirements
• data-location considerations where applicable
• backup and recovery requirements

Moving information to a cloud environment does not by itself transfer compliance accountability to the provider.

For FINRA member firms, FINRA specifically states that outsourcing an activity to a cloud provider does not relieve the firm of its responsibility for compliance with applicable securities laws, regulations, and FINRA rules associated with that activity.

Other financial organizations may have different obligations. Applicability should be determined before a migration strategy is approved.

A cloud migration may also create a deeper dependency on an outside provider.

That makes vendor risk an operational issue, not simply a procurement issue. FINRA's 2026 Annual Regulatory Oversight Report notes an increase in reported cyberattacks and outages involving firms' third-party vendors.

Its effective practices for member firms include initial and ongoing due diligence, inventories of vendor services and data, outage-impact assessments, contingency planning, monitoring, contract controls, termination procedures, and evaluation of fourth-party risk.

Relevant questions include:

• What services does the vendor provide?
• What data can it access?
• What happens if the service is unavailable?
• How are incidents communicated?
• What does the contract require?
• Can the organization's data be exported?
• What happens when the relationship ends?
• Are other providers involved behind the primary vendor?
• How difficult would it be to change providers?

Cloud provider selection should therefore include an exit strategy, not just an implementation strategy.

There is no universal list of financial systems that should move to the cloud. A better approach is to evaluate each workload against consistent business and risk criteria.

Leadership should consider:

1. Business purpose: What does the system enable?
2. Business criticality: What happens if it is unavailable?
3. Data sensitivity: What information does it store, process, or transmit?
4. Applicable requirements: Which regulatory, contractual, privacy, or retention obligations apply?
5. Identity and access: Who needs access, and how should access be controlled?
6. Integration dependencies: Which other systems, vendors, or workflows depend on it?
7. Availability requirements: How much interruption can the organization tolerate?
8. Recovery requirements: How quickly must service and data be restored?
9. Performance and latency: Does the workload have time-sensitive or location-sensitive requirements?
10. Connectivity dependencies: What happens during an internet or carrier outage?
11. Application support: Does the software vendor support the proposed architecture?
12. Scalability: Will demand change enough to make flexible resources valuable?
13. Migration complexity: How difficult will the transition be?
14. Migration risk: What can go wrong during the move?
15. Lifecycle cost: What will the environment cost to migrate, operate, secure, support, and eventually replace?
16. Ongoing ownership: Who is responsible after the migration is finished?

A practical workload review can look like this:

The purpose of this framework is not to produce a mechanical score. It is to force the right questions before the organization makes an architectural commitment. Two systems inside the same financial firm can legitimately reach different conclusions.

Once leadership determines that a workload is a reasonable candidate, detailed cloud migration planning can address sequencing, dependencies, testing, risk, and implementation.

Not moving a workload can be a valid technology strategy.

Some systems may remain better suited to an on-premises or hybrid environment because the risks or constraints of migration currently outweigh the benefit.

That may be the case when:

• a legacy application is not adequately supported in the proposed cloud environment
• specialized hardware must communicate directly with the system
• integrations create excessive complexity or migration risk
• latency requirements make the proposed architecture impractical
• contractual or regulatory considerations affect deployment options
• connectivity or redundancy is inadequate
• the migration would create unacceptable downtime or business disruption
• the target environment cannot meet recovery requirements
• licensing or lifecycle economics do not support the move
• the organization is not operationally prepared to manage the new environment

Organizations evaluating the broader differences between cloud vs. on-premises infrastructure can also consider factors such as ownership, control, scalability, cost, security responsibility, and ongoing management.

Hybrid cloud architecture can also be an intentional choice rather than a compromise.

A firm might retain a specialized application locally while moving other workloads to cloud platforms. It might maintain local capabilities for operational reasons while using cloud resources for specific business functions, resilience, or scalability.

The architecture should follow the requirement, not the trend.

Cloud, on-premises, and hybrid are all legitimate options when they are deliberately matched to the workload.

A migration should not be approved solely because the technology works.

Leadership should understand the business case, the risk, and what the organization will be responsible for after implementation.

Before authorizing a move, ask:

• Why are we moving this workload?
• What business result should improve?
• What data does the system store, process, or transmit?
• Which legal, regulatory, contractual, or internal requirements apply?
• Have security responsibilities been clearly assigned?
• What remains our responsibility?
• What belongs to the provider?
• Are integrations documented and understood?
• What happens if the provider experiences an outage?
• What happens if our internet connectivity fails?
• What availability level does the business require?
• What backup and recovery capabilities are required?
• Have recovery procedures been tested or planned?
• What is the full lifecycle cost?
• Has third-party risk been evaluated?
• Is there a documented migration plan?
• Is there a rollback or contingency plan?
• Who owns the environment after migration?
• How will security, compliance, cost, and performance be reviewed afterward?
• What happens if we need to change providers?

Workloads with strict availability requirements should also have clearly defined backup and recovery requirements, including acceptable data loss, recovery time, monitoring, and restoration testing.

Leadership should also understand the most common cloud migration challenges before approving the project, including application compatibility, integration dependencies, downtime, security changes, testing, rollback requirements, and unexpected costs.

The last question is particularly easy to overlook.

A cloud environment may be technically successful while still creating excessive vendor dependency. FINRA's cloud guidance specifically identifies vendor lock-in and exit planning as issues firms may need to consider, while its current third-party-risk guidance emphasizes procedures for data return or destruction and termination of vendor access when a relationship ends.

A good migration therefore includes not only a plan for getting into the target environment, but also a plan for operating it, recovering it, and eventually changing it if business requirements change.

The final decision should come back to one principle:

Move a workload when the expected business and operational benefits justify the migration and ongoing risks and when the organization can demonstrate that the target environment meets its security, compliance, integration, availability, recovery, and governance requirements.

Before accepting a recommendation, leadership should also ask its IT or cloud provider:

• Why should this workload move?
• What should remain where it is?
• Which risks will change after migration?
• Who owns each security responsibility?
• How will applicable compliance requirements be addressed?
• How will data and systems be backed up and recovered?
• What is the migration plan?
• What is the rollback strategy?
• What happens during an outage?
• What ongoing management is required?
• How would we move away from the provider later?

A recommendation should be able to withstand those questions.

The most valuable cloud strategy may not be “move more.”

It may be move the right things, for the right reasons, in the right sequence.

Once leadership has identified workloads that may benefit from migration, the next step is to evaluate the organization's actual applications, infrastructure, data, integrations, security controls, compliance considerations, recovery requirements, and vendor dependencies.

That review may confirm that a workload belongs in the cloud. It may identify controls that should be strengthened before migration. It may support a hybrid architecture. In some cases, it may confirm that the existing environment should remain in place for now.

That is the value of beginning with the decision rather than the destination.

thirtyone3 technology helps organizations evaluate current systems, cloud opportunities, security and compliance considerations, migration risks, and practical next steps without assuming that every workload belongs in the cloud.