From on-premises to AWS, Azure or GCP. From one cloud to another. Or deliberately hybrid. We design the migration path, build the landing zone, move the workloads and stay on board until your team can continue independently. Vendor-independent: we do not choose a platform because we are a partner of it.
"Moving everything to the cloud" sounds like a logistical task: pick up applications, set them down somewhere else, done. In practice it is more involved. For each workload you have to decide whether to move it as-is, adapt it first, replace it with SaaS, rebuild it on cloud-native services, or deliberately leave it alone. Those choices have consequences that last for years: in cost, in operational burden, in security posture and in how quickly your team can keep developing afterwards. At its core, a migration is therefore a design question disguised as a relocation.
We guide migrations for mid-market organisations: businesses with several dozen to several hundred workloads and an IT team too small to carry the whole exercise alone, yet too capable to want to hand everything over. Our role combines direction and execution. We work with AWS, Azure and Google Cloud, and choose together with you which platform, or combination of platforms, suits your workloads, your compliance context and your team. No predetermined preference, and no partner quotas to meet.
Cloud migration guidance is broader than platform-specific advice. If you have already chosen AWS and are looking for platform-specific depth, you can read more on our AWS consulting page. If you are still before the cloud question and want to approach the broader digital strategy, our digital consulting practice offers that framework. If the migration of business applications itself is the focus — for example a new platform under an existing application — also look at platform migration development. This page is specifically about migrating infrastructure and workloads to or between clouds.
Cloud migration does not mean one thing. Below are the four movements we most often see in our practice — each with its own pitfalls, its own sequence of steps and its own risk profile.
The classic migration path. You have your own or a leased data centre, often with physical servers and/or a hypervisor stack, and want to move to AWS, Azure or GCP. The gain lies in flexibility, scalability and no longer investing in hardware. The pitfall lies in everything that worked implicitly on your own network — directory services, file shares, fixed IP addresses, custom logging — which in the cloud must be made explicit.
For example Azure to AWS, or GCP to Azure. Often driven by a corporate decision, an acquisition, an expiring enterprise agreement or a fundamental reconsideration of the platform choice. The complexity lies in cloud-specific dependencies — an Azure Functions app does not run without rework on Lambda, and an Aurora database does not move unnoticed to Cloud SQL. We map those dependencies before a single workload is set in motion.
Not every workload needs to move to the cloud. Sometimes keeping it on-prem is the right choice, because of latency to production systems, data volumes that are too expensive to move, or compliance requirements that translate poorly to a hyperscaler. We help you decide which workloads should move and which should not, and we build the network and identity integration that lets the two worlds work together securely instead of fighting each other.
The less discussed movement: an organisation that is in the cloud and deliberately wants out, whether back to on-premises, to another cloud, or to a mix. Often because costs no longer stand in proportion, or a data residency requirement suddenly becomes stricter. We also guide these kinds of projects — without judgement on the direction, but with attention to operational continuity.
Depending on where your migration stands and how much of the project you want to keep in-house. Which form fits is determined together in the first conversation — a project often begins with an assessment and grows into execution.
A structured review of your current landscape. We inventory workloads, map dependencies, score each application against the 7Rs framework and build from that a phased migration plan with the associated business case. At the end you know which workloads move in which phase, which target platform is logical per group, what costs and risks are involved, and which organisational preconditions must be arranged before the first workload is set in motion.
Before a single workload moves, the destination has to be right. We build a landing zone in your chosen hyperscaler: a multi-account or multi-subscription structure, baseline security controls, identity federation with your existing IdP, a network blueprint with segmentation and connectivity to your on-premises environment, and baseline logging and monitoring. The end result is an environment where your teams can receive workloads safely and predictably, without each team having to reinvent it.
Strategy without execution remains theory. In this engagement we stay on board for the actual migration, workload by workload or cluster by cluster. We roll out the planned 7Rs approach, carry out data migrations with careful attention to consistency, set up observability and cost monitoring as soon as workloads are live, and stay with you until the environment runs stably and your team can build on it independently. Knowledge transfer is not an afterthought but an ongoing responsibility.
The industry now uses a common vocabulary for what you can do with each workload: the "7Rs". It is not a law, but a useful handle for discussing migration choices in a structured way, especially when business, IT and finance sit around the same table. Not every workload needs the same treatment; the skill lies in making the right choice for each group and documenting the reasoning explicitly.
Rehost, or "lift-and-shift", moves a workload as-is. A VM in your data centre becomes an EC2 instance, Azure VM or Compute Engine instance. Quick and low-risk, with little direct gain beyond removing data centre dependency. Often a good first step for workloads that will be modernised later. Replatform moves with small adjustments, for example consuming the database as a managed service (RDS, Azure Database, Cloud SQL) without rebuilding the application. The gain is lower operational overhead and better operational characteristics, without the lead time of a rebuild.
Repurchase replaces the application with a SaaS equivalent. For commodity functions (email, file sharing, CRM, HR) it is often the most economical choice. Refactor redesigns the workload to take advantage of cloud-native services: containers, serverless, managed databases, event streams. A higher investment, but for strategic applications sometimes the only route to genuine scalability. Retire sounds obvious but is often overlooked: every landscape contains a percentage of workloads that could already be switched off, and a migration is the perfect occasion. Retain means deliberately leaving something where it is, see the hybrid approach above. Finally, Relocate moves entire VMware clusters or comparable workloads as a whole to a cloud equivalent (such as VMware Cloud on AWS), without having to make a 7Rs choice per VM.
No vague deliverables, but artefacts your cloud team, security officer, finance team and business owners can work with.
Six situations in which clients come to us for migration work. If one of these sounds familiar, we would be glad to talk further. A no-obligation conversation is enough to see whether we are a good fit.
You have a data centre contract that is coming to an end, or a server estate that no longer makes sense for what it delivers. The question is no longer whether you move to the cloud, but how to do it without bringing the business to a standstill and without building a lift-and-shift you will regret in a few years' time.
A corporate decision, an acquisition or an expiring volume contract is forcing you to change platform: Azure to AWS, AWS to GCP, or other combinations. You are looking for a partner who will design the migration without a bias towards either the original or the new platform, and who will honestly map out the cloud-specific dependencies.
Your sector imposes requirements on data residency, logging and incident procedures. The current environment only just meets them, and you want to use the migration to get it right in one go. We work from a clear information security policy and translate frameworks such as GDPR, DORA, NIS2, NEN 7510 and ISO 27001 into concrete architectural decisions, rather than waiting until the auditor arrives.
You are already running in the cloud, but monthly spend is growing faster than the business justifies. You suspect overcapacity, lift-and-shift workloads that were never properly finished and suboptimal platform choices, but the exact picture is missing. A targeted re-architecture under the banner of "cloud-native migration" makes a structural difference.
You're looking for honest advice on where the hyperscaler stops making sense. Some workloads, such as production control with strict latency requirements, archives with enormous data volumes, or systems tied to very specific hardware, belong on-premises by design. We help you choose, and we build the hybrid architecture that lets both worlds work together.
You'll notice that customers, regulators or your own DPO are placing sharper demands on where data physically resides and who has access to it. The question is shifting from "EU region" to options such as AWS European Sovereign Cloud, Azure EU Data Boundary, or GCP Sovereign Solutions. We help you map the real differences between those options, looking beyond the marketing, and choose together what fits.
For European organisations, data residency is often a prerequisite, and a migration is the ideal moment to get it right from the outset. All three major hyperscalers offer several EU regions. On AWS these include Frankfurt (eu-central-1), Stockholm (eu-north-1), Ireland (eu-west-1) and Paris (eu-west-3). Azure offers, among others, West Europe (Amsterdam), North Europe (Dublin), Sweden Central and Germany West Central. GCP offers regions such as europe-west4 (Eemshaven), europe-west1 (Belgium) and europe-north1 (Finland). Which region suits you depends on your customer base, latency budget, available services and the compliance context of your sector.
Above these sit the "sovereign" and boundary offerings. AWS European Sovereign Cloud is being set up as a legally and operationally separate platform within the EU. Azure EU Data Boundary promises that customer data and certain diagnostic data stay within the EU. GCP offers Sovereign Solutions in partnership with local partners. None of these options is simply "tick an EU region and you're done" — each has its own service limitations and operational consequences, which we weigh case by case.
For financial services providers, DORA applies: digital operational resilience, exit strategies for critical ICT providers, structured incident reporting and third-party risk management. For healthcare providers, NEN 7510 remains the framework. NIS2 affects a broader group of organisations and sets explicit requirements for governance and supply-chain security. The GDPR applies to all personal data. We ensure the migration design demonstrably supports these frameworks. For the wider security context around your own software, we also develop ISO 27001-compliant software that aligns with the cloud baseline resulting from the migration.
An initial conversation in which we learn where your IT landscape stands, which decision is on the table and what constraints apply — in terms of budget, compliance, team skills and timing. This is followed by a brief proposal phase in which we agree which form — assessment, design or guided implementation — best suits your starting point.
Together with your IT team, we build a clear overview of your workloads, dependencies, owners and compliance classification. Where documentation is scarce, we carry out lightweight discovery through network scans, monitoring data and interviews with the people who manage the systems day to day. No illusion of completeness, but an honest picture of the starting point.
In a few focused working sessions, we score the workloads against the 7Rs framework and determine the target platform for each group. This includes choosing a primary hyperscaler — AWS, Azure or GCP — or a deliberate multi-cloud strategy. No black-box analysis: your team makes the decisions together with us and retains ownership of the design.
We build the target environment using Infrastructure as Code: account or subscription structure, an IAM baseline, a network blueprint, baseline logging and monitoring, and integration with your on-premises environment and identity provider. At the end of this phase you have an environment that can receive workloads safely and predictably.
The actual migration runs in waves: first the low-risk workloads to calibrate the pace, then the more complex ones. For each wave we cover preparation, testing data paths, a cut-over plan, execution and stabilisation. For data-heavy migrations we set up continuous replication, so the final switch is brief and reversible.
After go-live, a workload remains vulnerable for a while: mismatched instance types, missing alarms, suboptimal network routes. We stay on board through stabilisation and make sure your team knows the runbooks, dashboards and escalation paths. The engagement only ends once the environment runs stably and your people can build on it independently.
What clients usually ask us before we start: honest answers, no sales talk.
A half-hour introductory conversation, no obligation and no sales pressure. We listen to your situation, ask questions and give you direction you can use — even if it turns out that working with us isn't the right next step, or that one particular cloud provider suits you better than another.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
