How Financial Institutions Can Build Cloud Operational Readiness in 90 Days

In my previous post, The Hidden Cost of Unpreparedness, I described the challenge facing a financial services company migrating 180+ servers without the operational foundation to succeed. The risks are real: cost overruns, security gaps, compliance failures, and burned-out teams.

But here’s the question I keep hearing: “If we need to build this foundation, how long will it take? We’re under pressure to move now.”

The good news: you don’t need years. You don’t even need six months.

From my experience working with banks, fintechs, and insurance companies across Latin America, I’ve seen organizations establish cloud operational readiness in 90 days,enough to migrate confidently and operate sustainably.

This isn’t about perfection. It’s about building the minimum viable foundation that allows you to move fast without breaking things. And in financial services, where regulatory scrutiny is high and downtime is costly, that foundation is non-negotiable.

Let me walk you through how to do it.

Why 90 Days?

Ninety days is long enough to establish real capability, but short enough to maintain momentum and executive support.

It’s also a timeframe that aligns with how financial institutions operate: quarterly planning cycles, audit windows, and board reporting rhythms.

But let me be clear: this isn’t about rushing. It’s about being deliberate and focused. You’re not building everything,you’re building what matters most to operate the cloud safely and effectively.

The framework I’m sharing comes from real projects. It’s been tested in regional banks, multinational financial groups, and fast-growing fintechs. The context varies, but the pattern holds. In any case this approach requires real commitment, not unclear intentions.

The 90-Day Framework

The framework is structured in three 30-day sprints, each with a clear outcome. Think of it as building in layers: foundation, validation, and scale.

Sprint 1 (Days 1-30): Establish the Foundation

Goal: Define standards, build core capabilities, and align teams.

This sprint is about creating the scaffolding that everything else will build on. You’re not migrating workloads yet, you’re preparing to migrate well.

Week 1: Define Cloud Governance Framework

Start with governance. As I wrote in The Silent Power of Cloud Governance, governance is freedom through structure. Without it, cloud adoption becomes chaos.

Key activities:

• Define account structure (multi-account strategy for dev, test, prod).
• Establish identity and access management (IAM) policies based on least privilege.
• Set up cost allocation tags and budget alerts.
• Define security baselines (encryption, logging, network segmentation).
• Document approval workflows for exceptions.

Outcome: A governance playbook that answers: Who owns what? Who can change it? How are costs tracked? What security policies apply?

Pro tip: Don’t aim for perfection. Start with a lightweight framework and iterate. The goal is clarity, not bureaucracy.

Week 2: Build Infrastructure as Code (IaC) Templates

IaC is the backbone of cloud operations. Every resource: networks, compute, storage, security groups, should be defined in code, versioned, and repeatable.

Key activities:

• Choose an IaC tool (Terraform, AWS CloudFormation, Azure ARM, Biceps or similar).
• Build templates for common patterns: VPCs, subnets, security groups, compute instances, databases.
• Establish naming conventions and tagging standards.
• Store templates in version control (Git).

Outcome: A library of reusable IaC templates that enforce governance policies by default.

Pro tip: Start with one reference architecture, a standard three-tier application stack. Prove it works, then expand.

Week 3: Establish CI/CD Pipelines

Automation is what separates cloud operations from traditional IT. CI/CD pipelines allow you to deploy infrastructure and applications consistently, with testing and security checks built in.

Key activities:

• Set up a CI/CD platform (GitLab, GitHub Actions, Jenkins, AWS CodePipeline, Azure DevOps or similar).
• Build a pipeline for IaC deployment: code review → automated testing → deployment to dev → approval gate → deployment to prod.
• Integrate security scanning (static analysis, vulnerability checks).
• Document the deployment process.

Outcome: A working pipeline that deploys infrastructure from code, with automated validation and approval gates.

Pro tip: Keep it simple. A basic pipeline that works is better than a complex one that doesn’t.

Week 4: Train and Align Teams

Technology without people is just expensive infrastructure. This week is about upskilling teams and aligning them around the new operational model.

Key activities:

• Conduct workshops on IaC, CI/CD, and cloud governance.
• Assign roles and responsibilities (who owns what in the new model).
• Establish communication channels (Slack, Teams, or similar for cross-functional collaboration).
• Create a shared roadmap linking business goals to technical milestones (as I discussed in Bridging Strategy and Execution).

Outcome: Teams understand the new operational model and their role in it. Resistance turns into engagement.

Pro tip: Don’t underestimate cultural change. Invest time in explaining the “why,” not just the “how.”

Sprint 2 (Days 31-60): Validate with a Pilot

Goal: Prove the operational model works by migrating a real workload.

This sprint is where theory meets reality. You’re testing your IaC templates, CI/CD pipelines, and governance policies with a live workload.

Week 5: Select and Prepare the Pilot Workload

Choose a workload that’s meaningful but not mission-critical. You want something real enough to surface issues, but low-risk enough that failure won’t cause a crisis.

Key activities:

• Select a pilot application (ideally a three-tier web app with a database).
• Document current architecture and dependencies.
• Define success criteria: uptime, performance, cost, security posture.

Outcome: A pilot workload selected and documented, with clear success metrics.

Pro tip: Avoid the temptation to pick the easiest workload. Pick one that’s representative of what you’ll migrate at scale.

Week 6: Migrate the Pilot Using IaC and CI/CD

This is the moment of truth. Deploy the pilot workload using the IaC templates and CI/CD pipelines you built in Sprint 1.

Key activities:

• Provision infrastructure using IaC.
• Deploy the application through the CI/CD pipeline.
• Configure monitoring and logging.
• Validate security controls (encryption, access policies, network segmentation).

Outcome: The pilot workload is running in the cloud, deployed entirely through code and automation.

Pro tip: Expect issues. That’s the point. Document every problem and how you solved it.

Week 7: Operate and Optimize the Pilot

Now that the pilot is live, operate it as you would a production workload. This week is about validating that your operational model scales beyond deployment.

Key activities:

• Monitor performance, availability, and costs.
• Test incident response procedures.
• Optimize resource sizing based on actual usage.
• Validate compliance with governance policies.

Outcome: Confidence that the operational model works in practice, not just in theory.

Pro tip: Involve operations teams early. Their feedback is critical for refining runbooks and automation.

Week 8: Retrospective and Refinement

Pause and reflect. What worked? What didn’t? What needs to change before scaling?

Key activities:

• Conduct a retrospective with all teams involved.
• Document lessons learned.
• Update IaC templates, pipelines, and governance policies based on feedback.
• Refine the migration playbook.

Outcome: A validated, refined operational model ready to scale.

Pro tip: Celebrate the wins. Pilots are hard work, and teams need to see that their effort mattered.

Sprint 3 (Days 61-90): Scale and Operationalize

Goal: Prepare to scale the migration and embed operational excellence.

This sprint is about taking what you learned from the pilot and making it repeatable, sustainable, and scalable.

Week 9: Expand IaC and Automation

Based on lessons from the pilot, expand your IaC library and automation capabilities.

Key activities:

• Build additional IaC templates for other workload types (batch processing, data pipelines, etc.).
• Automate operational tasks: backups, patching, scaling policies.
• Integrate monitoring and alerting into the CI/CD pipeline.

Outcome: A comprehensive IaC library and automation framework ready for scale.

Pro tip: Prioritize automation for repetitive, error-prone tasks. That’s where you’ll see the biggest ROI.

Week 10: Establish Operations as Code

Operations as Code extends IaC to operational procedures: incident response, scaling policies, disaster recovery.

Key activities:

• Codify runbooks for common operational tasks.
• Automate incident detection and response (auto-scaling, self-healing).
• Define disaster recovery procedures and test them.

Outcome: Operational resilience built into the platform, not dependent on heroics.

Pro tip: Start with the most common incidents. Automate those first.

Week 11: Strengthen Cloud Governance

With the pilot validated, strengthen governance to prepare for scale.

Key activities:

• Implement automated policy enforcement (AWS Config, Azure Policy, or similar).
• Set up continuous compliance monitoring.
• Establish cost optimization practices (rightsizing, reserved instances, spot instances).
• Create dashboards for visibility into costs, security, and compliance.

Outcome: Governance that scales without adding manual overhead.

Pro tip: Make governance visible. Dashboards and alerts keep teams accountable without micromanagement.

Week 12: Prepare for Scale

The final week is about readiness: ensuring teams, processes, and technology are aligned for the full migration.

Key activities:

• Finalize the migration roadmap (which workloads, in what order).
• Conduct a readiness review with leadership.
• Establish feedback loops for continuous improvement (as I discussed in Bridging Strategy and Execution).
• Communicate the plan to the broader organization.

Outcome: A clear, confident path forward for scaling the migration.

Pro tip: Don’t wait for perfection. If you’ve validated the model with a pilot, you’re ready to scale.

What Success Looks Like After 90 Days

At the end of 90 days, you won’t have migrated all 130 servers. But you’ll have something more valuable: operational readiness.

Here’s what that looks like:

• Governance in place: Clear policies, automated enforcement, and cost visibility.
• IaC and CI/CD working: Infrastructure deployed from code, with automated testing and security checks.
• Pilot validated: A real workload running in the cloud, proving the model works.
• Teams aligned: Roles defined, skills developed, and cultural resistance addressed.
• Operational resilience: Monitoring, incident response, and disaster recovery procedures tested and automated.

You’re not done. But you’re ready to scale confidently.

Why This Works in Financial Services

Financial institutions face unique constraints: regulatory scrutiny, risk aversion, legacy systems, and complex approval processes. The 90-day framework accounts for these realities.

Regulatory compliance: By embedding governance and security from day one, you’re building compliance into the foundation, not retrofitting it later.

Risk management: The pilot approach allows you to validate the model with low-risk workloads before touching mission-critical systems.

Cultural change: Ninety days is enough time to shift mindsets without losing momentum. Teams see results quickly, which builds confidence.

Executive alignment: Quarterly cycles align with how financial institutions plan and report. A 90-day sprint fits naturally into existing rhythms.

Common Pitfalls to Avoid

Even with a clear framework, I’ve seen organizations stumble. Here are the most common pitfalls:

1. Skipping governance. Teams rush to build IaC and CI/CD without defining policies. Result: automation that scales chaos.

2. Choosing the wrong pilot. Picking a workload that’s too simple (doesn’t surface real issues) or too complex (too risky). Pick something representative.

3. Underinvesting in training. Technology is easy. People are hard. If teams don’t understand the “why,” they’ll resist the “how.”

4. Treating the pilot as a one-off. The pilot isn’t a science experiment, it’s a rehearsal for scale. Treat it seriously.

5. Ignoring feedback loops. As I wrote in Bridging Strategy and Execution, strategy and execution must co-evolve. Build feedback loops from day one.

Real-World Example: A Regional Bank

Let me share a real case. A regional bank in Latin America was under pressure to migrate to the cloud within a year. They had 90+ applications, minimal cloud experience, and a risk-averse culture.

We implemented the 90-day framework:

• Sprint 1: Defined governance, built IaC templates, established CI/CD pipelines, trained teams.
• Sprint 2: Migrated a customer-facing web application as a pilot. Validated the model. Refined based on lessons learned.
• Sprint 3: Expanded automation, strengthened governance, prepared the migration roadmap.

After 90 days, they hadn’t migrated everything. But they had:

• Reduced deployment time from weeks to hours.
• Established automated compliance monitoring.
• Built confidence across technical and leadership teams.
• Created a repeatable playbook for scaling the migration.

Over the next nine months, they migrated 80% of their workloads: on time, under budget, with zero critical security incidents.

The difference wasn’t technical capability. It was preparation.

Final Thoughts

Cloud migration without operational readiness is a gamble. You might get lucky, but the odds aren’t in your favor.

The 90-day framework isn’t about perfection. It’s about building the minimum viable foundation that allows you to migrate confidently, operate sustainably, and deliver the business value that cloud promises.

For financial institutions, where risk is high and trust is everything, that foundation isn’t optional. It’s the difference between transformation and chaos.

As I wrote in From Buzzwords to Business Value, cloud is not a destination. It’s the foundation for continuous transformation.

And transformation starts with readiness.

Ricardo