Complete Cloud Migration Guide for Enterprises: Strategy, Costs, and Roadmap

Most enterprise cloud migrations in LATAM are not failing because the technology is hard. They are failing because the business case, the operating model, and the FinOps discipline were treated as a phase 2 problem. By the time the CFO sees the first full quarter of cloud bills, the project has already lost executive sponsorship.

If you are a CTO, CIO, or IT Director evaluating a migration in 2026, the question is no longer whether to move. It is how to sequence 200–2,000 workloads, which of the 6R strategies applies to each, what your real total cost of ownership will be after month 18, and how to avoid becoming the next [VERIFY: percentage of cloud migrations that exceed budget or timeline, McKinsey or Gartner 2025] case study of a stalled migration.

This guide is the playbook we use at Nivelics across [VERIFY: number of completed cloud migrations led by Nivelics, internal data] enterprise migrations to AWS, GCP, and Azure. It covers the decision framework, provider trade-offs, a realistic 12–18 month roadmap, cost estimates by workload size, and the readiness checklist we run before signing any statement of work.

Why migrate to the cloud in 2026?

The conversation has shifted. Five years ago, cloud was about elasticity and cost. In 2026, the gating factor for most enterprises is access to AI services, managed data platforms, and global compliance tooling that simply do not exist on-premises at a competitive price.

Business drivers: CapEx → OpEx, scalability, time-to-market

Moving from a CapEx model (3–5 year hardware refresh cycles, depreciation, data center contracts) to an OpEx model frees working capital and aligns IT spend with revenue. For a mid-size enterprise running ~$2M/year in on-prem infrastructure, this typically translates into a [VERIFY: average client savings after FinOps optimization, Nivelics internal benchmark] reduction in run-rate after month 12, once right-sizing and reserved capacity are in place.

Time-to-market is the second driver. Provisioning a new environment on-prem still takes 6–12 weeks in most LATAM enterprises. On AWS or GCP, with a proper landing zone, it takes hours. For product organizations shipping weekly, that gap is the difference between leading a category and reacting to it.

Scalability matters less for steady-state workloads and much more for seasonal businesses (retail, fintech, logistics) where peak-to-average ratios exceed 5x. Paying for peak capacity 365 days a year is no longer defensible to a board.

Technical drivers: disaster recovery, observability, native AI/ML

Disaster recovery on-premises requires a second data center, replication licenses, and a team to test it. In the cloud, multi-region DR with RPO under 15 minutes is a configuration, not a project. For regulated industries (banking, healthcare, insurance), this alone justifies migration.

Observability has matured. Native services like CloudWatch, Cloud Operations Suite, and Azure Monitor — combined with OpenTelemetry — give you traces, logs, and metrics across hundreds of services without standing up your own observability stack.

AI and ML are the new gravity well. Bedrock, Vertex AI, and Azure OpenAI Service are not portable. If your 2026–2027 roadmap includes generative AI, agents, or large-scale ML, the cloud is no longer optional. See our deep dive on GCP vs AWS for data and AI workloads.

Why LATAM can no longer postpone the decision

Cloud adoption in LATAM enterprises reached [VERIFY: cloud adoption rate in LATAM enterprises 2025–2026, Forrester or Gartner] in 2025, with banking, retail, and logistics leading. The competitive cost is now visible: enterprises still on-prem are paying 30–50% more per transaction than cloud-native competitors, and they cannot ship AI features at the same cadence.

For LATAM subsidiaries of US multinationals, the corporate mandate is usually clear: align with the parent's cloud standard within 18–24 months. The local CIO's job is to execute without disrupting operations. That is the focus of this guide.

The 6 migration strategies (AWS 6 R's)

The AWS 6 R's framework — Rehost, Replatform, Refactor, Repurchase, Retain, Retire — is the standard taxonomy used across the industry. Every workload in your portfolio should be classified into one of these six categories during the assessment phase. Mixing strategies is normal; pure lift-and-shift programs almost always disappoint.

Rehost (lift and shift)

Move the workload as-is to EC2, Compute Engine, or Azure VMs. No code changes, minimal architecture changes. Fast, low risk, but you inherit all the inefficiencies of the on-prem design.

When to use it: end-of-life data center deadline, workloads with no business case for re-architecture, third-party software with vendor lock on a specific OS. Expect 10–20% cost reduction at best, often 0% before optimization.

Replatform (lift, tinker, shift)

Move with targeted changes: swap self-managed databases for RDS/Cloud SQL, containerize a monolith without refactoring it, replace the load balancer. Higher savings (typically 25–40%) with manageable risk.

When to use it: most stateful workloads, especially databases and middleware. This is the sweet spot for the majority of enterprise portfolios.

Refactor (re-architecting)

Rebuild the workload as cloud-native: serverless, microservices, managed event streams. Highest cost and longest timeline, but unlocks elasticity, AI integration, and the lowest run-rate.

When to use it: revenue-generating products, core platforms, anything with a 5+ year roadmap. Do not refactor commodity systems.

Repurchase (move to SaaS)

Replace the workload with a SaaS equivalent: ERP to NetSuite, CRM to Salesforce, HRIS to Workday, ticketing to ServiceNow. Often the cheapest TCO over five years.

When to use it: undifferentiated business systems where customization adds no competitive advantage.

Retain (keep on-prem)

Leave the workload where it is. Common for mainframe systems with 3–5 year decommissioning plans, or workloads with strict data residency requirements not yet met by local cloud regions.

When to use it: regulatory blockers, recently refreshed hardware, or workloads scheduled for retirement within 24 months.

Retire (decommission)

The assessment will surface 10–25% of workloads that are no longer used or can be consolidated. Turning them off is the highest-ROI action of the entire program.

When to use it: always run this analysis first. Every workload retired is one less to migrate.

Provider: AWS vs GCP vs Azure

There is no universally correct answer. The right provider depends on your workload mix, existing licensing, talent availability, and industry. Most large LATAM enterprises end up multi-cloud by year three, but they should not start multi-cloud.

Technical criteria

Criterion	AWS	GCP	Azure
Service breadth	Widest (200+ services)	Focused, strong in data/AI	Broad, deep Microsoft integration
Data & analytics	Redshift, Athena, EMR	BigQuery (best-in-class)	Synapse, Fabric
AI/ML	Bedrock, SageMaker	Vertex AI, Gemini	Azure OpenAI Service
Kubernetes	EKS (mature)	GKE (origin of K8s)	AKS (solid)
Networking	Most mature	Global VPC by default	Strong hybrid (ExpressRoute)
LATAM regions	São Paulo, others	São Paulo, Santiago	São Paulo, Mexico

For a deeper comparison, see our analysis of AWS vs GCP for enterprise workloads.

Ecosystem and talent availability in LATAM

AWS has the largest certified talent pool in LATAM by a wide margin. Hiring AWS-certified engineers in Bogotá, Mexico City, or São Paulo is materially easier than hiring equivalent GCP or Azure talent. This affects both salary and time-to-hire.

Azure benefits from existing Microsoft enterprise relationships (EA agreements, Active Directory, Microsoft 365). If your organization is deeply Microsoft-aligned, the friction to adopt Azure is lower.

GCP is strongest where data is the product: ad-tech, retail analytics, ML-heavy platforms. The talent pool is smaller but highly specialized.

Cost and billing criteria

List prices for compute and storage are within 5–10% across the three providers for equivalent SKUs [VERIFY: reference pricing for typical workloads on AWS/GCP/Azure 2025–2026]. The real cost differences come from:

Egress fees: historically high across all three; GCP and AWS have reduced egress for customers leaving, but inter-region and internet egress remain a major cost lever.
Reserved/committed use discounts: 30–55% savings with 1–3 year commitments.
Licensing: Windows Server and SQL Server are materially cheaper on Azure if you have existing Software Assurance.

Our full breakdown on cost optimization lives in FinOps on AWS: optimization playbook.

Recommendation by industry

Banking & fintech: AWS (regulatory maturity, breadth) or Azure (if Microsoft-heavy).
Retail & e-commerce: GCP (BigQuery, recommendations AI) or AWS.
Healthcare: Azure (compliance tooling, Microsoft integration) or AWS.
Manufacturing & logistics: AWS (IoT services, breadth).
Media & ad-tech: GCP (data and ML).

Phases of a successful migration (12–18 months)

A realistic enterprise migration is 12–18 months end-to-end. Anyone promising less for a portfolio of 100+ workloads is either underestimating scope or planning a pure lift-and-shift that will need a second migration in 24 months.

Phase 1 (months 0–2): Assessment and discovery

Inventory every workload, dependency, and data flow. Use tooling (AWS Migration Evaluator, Azure Migrate, StratoZone) plus interviews. Output: a portfolio classified by 6 R's, a business case with TCO and ROI, and a wave plan.

This is also where you identify the 10–25% of workloads to retire. Skipping or rushing this phase is the most common cause of failed migrations.

Phase 2 (months 2–4): Landing zone, governance, IAM

Build the foundation: multi-account/multi-subscription structure, network topology (transit gateway, VPC design), identity federation, logging and security baseline, tagging strategy, and FinOps tooling. AWS Control Tower, Azure Landing Zones, and GCP Cloud Foundation accelerate this. See our cloud infrastructure services for reference architectures.

Governance decisions made here are expensive to undo later. Invest the time.

Phase 3 (months 4–10): Migration by waves

Move workloads in waves of 10–30, grouped by dependency and risk. Start with low-risk, low-dependency workloads (dev/test, internal tools) to build team confidence and refine the runbook. Production-critical workloads come in waves 3–5.

Each wave follows the same pattern: cutover plan, rehearsal, migration window, validation, hypercare. Document everything; the wave 7 team will not be the wave 1 team.

Phase 4 (months 10–14): Optimization and FinOps

This is where the savings are realized. Right-size instances based on actual utilization, apply reserved instances and savings plans, eliminate orphaned resources, tune storage tiers, and implement automated shutdown for non-production environments.

Without this phase, your cloud bill will be 30–60% higher than it should be. Forever.

Phase 5 (months 14+): Cloud-native transformation

The migration is done; the transformation begins. Refactor selected workloads to serverless, adopt managed AI services, implement platform engineering, and shift to GitOps. This phase has no end date — it is the new operating model.

Real migration costs

Migration costs split into three categories: one-time migration cost, ongoing run cost, and opportunity cost (delays, productivity loss). The one-time cost is what gets approved; the run cost is what gets debated for the next five years.

Estimate by workload size

Workload size	Description	One-time migration cost (USD)	Timeline
Small	Stateless app, single DB, <10 servers	$15K–$50K	4–8 weeks
Medium	Multi-tier app, 10–50 servers, integrations	$80K–$250K	3–6 months
Large	Core platform, 50+ servers, complex data	$300K–$1.5M+	6–12 months

These are reference ranges based on Nivelics engagements; your numbers will vary based on complexity, talent model, and provider.

The trap: hidden costs (egress, licensing, training)

The most common surprises in month 6:

Egress charges: data leaving the cloud (to on-prem, to users, between regions) at $0.05–$0.12/GB adds up fast for data-heavy applications.
Licensing: bringing your own Oracle, SQL Server, or SAP licenses requires careful BYOL planning. Cloud-vendor SQL editions can double your database cost.
Training and certification: budget $3K–$8K per engineer for certification and ramp-up.
Third-party tools: monitoring, backup, security tools often require new SKUs or licenses for cloud.
Parallel running: during migration, you pay for both on-prem and cloud. Plan for 3–6 months of overlap per workload.

FinOps from day one

FinOps is not a phase 4 activity. It is a discipline that starts in phase 1 with tagging strategy, budget alerts, and showback/chargeback design. Enterprises that wait until after migration to implement FinOps overspend by an average of [VERIFY: average overspend for organizations without day-one FinOps, FinOps Foundation State of FinOps 2025] in year one.

Our FinOps service embeds a FinOps practitioner from week one of the program. It pays for itself within the first quarter.

Common mistakes (lessons from real projects)

After dozens of enterprise migrations, the same mistakes recur. Here are the seven most expensive ones and how to avoid them.

Skipping the assessment. Teams jump to execution to show progress. Result: surprise dependencies surface in wave 4, and the timeline doubles. Fix: spend the full 8 weeks on assessment, even if leadership pressures you to start.
Lift-and-shifting everything. It feels safe and fast. It is neither — you end up paying cloud prices for on-prem architecture. Fix: apply the 6 R's rigorously; refactor at minimum your top 20% revenue-driving workloads.
No FinOps until month 12. The first quarterly bill triggers a panic, executives lose confidence, and budgets are cut mid-program. Fix: implement tagging, budgets, and anomaly detection before the first workload moves.
Underinvesting in the landing zone. A weak foundation forces rework later. We have seen enterprises rebuild their account structure 18 months in. Fix: treat the landing zone as a product, not a checklist.
Ignoring the operating model. The cloud requires different roles (platform engineers, SREs, FinOps practitioners) and different processes (GitOps, IaC). Migrating workloads without evolving the team produces an expensive on-prem-in-the-cloud. Fix: run the org transformation in parallel.
Picking the provider for the wrong reasons. Choosing based on a single executive's preference or a one-time discount, instead of workload fit and talent availability. Fix: run a structured evaluation with weighted criteria.
No executive sponsor with budget authority. Migration programs that report to an IT director without CFO alignment stall the moment the bill arrives. Fix: secure a C-level sponsor and a multi-year budget envelope before kickoff.

For a worked example of how we navigated these in a real engagement, see our cloud migration case study and our enterprise AWS migration guide.

Cloud readiness checklist

Before you commit to a migration program, validate that your organization is ready across six dimensions. We use this checklist in every assessment.

Strategy & sponsorship

C-level sponsor identified with multi-year budget authority
Business case approved with TCO, ROI, and risk register
Target operating model defined (centralized, federated, or hybrid)

Portfolio

Workload inventory complete (apps, databases, integrations, data flows)
6 R's classification done for every workload
Wave plan with sequencing and dependencies

Provider & architecture

Provider selected with documented criteria
Landing zone design approved (accounts, network, IAM, security)
Reference architectures for top workload patterns

Team & skills

Skills gap analysis completed
Training and certification plan in place
Staff augmentation or partner engaged for peak phases

FinOps & governance

Tagging strategy defined and enforced
Budgets, alerts, and anomaly detection configured
Showback or chargeback model agreed with finance

Security & compliance

Compliance requirements mapped (data residency, sector-specific)
Security baseline defined (encryption, IAM, logging, monitoring)
Incident response runbook adapted for cloud

If you check fewer than 14 of these 18 boxes, you are not ready to start migration waves. You are ready to start the assessment phase. Our cloud services team can run a structured readiness review in two weeks.

Next step

If you are evaluating a migration in the next 6–12 months, the highest-ROI action you can take this quarter is a structured assessment. We will inventory your workloads, classify them by the 6 R's, model TCO across AWS, GCP, and Azure, and deliver a wave plan you can take to your board.

Book a free cloud migration assessment (2 weeks) — or learn more about our AWS migration service.

Frequently asked questions

How long does an enterprise cloud migration take?

For a portfolio of 50–200 workloads, expect 12–18 months end-to-end: 2 months of assessment, 2 months of landing zone, 6 months of migration waves, and 4–6 months of optimization. Faster timelines usually mean lift-and-shift only, which defers the real work.

What is the average cost of migrating to the cloud?

One-time migration costs typically run $1,500–$8,000 per workload depending on complexity. A mid-size enterprise (100 workloads) should budget $300K–$1.2M for the migration itself, plus parallel run costs and training. Run-cost savings of 25–40% are realistic after FinOps optimization.

Should I choose AWS, GCP, or Azure?

AWS for breadth and LATAM talent availability, Azure for Microsoft-heavy environments, GCP for data and AI-centric workloads. Most enterprises end up multi-cloud by year three, but starting on a single provider reduces complexity and accelerates the program.

Lift and shift or refactor — which is better?

Neither, in isolation. Apply the 6 R's framework: lift-and-shift for end-of-life pressure and commodity workloads, replatform for the bulk of stateful systems, refactor for revenue-driving products with a 5+ year roadmap. A mixed strategy almost always outperforms a pure approach.

When should I implement FinOps?

From day one. Tagging strategy, budget alerts, and anomaly detection must be in place before the first workload moves. Organizations that defer FinOps to post-migration consistently overspend by 30–60% in the first year.

Do I need a partner for cloud migration?

For portfolios over 30 workloads, yes — at minimum for the assessment, landing zone, and the first two waves. Internal teams can take over once the runbook is proven and skills are transferred. The expensive mistake is hiring a generalist consulting firm without deep cloud and FinOps practice.