Your servers are five years old, the data centre contract is up for renewal, and someone on the board has asked for “the cloud plan”. You’ve made the decision to move. Now comes the harder part: how do you get there without breaking anything your customers rely on?

On-premise to cloud migration is the process of moving your applications, data and workloads from servers you own to a cloud environment run by a provider. When these projects go wrong, the cause is often gaps in preparation rather than the technology itself, which is why migrating from on-premises infrastructure to the cloud takes careful planning to keep downtime to a minimum.

We spoke with Tomasz Obszarny, Senior Technical Lead Cloud Architect, about cloud migration planning, possible strategies and the common challenges that can lead to migration failures. Below, you’ll find his advice alongside a step-by-step process, security essentials and a real project example.

What is on-premise to cloud migration?

Cloud migration refers to moving digital assets, such as applications, databases and entire workloads, into cloud infrastructure. On-premises to cloud migration is the specific case where you start from on-premises infrastructure (your own server room or data centre) rather than from another provider.

Where your workloads land depends on how much of the stack you want to run yourself. Cloud service providers typically offer three models:

  • Infrastructure as a service (IaaS): you rent virtual servers, storage and networking, and keep managing your own operating systems and applications.
  • Platform as a service (PaaS): the provider runs the underlying platform, such as managed databases or runtimes, so your team can focus on code and data.
  • Software as a service (SaaS): you replace an on-premises solution with a ready-made application hosted by a vendor.

P2C or V2C? You’ll also see migrations described by their starting point. P2C (physical-to-cloud) migration transfers physical infrastructure to cloud servers, while V2C (virtual-to-cloud) migration moves virtual machines to cloud services. Since most existing systems are already virtualised, V2C is the more common path. For the difference between the two technologies, read virtualisation vs cloud computing, or start with our introductory guide to the cloud.

Why move from on-premises to the cloud?

The business case should start from your business objectives, not from industry trends. Most companies build it around five benefits:

  • Scalability. Cloud environments offer better scalability than on-premises infrastructure. You add capacity for a seasonal peak and release it afterwards, instead of buying hardware for the busiest day of the year.
  • Lower running costs. Migrating to the cloud can reduce operational costs significantly, because you pay for cloud resources as you use them. The cost savings aren’t automatic, though, as the challenges section shows.
  • Performance and agility. Cloud migration enhances performance and agility: you can deploy closer to users to improve performance and ship changes faster.
  • Accessibility. Cloud migration improves accessibility for remote work, so distributed teams reach the same systems from anywhere.
  • Less maintenance, stronger foundations. Cloud providers often handle maintenance and updates, freeing your internal teams for strategic projects. They also invest heavily in security measures for data protection and offer built-in disaster recovery options, although how secure your environment ends up depends on how you configure it.

For most business operations, the biggest gain from cloud technology is flexibility, and cloud solutions give you that without a procurement cycle.

What does the on-premise to cloud migration process look like?

Of course, a detailed roadmap depends on your specific needs. There’s no one-size-fits-all solution. A successful cloud migration, however, usually moves through four phases: assessment, planning, execution and optimisation. A structured migration process starts by assessing your current assets and ends with a phased transfer, not a single big-bang weekend.

Skipping that structure gets expensive, as a lack of cloud migration strategy is a common source of costly mistakes. For the bigger picture, see our guide to cloud migration strategy.

Here’s how the steps below map to the phases:

  • Assess: steps 1 and 2
  • Plan: steps 3 and 4
  • Execute: steps 5 and 6
  • Optimise: step 7

1. Assess your current IT environment

Before you move anything, find out exactly what your existing infrastructure contains. The assessment phase includes an inventory and mapping of existing on-premises applications and hardware: servers, databases, storage, licences and integrations.

Next, map application dependencies. Effective cloud migration planning depends on knowing which systems talk to each other, because moving one half of a tightly coupled pair is a reliable way to break production. Finally, rate each workload’s cloud readiness. Tomasz explains why this step matters so much in the challenges section below.

2. Identify your needs and set goals

What infrastructure elements do you absolutely need to have access to? It may be that as you’re migrating data to the cloud, not everything will be as easy to access or will work as fast as on-premises. Internet connection latency plays a key role in how users perceive speed.

Moreover, there’s the matter of right-sizing: choosing the right size of cloud infrastructure. The size impacts the costs, so it’s important not to go overboard, or you may end up paying more than expected.

Turn these needs into measurable cloud migration goals: performance baselines, cost targets and acceptable recovery times. Without them, you can’t tell whether your migration journey succeeded or simply finished.

3. Define your target environment

With your needs clear, decide what you’re moving to. Start with the scope. Do you want a full or partial migration to the cloud? Or do you want to stay on-premises with backups in the cloud? Then choose the cloud model: public cloud, private cloud or a hybrid one.

Hybrid is already the norm. In Flexera’s 2026 State of the Cloud Report, 73% of surveyed organisations use a hybrid cloud model, and Gartner forecasts that 90% of organisations will adopt a hybrid cloud approach through 2027. A hybrid setup lets you keep workloads with specific operational requirements, such as low-latency plant systems or tightly regulated data, on premises while the rest runs in the cloud.

Finally, pick a cloud provider that meets your business needs, not the one with the longest feature list. AWS, Microsoft Azure and Google Cloud all cover the essentials, so the right cloud provider for you usually comes down to:

  • the services you need (IaaS, PaaS, or managed services for databases, analytics or AI)
  • regions and data residency options that match your compliance requirements
  • certifications relevant to your industry
  • how well it supports cloud integration with the systems you’re keeping on premises
  • pricing model, support levels and your team’s existing skills

Some organisations spread workloads across multiple cloud providers. A multi-cloud approach can improve resilience and negotiating power, and it’s one route to avoiding vendor lock-in, but it also adds operational overhead. Portable data formats, containers and open standards help either way.

4. Choose a migration strategy for each workload

Once you’ve settled on the right cloud platform, decide how each application gets there. AWS Prescriptive Guidance lists seven migration strategies, known as the 7 Rs. Most portfolios use several of them at once.

Retire

You identify applications that aren’t in use anymore and decide to decommission them rather than move them. What’s the point of migrating an unused application to the cloud if it would only waste resources without providing any value?

Retain

Sometimes, after identifying serious obstacles, you may decide to keep a system where it is for now and come back to it later. This may happen for legal reasons, for example, if you’re not allowed to store customer data on third-party servers. Migration may also not be advisable because of licence costs, for instance, when the licence price is calculated from the capabilities of the underlying physical hardware.

Rehost (lift and shift)

You move an existing solution from on-premises to the cloud with no changes. It’s quick to implement, but not necessarily the most cost-efficient option. Our guide to lift and shift explains when it pays off.

Relocate

You move a whole virtualised platform, such as a VMware environment, to its cloud-hosted equivalent without changing the applications or buying new hardware. It’s often the fastest route for large, already virtualised estates.

Repurchase (drop and shop)

You replace an application with a different product, most often a SaaS solution. A common trigger is licensing: if your current software’s licence doesn’t permit cloud installation, a cloud-ready alternative may be the only realistic route.

Replatform (lift and reshape)

The core architecture stays the same, but you make targeted changes for cloud compatibility or efficiency. An example is moving a self-managed database to a managed database service.

Refactor

You change the application’s architecture and code so it becomes cloud native, for example by splitting a monolith into services, moving to containers or replacing parts of it with managed and serverless components. It’s the most complex and costly option, so it’s usually reserved for applications where scalability or release speed really matter.

For large migrations, AWS recommends favouring rehost, replatform and relocate, then modernising once the move is complete. For a side-by-side comparison of different migration strategies, see our guide to types of cloud migration.

Where does serverless fit? In serverless computing, the provider allocates resources on demand and bills you mainly for actual usage. Functions run in response to events, such as an API request, a file upload or a scheduled task, rather than on servers you keep switched on. That said, not every component is billed only while it runs: storage, databases and some supporting services still generate costs when nobody is using the application. Serverless is typically part of a refactor, not a strategy on its own.

5. Run a pilot migration

Conduct pilot testing before any full-scale migration. A good pilot migration uses a real but low-risk workload, such as an internal tool or a reporting database nobody touches at 3 a.m. It proves your tooling, security setup and rollback procedure, and shows your team what working on the new cloud-based platform looks like. Measure the results against the goals from step 2 before you commit to the next wave of your migration plan. That’s how the TakTo project started, as the case study below shows.

6. Migrate in phases, test and cut over

Plan your migration in phases to minimise disruption. The actual migration usually runs in waves, with systems grouped by their dependencies so nothing arrives in the cloud without the services it relies on.

For each wave:

  1. Move the data. Data migration usually starts with an initial bulk transfer, then keep source and target in sync until cutover, so moving data doesn’t mean freezing the business.
  2. Validate data integrity. Compare record counts and checksums between the old and the new environment.
  3. Run user acceptance testing. Business users confirm that the migrated systems behave as expected, using real scenarios and realistic data volumes.
  4. Cut over in an agreed window. Downtime management is essential to keep business disruption low, so agree the window with stakeholders and keep a tested rollback plan ready.

Automation tools (infrastructure as code, replication services, scripted tests) make every wave repeatable, which matters once several migration projects run in parallel. Security measures belong in every wave too, as the next section explains.

7. Monitor and optimise

Going live isn’t the finish line. Monitoring and optimisation after migration are what keep performance and cost efficiency where you planned them. Use monitoring tools to track response times, utilisation and spend, then right-size again based on real data rather than estimates.

This is also the moment to leverage cloud native features that a straight rehost doesn’t give you. Storage is a good example: as Tomasz points out, data that’s rarely or never changed can move to cheaper object storage classes, such as those in Amazon S3, and AWS can shift it between tiers automatically based on how often it’s accessed. Finally, decommission the old on-premises systems so you don’t pay for two environments longer than necessary.

How to keep data secure and compliant during migration

Data security is a top concern during cloud migration, and for good reason: data on the move is often more exposed than it was in your own data centre, and every migration brings new compliance risks. Plan protection before the first byte leaves your network, and make sure your target architecture addresses security and compliance requirements from day one.

Cover these five areas:

  • Data encryption. Encrypt data in transit and at rest. Encryption is essential throughout the migration process, especially for sensitive data such as customer records or financial information.
  • Access management. Grant least-privilege access, enforce multi-factor authentication and remove temporary migration accounts once a wave is complete. Our article on cloud identity explains how identity works in the cloud.
  • Compliance. Standards such as GDPR and HIPAA apply during migration, not only after it. Check where your data will be stored and processed. Data residency rules are one of the reasons Tomasz gives for retaining some systems.
  • Shared responsibility. Your provider secures the underlying infrastructure, but you retain shared responsibility for data security in the cloud. Configuration, identities and the way you manage data stay with you.
  • Ongoing monitoring. Monitoring tools are necessary to ensure ongoing compliance post-migration, because configurations drift in cloud-based environments as new services are added.

Get these right, and the cloud can give you enhanced security compared with many on-premises environments.

What are the on-premises to cloud migration challenges?

The most common on-premises to cloud migration challenges are:

Insufficient pre-migration analysis and preparation

Let’s say your goal is not to use on-premises servers at all. However, during the migration, it turns out that some part of your product can’t be moved to the cloud. You overlooked that in your pre-migration analysis, and now the migration can’t be completed.

Good preparation for the migration process is key. You must go through your ecosystem and identify all elements that are to be migrated to the cloud, analyse their cloud readiness and determine which migration method is most appropriate.

Lack of expert knowledge

Every cloud migration project could fail if there’s not enough knowledge and skills to handle it.

Migration of big amounts of data

Sometimes the bandwidth of the internet connection doesn’t allow the transfer of the required amount of data to the cloud at a fixed time.

To prevent this from happening, some cloud service providers offer special services. For example, AWS has developed physical data transport devices in its Snowball family, which can accommodate large amounts of data so it can be shipped in and out of the cloud. Its truck-sized sibling, Snowmobile, was retired in 2024. Microsoft Azure Data Box and Google Cloud’s Transfer Appliance work in a similar way, while online services such as AWS DataSync suit ongoing data transfers.

Big transfers also expose weak spots in your own network, so upgrades may be necessary before data can move efficiently. And keep an eye on data transfer fees, especially for moving data out of a cloud, as they add up quickly.

Cost management and hidden fees

Cost management is a primary challenge in cloud migration, and it doesn’t disappear after go-live. In Flexera’s 2026 survey, 85% of respondents named managing cloud spend as a challenge, more than any other issue and ahead of security.

Hidden fees make it worse: egress charges, paying for two environments during the migration phase and oversized instances (the right-sizing issue Tomasz described in step 2). Many companies respond with dedicated financial operations (FinOps) practices.

Vendor lock-in

Vendor lock-in can occur if workloads are heavily reliant on proprietary cloud services. The managed services that save you the most effort are often the hardest to leave. You don’t have to avoid them, but use them knowingly and document your exit options.

Legacy system compatibility

Legacy system compatibility can complicate cloud migrations by requiring redesign or replacement of applications. Software tied to specific hardware, old operating systems or physical licences may need significant modifications, which is where refactoring or repurchasing comes in. Sometimes, retaining it for now is the honest answer.

Downtime and data loss

Cloud migration risks include unexpected downtime and data loss if the move isn’t planned meticulously. To protect business continuity, back up before every wave and keep a rollback path open until users sign off. Set up disaster recovery in the new cloud environment before cutover, not after the first incident.

On-premise to cloud migration case study

Do you have an application that has to be available for users 24/7 without any interruptions? Are you wondering how to plan the cloud migration so that it’s invisible on the customer side?

This was the scenario we faced with TakTo, one of our customers, for whom we executed a lift and shift migration strategy. We had to divide the process into a few stages. First, we transferred and tested smaller and non-customer-facing databases and environments. Then, we migrated TakTo’s databases, which were extensive and, from the technical point of view, the trickiest element to move. The migration went smoothly, and the change was imperceptible to the users.

In other words: a pilot on low-risk environments, then phased waves, with the hardest workloads saved until the process had been proven.

Here you can read TakTo’s cloud migration case study in full

Are you ready to move from on-premises to the cloud?

Want a migration plan built around your workloads, not a template? You get an assessment of what you have, a strategy for each workload and a cutover plan your users won’t notice. Tell us about your needs on our cloud services page.

Before you start, check that:

  • Your inventory and application dependencies are mapped
  • Your cloud migration goals and KPIs are defined
  • You’ve chosen a target environment and provider
  • Every workload has an assigned migration strategy
  • Your security and compliance plan covers the migration itself, not just the end state
  • You have a pilot workload and a tested rollback plan

FAQ

It’s the process of moving data, applications and workloads from your own servers to a cloud environment such as AWS, Microsoft Azure or Google Cloud. The goal is usually better scalability, lower running costs and more flexibility, while keeping business continuity and data security intact.

AWS lists seven, known as the 7 Rs: Retire, Retain, Rehost (lift and shift), Relocate, Repurchase, Replatform and Refactor. The right mix depends on your business goals, budget and infrastructure complexity, and most portfolios combine several.

Serverless computing allocates resources on demand and bills you mainly for actual usage, with code running in response to events or schedules. It suits variable workloads, but storage, databases and some supporting services still cost money when idle, so check the cost of every component.

Insufficient pre-migration analysis, a lack of in-house expertise and limited bandwidth for large datasets top the list, followed by cost control, vendor lock-in, legacy compatibility and downtime.

Define your goals, audit your existing systems and map their dependencies. Then run a pilot, migrate in phases starting with less critical workloads, test with real users before each cutover and keep a rollback plan ready. That’s how the TakTo migration stayed invisible to its users.

P2C (physical-to-cloud) moves workloads running directly on physical servers to the cloud. V2C (virtual-to-cloud) moves existing virtual machines to cloud services. V2C is usually faster, because virtualised workloads are already separated from the hardware.

It depends on the number of workloads, their dependencies, data volume, chosen strategies and compliance requirements. A small on-prem to cloud migration of a few rehosted applications moves far faster than a portfolio that needs refactoring.

Not automatically. Cloud providers invest more in physical and infrastructure security than most companies can, but security in the cloud is a shared responsibility. Your configuration, identities and data protection decide how secure your workloads really are.

It’s the reverse move, often called cloud repatriation: bringing workloads back to your own infrastructure, usually for cost, control or compliance reasons.

arrow_circle_right Table of contents

Małgorzata Kruszyńska

Małgorzata Kruszynska

Business Researcher

Related articles