Cloud for enterprise applications in Spain: migration and architecture guide

AWS, Azure, or Google Cloud: what to choose for a mid-sized Spanish company

• AWS (Amazon Web Services): the largest and most mature of the three. Best managed services ecosystem (RDS, S3, Lambda, ECS), most extensive documentation, and largest community of certified professionals in Spain. First choice for new applications without a pre-existing Microsoft dependency.
• Microsoft Azure: mandatory if the company already uses Office 365 / Microsoft 365, Active Directory, or has SQL Server or Windows Server licences with Software Assurance (Azure Hybrid Benefit saves up to 40% on licences). Best Microsoft ecosystem integration, critical for mid-sized Spanish companies with legacy Microsoft infrastructure.
• Google Cloud Platform (GCP): competitive advantage in data and machine learning workloads (BigQuery, Vertex AI). Valid option for companies with strong analytics or AI needs. Fewer certified partners in Spain than AWS or Azure.
• Multi-cloud and hybrid cloud: most mid-sized Spanish companies end up with a hybrid model (part on-premise, part cloud). The key is designing the connectivity architecture (VPN, ExpressRoute, Direct Connect) from the start to avoid latency bottlenecks.

Cloud-native vs lift-and-shift: when refactoring is worth it

• Lift-and-shift (rehost): direct migration of virtual servers to cloud VMs without changing code. Fast and low initial risk, but doesn't leverage cloud benefits (auto-scaling, resilience, pay-per-use). Recommended as a first step when under time pressure or when the team lacks cloud experience.
• Replatforming: migration to managed services (managed database, managed application server) without changing the application architecture. Reduces operational burden without the risk of full refactoring. The optimal balance for most enterprise applications in the first migration.
• Cloud-native refactoring (containers + microservices): maximum benefit but highest transformation cost. Justified when the application needs on-demand scaling, has multiple independent development teams, or requires multi-region high availability. Not justified for internal applications with predictable load.
• Serverless for intermittent workloads: Lambda/Azure Functions for event processing, API integration, notifications, and scheduled tasks. Zero cost at idle, instant auto-scaling. Well-suited for B2B integrations, webhooks, and data transformation processes.

Real costs of enterprise cloud: avoiding surprises on the bill

• The lift-and-shift without optimisation mistake: migrating physical servers to same-size cloud VMs without right-sizing typically results in bills 2-3x more expensive than the previous on-premise cost. On-premise servers typically run at 10-20% capacity; in the cloud, you pay for what you use if you architect well.
• Reserved Instances and Savings Plans: cloud charges on-demand pricing by default, which is the most expensive. With Reserved Instances (AWS) or Reserved Capacity (Azure) with 1-3 year commitment, savings are 40-72%. Mandatory for stable, predictable workloads.
• Egress costs (data transfer out): transferring data to the internet or between cloud regions costs money. In architectures with high data volumes between services in different regions, egress costs can exceed compute costs. Must be considered when designing topology.
• FinOps as a discipline: companies that manage cloud costs well designate a FinOps owner, implement resource tagging by project and environment, review bills weekly, and remove orphan resources (snapshots, elastic IPs, unattached volumes). Typical savings of 20-35% in companies without prior practice.

Cloud migration plan for existing enterprise applications

• Phase 1 — Inventory and dependency analysis: catalogue all applications, their technical dependencies, current SLAs, and business criticality. Prioritise applications by migration risk/benefit ratio.
• Phase 2 — Target architecture design: define the target VPC/VNet, managed services to use, hybrid network strategy, identity management, and security model. Don't skip this phase even under pressure to migrate quickly.
• Phase 3 — Pilot migration (non-production environment): migrate a development or staging environment first to validate the architecture, identify connectivity issues, and calibrate real costs before migrating production.
• Phase 4 — Production migration and cutover: plan the migration window, post-migration smoke tests, rollback plan, and user communication. The best teams execute cutover in a planned maintenance window with automatic rollback if tests fail.

Related resources