Cloud Migration: How to Plan the Transition

TL;DR

Main decision: Every application needs its own decision: lift-and-shift, refactor, replace with off-the-shelf, or do not move. These decisions clarify scope, risk and the cost estimate.
When Azure: Consider Azure when you need cloud-native services, elastic scaling or integration with Microsoft 365 or Dynamics 365. Assess data residency and compliance for the specific services and architecture.
When self-hosted: Self-hosted or dedicated infrastructure may work better for steady workloads or specific hardware, latency and operational-control requirements. Compare total cost and the team's capabilities.
Hybrid scenarios: Combining cloud and self-hosted can work well: cloud for elastic services and integrations, dedicated servers for steady workloads. Full TCO, security, latency and the team's operating capability determine the choice.
How to estimate the schedule: The schedule depends on the application and integration inventory, compatibility, data volume, downtime constraints, testing and operational readiness. The strategy alone is not enough to estimate it.

What Can Actually Change During a Cloud Migration

The scope of a migration can range from changing the operating environment to rewriting or replacing an entire application. The right option follows its current operations, data, dependencies and the reason the environment needs to change.

The following three levels describe the scope of technical change. They are not a ranking: each can be right for a different application.

Level 1: Lift-and-shift (cloud-hosted)

The application moves to cloud infrastructure without a major architecture change. Availability, backup and recovery do not appear automatically; they must be designed and paid for according to requirements. Rehosting can be a transition step or a long-term option if its operating and cost model works.

Level 2: Cloud-ready (replatform)

Selected infrastructure components are replaced by managed services, such as a web platform, database or object storage. These services may simplify some operational tasks, but the exact responsibility depends on the service, tier and configuration. Compatibility changes can be minor or substantial.

Level 3: Cloud-native (refactor or rewrite)

The application is designed for the cloud and may use serverless, event-driven communication and horizontal scaling. Consumption pricing can follow variable demand more closely, but architecture, minimum capacity and data transfer also affect cost.

The Operating Model Is Part of the Migration

The target environment needs a defined capacity, availability model, backup and recovery plan and cost controls. Without these decisions, the application changes location but not its operating model.

How to Decide for Each Application

The first step is deciding what to do with each application. Some can move without a major change, while others need modification, a rewrite or replacement; part of the portfolio may stay in its current environment. Each decision needs a reason, assumptions, the impact on data and integrations and a target operating model.

1

Rehost (lift-and-shift)

Move the application to cloud infrastructure without a major change. This often limits changes to the application, but it is not automatically the fastest or least expensive option: compatibility, networking, security and operations still need to be addressed. It can suit a data-center exit or act as an interim step before replacement.

2

Replatform (lift-and-reshape)

Move while adopting selected managed services, such as a database or web platform. The amount of change depends on application compatibility. Backup, availability and scaling follow the capabilities, tier and configuration of the selected service; they are not automatic properties of every deployment.

3

Refactor (re-architect)

Changing the architecture to use selected cloud services. A monolith can be divided into services, VMs replaced by containers or serverless functions, and some integrations moved to event-driven messaging. This is a more demanding option; its benefits and operating cost need to be weighed against the cost of change.

4

Repurchase (move to SaaS)

Instead of moving the old application, replace it with a SaaS product such as a new CRM or ERP. Core product development is no longer part of the project, but configuration, data migration, integrations and change management usually remain. This works when an available product meets the process and economic requirements.

5

Retire (switch off)

An audit can reveal unused or duplicate applications. The scope needs to be confirmed from the inventory, operational data and system owners. Safely retiring such an application is a migration strategy in its own right.

6

Retain (keep on-premises)

Hardware dependencies, regulatory constraints, latency or disproportionate change costs may justify keeping an application where it is. Retaining it is a valid strategy when support, security and links to migrated systems are also addressed.

Assessing the application portfolio creates the basis for a migration plan. The effort depends on portfolio size, documentation and access to system owners; the output should record decisions, assumptions, risks and estimated operating costs.

Cloud Migration Strategy Overview

The same decision can be summarized by the typical situation and the outcome required for each application.

Strategy	Typical situation	Outcome
Rehost	You want to limit changes or leave a data center	The same application on new infrastructure; operations are designed separately
Replatform	The application can use selected managed services	The provider handles part of operations within the chosen service and configuration
Refactor	The current architecture limits required change or operations	A revised architecture whose benefits and costs need validation
Repurchase	An available SaaS product meets the process requirements	A new product, configuration, data migration and integrations
Retire	The application is unused or duplicated	Controlled shutdown, including archiving and retention obligations
Retain	Regulatory or hardware constraint	The application stays in place and is reassessed when needed

swipe to see the full table

What Drives Cloud Costs

Cloud cost is more than compute. Depending on the architecture, it can include databases, storage, network traffic, availability, backups, licenses, monitoring, support and the operations team. The calculation therefore needs to reflect the actual workload and required service level.

Managed database: when it makes sense

A managed database can take over parts of patching, backup and availability. The exact division of responsibility and data recoverability depend on the service, tier and configuration. Compare the required SLA, team capabilities and total cost rather than deciding from database size alone.

Egress: data leaving the cloud

Providers often charge primarily for data leaving the cloud, but pricing varies by service, direction and region. Include analytics, inter-region transfers, backups and public traffic in the service-specific calculation.

Storage: operation and retrieval fees

Object storage (Azure Blob, S3) charges separately for storage itself and for operations (LIST, GET, PUT). Scripts walking all objects generate additional operations. The Archive tier suits long-term retention but has minimum retention rules and access fees.

Retention, Soft Delete and Snapshots

Soft delete and frequent snapshots protect data but consume additional storage. Their billing impact depends on change volume, frequency and retention, so model it in the provider pricing calculator before migration.

A price list is only an input. Build a workload model before migration, validate it with the provider's calculator and set budgets, alerts and regular reviews of actual consumption after launch.

Cloud, Self-hosted or Hybrid

The cloud is not one thing. Cloud and dedicated servers solve different problems, and the best architectures often combine them. The decision follows what your applications really need and how they are built, rather than what looks "modern".

For variable demand, we compare the benefits of elastic services in Azure, AWS or Google Cloud. For steady compute-heavy and data-heavy workloads, a dedicated server may be more economical once operations, availability, backup and recovery are included. The comparison must also cover long-term cloud and server management, change authority and incident response.

Azure, when you need cloud-native

Azure is a strong candidate when an application benefits from App Service, Functions, Cosmos DB, Event Grid or Service Bus and needs elastic scaling or integration with Microsoft 365 or Dynamics 365. Compliance and data-residency requirements still need to be assessed for the specific services and compared with alternatives.

Dedicated server, when you pay for raw performance, not elasticity

For steady compute or data workloads, fixed capacity can make the bill more predictable. The comparison must also include licenses, connectivity, power, recovery, monitoring, spare capacity and the team's work. Use total cost to decide.

Hybrid: Azure for frontend, dedicated server for data

One possible setup for companies with large datasets and an elastic frontend. The web application can run in Azure App Service, authentication through Entra ID, and the data layer on a dedicated server connected over VPN. Egress, latency, availability and operational effort determine the economics.

Keeping the Current Environment

A legacy application can remain on stable hardware when its operations meet requirements and a move would not deliver a matching benefit. The migration plan then addresses its support, security and links to the systems that do move.

What Must Be Ready Before the Migration Starts

A migration project needs a specific reason, available system owners and a way to verify data and operations after the transition. These inputs determine the assessment scope, sequence of stages and a realistic schedule.

Project Reason and Boundary

Define the constraint the migration should resolve and which applications, countries or operating areas belong in the first stage.

Owners and Decisions

Each application needs someone who understands its operations, confirms requirements and accepts the result.

Data, Access and Documentation

Prepare access to source systems, integration records, the data migration scope and available operating documentation.

Testing and Transition

Agree the acceptable downtime, control scenarios, responsibilities and conditions for proceeding or rolling back.

Helvetia System Migration to Azure

For Helvetia, we assessed a Visual Basic back office, rewrote the complete system in C# .NET and deployed it to Azure App Service and SQL Database. The rewrite and migration took 18 months, with a controlled transition across seven European markets. We continue to provide operational support and development.

Frequently Asked Questions

How long does a cloud migration take?

We estimate the schedule from the application and integration inventory, compatibility, data volume, downtime constraints, security controls and testing scope. For Helvetia, the project included a complete rewrite of a large Visual Basic desktop application in .NET and its migration to Azure; it took 18 months.

Will the cloud be cheaper than our current on-premises setup?

It can be, but it is not guaranteed. Lift-and-shift alone does not guarantee savings. Replatforming or refactoring may change operating cost, but compare full TCO: development, licenses, infrastructure, operations, availability, data transfer and exit costs.

Why are storage and databases expensive in the cloud?

Cost can include reserved capacity or consumption, availability, backups, stored volume, operations and data transfer. These items may dominate for large or poorly matched workloads. The answer is not automatically a rewrite or a hybrid setup: measure the workload first and compare the alternatives, including management costs.

Does combining cloud and self-hosted make sense?

Yes. Hybrid can make sense when one part needs elasticity or cloud integrations and another has steady compute or data demand. Full TCO, egress, latency, availability, security and the ability to operate both environments determine the outcome.

What does cloud-native mean versus cloud-hosted?

A cloud-hosted application runs on cloud infrastructure without a major architecture change. A cloud-native application is designed to use cloud services such as serverless, event-driven communication, managed databases or horizontal scaling. This does not automatically mean a lower price; compare both options for the actual workload and operating model.

How do we handle the EU Data Boundary and GDPR in Azure?

Microsoft completed the main phases of the EU Data Boundary in February 2025 (see the official Microsoft Learn documentation). This does not make an architecture automatically GDPR compliant. For every service, verify the selected region, processing terms, possible exceptions and data flows, with particular care for global, AI and analytics services.

Start with One System.

In the initial consultation, we review the operations, data and dependencies of one system and define the initial assessment scope.

Full Name *

Email *

Company (optional)

Phone (optional)

What do you need help with? *

I acknowledge the processing of personal data described in the privacy policy

This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

How to Plan a Cloud Migration