# Cloud migration > We migrate applications, databases and operations onto Azure, AWS, Google Cloud and Cloudflare in waves, against an inventory agreed before the first move. Exclusions are written down and signed, each wave is reversible, and the workloads that should be rebuilt rather than moved are identified before anyone commits a date. For: Infrastructure and platform leaders with a deadline and a partial inventory Canonical: https://www.techfabric.com/cloud/migration --- Move the estate without discovering it as you go Migrations rarely fail on the technical work. They fail because the inventory was a spreadsheet somebody built in a week, the exclusions were never agreed, and every wave turns up three services nobody remembered owning. The date moves twice and the business stops believing the plan. ## What we look at - Every application, its dependencies, and who currently owns it - What is explicitly not coming, written down so it can be signed - Which workloads should be rebuilt rather than moved, and what that costs against moving them - Data gravity: what has to move together and what can follow later - Licensing that changes price on the other side, which is where budgets usually break - The rollback position for each wave, before the wave runs ## What you get - A wave plan built on the inventory, ordered so the risky things happen while attention is high - Infrastructure as code, so the second environment costs a fraction of the first - Each wave reversible until it is signed off, rather than a one-way door - The operational runbook written during the migration and not after it - Cost measured against the old estate monthly, so the business case survives contact with the bill - Your team running it by the last wave, because we would rather leave than stay ## Clients we have done this for - [Location Services](https://www.techfabric.com/case-studies/vrm) (Automotive / Fintech): Synapse and SQL Server moved onto Databricks in reversible waves, with the rules engine that validates a repossession assignment carried across. - [DealerIQ](https://www.techfabric.com/case-studies/dealeriq) (B2B ecommerce): A platform that started on Azure, moved off Cosmos DB and SQL Server in reversible waves. ## One of seven answers, per workload Our engineers sit with your platform team and give every workload in the estate one of seven answers before anyone sets a date, which is how the migration stops turning up surprises in wave four. AWS's guidance calls them the 7 Rs. Retire, retain, rehost (lift and shift), relocate, repurchase (move to SaaS), replatform, and refactor or re-architect. The useful part of AWS's guide is how specific it gets about the first one. An application averaging under 5% CPU and memory is a zombie, one between 5% and 20% over 90 days is idle, and one with no inbound connection in 90 days is a candidate to retire rather than move. Most inventories carry a few of each, and every one moved is a server you pay for twice. AWS also recommends against refactoring during a large migration. Rehost, replatform or relocate first, then modernise once the workload is running in the cloud. We agree for the long tail, and make the exception per workload where the running cost or the release cadence pays for the rebuild, decided in the assessment and written down. ### Inventory, with owners Every application, its dependencies, and who owns it. Utilisation data from the discovery tool marks the zombie and idle ones before anybody plans to move them. ### A strategy per workload One of the seven, chosen per application, with the reason. The rebuild candidates are named here, priced against moving them as they are. ### Signed exclusions What isn't coming, written down and signed, so it can't reappear as a surprise in wave four. ### Waves, each reversible Ordered so the risky moves happen while attention is high, each with a rollback position agreed before it runs, and the runbook written during the wave rather than after the last one. Checked against: [AWS Prescriptive Guidance: migration strategies](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html). ## Tools that changed since your plan was written AWS Migration Hub stopped accepting new customers on 7 November 2025, and AWS Application Discovery Service closed to new customers on the same date. Existing users can finish the migrations they started. AWS names AWS Transform as the successor for discovery, strategy recommendations and orchestration, and its rehost tool, Application Migration Service, now appears in AWS's own guide as AWS Transform MGN. A plan written in 2024 that starts with "deploy the discovery agent" needs that step rewritten. On Azure, Azure Migrate is still the free starting point for discovery, assessment, dependency analysis and a business case. Discovery runs through an appliance in your data centre, or the Azure Migrate Collector, which takes a snapshot without continuous Azure connectivity, for air-gapped or restricted networks. Movere, the older discovery tool, is retired. Checked against: [AWS: Migration Hub availability change](https://docs.aws.amazon.com/migrationhub/latest/ug/migrationhub-availability-change.html), [AWS Application Discovery Service](https://aws.amazon.com/application-discovery/), [Microsoft Learn: about Azure Migrate](https://learn.microsoft.com/en-us/azure/migrate/migrate-services-overview). ## Licensing that changes the price on the other side Windows Server and SQL Server licences are where cloud migration budgets break, because the rules depend on which cloud and which kind of host. On Azure, Azure Hybrid Benefit lets you bring Windows Server core licences, but only with active Software Assurance or a qualifying subscription licence. It counts a minimum of eight core licences per VM, so a four-core VM still uses eight, and a processor licence counts as sixteen cores. The benefit only runs for the Software Assurance term, so a lapsed agreement turns into pay-as-you-go pricing overnight. On AWS and Google Cloud, Microsoft's licensing terms since 1 October 2019 treat Alibaba, Amazon, Google and Microsoft as Listed Providers. Licences bought without Software Assurance and mobility rights can't be deployed on their dedicated hosted services, which is the usual route people plan for bringing their own licence. Check Microsoft's current Listed Providers document before you price a wave, because the list can change. - Does every application in the inventory have a named owner? - Which servers have averaged under 5% CPU and memory for 90 days? - Is the list of what isn't moving written down and signed? - Which Windows Server and SQL Server licences carry Software Assurance, and when does it end? - Is your discovery tool still open to you, or was it one of the AWS services closed to new customers in November 2025? - What is the rollback position for the first wave, before it runs? ``` az vm list --query "[?licenseType=='Windows_Server'].{name:name, rg:resourceGroup, size:hardwareProfile.vmSize}" -o table ``` Every Azure VM already using Azure Hybrid Benefit for Windows Server, with the Azure CLI. Compare the count with the core licences your agreement actually covers. Checked on 11 October 2026 against: [Microsoft Learn: Azure Hybrid Benefit for Windows Server](https://learn.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing), [Microsoft: Listed Providers](https://www.microsoft.com/licensing/docs/view/Listed-Providers). ## Questions ### How long does a cloud migration take? The honest answer is that the assessment tells you, and anyone quoting a duration before seeing the estate is guessing. What we can say is that the assessment itself is weeks rather than months, and it is the part that makes the rest of the schedule mean anything. ### Do you do lift-and-shift or rebuild? Both, chosen per workload rather than as a programme-wide position. Most estates have a long tail that should move as it is and a small number of systems where the running cost or the release cadence justifies rebuilding. Deciding that per workload is most of the value in the assessment. ### What happens if a wave goes wrong? You go back. Each wave stays reversible until it is signed off, which costs a little more to set up and is the difference between a bad weekend and a bad quarter. A migration where rollback was never built is one where the first serious problem becomes a negotiation. ### Can you work with our existing cloud team? That is the usual shape. Our engineers embed alongside yours, and the aim is that your team runs the last wave with us mostly watching. Where you would rather we took the whole thing, we will.