«We're moving to the cloud» has become as frequent a phrase in boardrooms as it is vague in its content. A 40-person SME that moves its file server to OneDrive has not done the same thing as an industrial company that migrates its ERP to Azure with high availability and disaster recovery. Calling both things «cloud migration» creates confusion, miscalibrated expectations and, in the worst case, failed projects with unexpected bills. This article breaks the process down into its real parts: what moves, in what order, what can go wrong and what savings are legitimate to expect.
What does «migrating to the cloud» actually mean?
The term covers at least four distinct moves that should be separated from the outset:
- Lift-and-shift (rehosting): virtual machines are taken as-is and moved to a cloud provider (AWS EC2, Azure VMs, Google Compute Engine). It is the fastest option but the one that takes least advantage of cloud benefits.
- Replatforming: the application is adjusted to use managed provider services (managed database, load balancers, auto-scaling) without rewriting the code.
- Refactoring / re-architecting: the application is redesigned as cloud-native services (microservices, serverless, containers). Greater investment, greater long-term gain.
- SaaS replacement: an in-house application is retired and replaced by an existing cloud service (for example, abandoning a Postfix mail server and switching to Microsoft 365 or Google Workspace).
For most SMEs in Spain, 80% of projects called «cloud migration» are in reality a combination of SaaS replacement (email, office productivity, video calls) and replatforming of the ERP or critical business applications. Pure lift-and-shift is usually an intermediate step, not a destination.
Cloud models and what responsibilities remain with your company
One of the most repeated mistakes is assuming that «being in the cloud» removes operational responsibilities. The reality is that the shared responsibility model varies depending on which layer you contract:
| Layer | IaaS (e.g. Azure VM) | PaaS (e.g. Azure App Service) | SaaS (e.g. Microsoft 365) |
|---|---|---|---|
| Physical hardware | Provider | Provider | Provider |
| Network and virtualisation | Provider | Provider | Provider |
| Operating system | Client | Provider | Provider |
| Middleware and runtime | Client | Provider | Provider |
| Application | Client | Client | Provider |
| Data and access | Client | Client | Client |
| Backups | Client | Shared | Client |
The most critical point: data is always the client's responsibility, under any model. A SaaS provider that shuts down or suffers an incident has no obligation to return your data in a usable format if you have not explicitly contracted an export option. This is the foundation of why the backup strategy must be designed before — not after — the migration.
The 6 phases of a well-executed cloud migration
Phase 1: Inventory and workload classification
Before moving anything, you need to know what you have. That means inventorying all applications, servers and dependencies, and classifying each workload according to three variables: business criticality, technical compatibility with the cloud and estimated migration cost. Tools such as Azure Migrate, AWS Migration Evaluator or even a structured manual inventory in a spreadsheet work for this purpose. The result is a matrix that determines what moves first, what gets retired and what stays on-premise for technical, regulatory or cost reasons.
Phase 2: Target architecture design
Once workloads are classified, the cloud architecture is designed: which regions to use (this has implications for latency and GDPR compliance on data location), how the virtual network is structured, which managed services replace which current components, and what the identity strategy is (Active Directory integration, SSO, MFA). This phase also defines the cloud governance model: tagging policies, spending limits, cost alerts and who can provision resources.
Phase 3: Proof of concept and pilot migration
No production migration should run without having first migrated a non-critical environment. The pilot validates that applications work in the cloud environment, that response times are acceptable, that integrations with third parties remain operational and that the internal team knows the operational procedures. A week of piloting can prevent weeks of incidents in production.
Phase 4: Production migration in waves
Workloads are migrated in waves, starting with the least critical. For each wave a migration window is defined (normally outside business hours), a clear rollback plan and a set of post-migration checks (smoke tests) that confirm the application is operational before closing the window. For applications with an active database, the usual technique is continuous replication: the source database is kept synchronised with the destination until the cutover moment, minimising actual downtime.
Phase 5: Optimisation and cost adjustment
The cloud bill surprises when it is not actively managed. The first post-migration month is usually the most expensive because instance sizes are defined conservatively. Optimisation involves adjusting sizing (rightsizing), enabling auto-scaling where appropriate, removing orphaned resources and taking advantage of reserved purchase models (Reserved Instances on AWS, Azure Reserved VM Instances) that can reduce compute bills by between 30% and 60% compared to on-demand pricing, depending on 1- or 3-year commitments.
Phase 6: Continuous operation and improvement
The migration does not end on the day the on-premise server is switched off. Cloud operations require continuous monitoring, security update management (especially in IaaS models), periodic cost reviews and architecture evolution as the business changes. At Summum Sistemas we support companies both in the cloud migration project and in the ongoing operation afterwards.
Real risks that cloud projects underestimate
Egress costs nobody mentions in the proposal
The major cloud providers charge for data that leaves their platform (egress), but not for data that enters. For applications that move large volumes of data outward (exports to clients, integrations with on-premise systems that were not migrated, locally downloaded backups), this cost can be significant and does not appear in initial estimates. AWS, Azure and Google Cloud publish their data transfer rates, and these must be incorporated into the TCO (total cost of ownership) before the decision is made.
Technical vendor lock-in
Using proprietary services from a provider (serverless functions, proprietary NoSQL databases, specific messaging services) increases dependency. If you later want to change provider or recover on-premise operation, portability will be costly. The decision to use proprietary services versus standard services (Docker containers, PostgreSQL databases, Kubernetes) should be made consciously, weighing the immediate benefit against the future migration cost.
Regulatory compliance for data
The General Data Protection Regulation (GDPR) requires that international transfers of personal data to countries outside the European Economic Area have adequate safeguards. The major cloud providers (AWS, Azure, Google Cloud) offer regions within the European Union and standard contractual clauses, but it is the client who must verify that data is stored and processed in the correct regions and that the contract with the provider meets the requirements for a data processor under Article 28 of the GDPR. The Spanish Data Protection Agency (AEPD) has published specific guides on cloud computing that are worth consulting before migrating personal data.
Continuity during the migration itself
The transition period is the moment of highest risk: data can exist in two places at once, backups may not cover the intermediate state and teams operate on an architecture they only partly know. A documented contingency plan, with clear owners and explicit rollback criteria, is not a document for audits: it is what allows you to sleep soundly on migration night.
How much does an SME actually save by migrating to the cloud?
The honest answer is: it depends on where you start. A company that has physical servers less than five years old with high utilisation will probably not save money on pure compute by migrating to IaaS. The cloud will bring other advantages (elasticity, resilience, remote access), but not a reduction in infrastructure bills.
On the other hand, a company with ageing servers whose maintenance is expensive, with an oversized infrastructure built to cover peaks that occur twice a year, or with high server room costs (cooling, UPS, security), typically sees a real reduction in operational costs after migration.
The most solid and consistent savings come from three vectors:
- Replacing on-premise applications with SaaS: the cost of licences, updates, support and administration of in-house applications usually clearly exceeds the cost of the SaaS equivalent when the internal time spent is counted.
- Eliminating obsolete hardware: not renewing servers whose useful life has ended and whose maintenance cost is rising.
- Reducing disaster recovery time: this is not a direct saving on the daily profit and loss account, but the cost of an 8-hour outage in the critical systems of a medium-sized company frequently exceeds the annual cost of a well-designed cloud continuity plan.
If you need a realistic estimate for your specific situation, the starting point is a cloud migration feasibility analysis based on your real inventory, not sector averages.
Public, private and hybrid cloud: which fits your company
The public cloud (AWS, Azure, Google Cloud) is the majority option for SMEs because it eliminates physical infrastructure management and offers on-demand scale. The private cloud (dedicated infrastructure, managed on-premise or in a colocation) makes sense when there are very strict regulatory requirements, data volumes that make the public cloud inefficient, or ultra-low latency needs. The hybrid model combines both: it keeps on-premise what cannot or should not move (for cost, regulatory or latency reasons) and moves everything else to the public cloud.
For most Spanish SMEs with between 20 and 200 employees, the hybrid model with Microsoft Azure as the public cloud and Microsoft 365 as the productivity layer is the reference architecture that offers the most operational agility and the least adoption friction, especially where Active Directory already exists in the environment.
Frequently asked questions
How long does a complete cloud migration take?
It depends on the scope. An email and office productivity migration to Microsoft 365 for a 50-user company can be completed in 2 to 4 weeks, including training. An on-premise ERP migration to a cloud platform with historical data integration, training and post-go-live stabilisation rarely closes in less than 3 months and can extend to 6 in complex environments. Realistic project planning is one of the factors that most influences success: rushing is the number one cause of serious incidents in production during migrations.
Can I migrate to the cloud if I have sensitive or regulated data?
Yes, with appropriate precautions. Sectors with specific regulations (healthcare, finance, children's data, defence) have concrete requirements about where and how data is stored. The major cloud providers offer regions within the European Union and GDPR-compliant data processing agreements. For sectors with additional regulation (such as the National Security Framework — ENS — mandatory for entities that handle public administration data), it is necessary to verify that the chosen cloud provider and configuration hold the corresponding certifications.
What happens if the cloud provider has an outage?
The major providers publish availability SLAs generally above 99.9% for their services, but none guarantees 100%. A well-designed architecture distributes critical workloads across availability zones (or even regions) so that the failure of one data centre does not leave the entire company without service. Designing for resilience is an architecture decision, not an automatic feature of contracting cloud: it must be requested and paid for explicitly.
Does it make sense to migrate to the cloud if my internet connection is unreliable?
This is a legitimate starting point that many companies in rural areas or with limited connectivity must evaluate. The dependency on connectivity is real in a 100% cloud environment. The usual solutions include: dual internet lines (main fibre + 4G/5G as backup), architectures with local cache for the most critical applications, and an honest analysis of whether the average connection downtime is comparable to or less than the average incident time for the on-premise server you want to replace. In many cases, connectivity in Spain has improved enough that this argument is no longer decisive, but it must be verified with real data before committing.
Conclusion: cloud migration is a business project, not just an IT one
Cloud migration projects that fail almost always share the same pattern: they are designed as technical projects without involving the people who use the applications, without assigning a clear business owner and without establishing objective success criteria beyond «it just works». Those that succeed start by defining which business problem is being solved and work backwards to choose the architecture that best solves it at the lowest reasonable risk.
At Summum Marketing we have been supporting SMEs and mid-market companies in technology transformation projects since 2007. From Summum Sistemas we manage cloud migrations with a structured method that minimises operational risk and maximises real return. If you are evaluating taking the step, the first assessment costs nothing: tell us your situation and we will give you an honest answer on whether it makes sense, when and how.