Cloud Migration Best Practices for AI-Era Workloads

Nearly every cloud migration guide in circulation was written for a destination that no longer exists. The canonical advice — inventory your servers, pick a migration pattern per application, lift the easy ones, refactor the rest — assumes the target is a cheaper, more elastic version of the data centre you are leaving. That assumption held for roughly a decade. It does not hold when a meaningful share of what you will run in eighteen months is inference, retrieval, and model training.

The difference is not cosmetic. AI workloads invert several of the constraints that classic migration planning optimises around. They are capacity-constrained rather than cost-constrained in specific regions. They make data gravity dramatically more expensive to get wrong. Their cost curve is driven by tokens and GPU-hours, not instance counts, so the FinOps model you build during migration will not describe your bill a year later.

This guide covers the cloud migration best practices that survive that shift, written for engineering leaders who are accountable for the outcome rather than the slide deck. It is opinionated, and where the conventional advice is now wrong, it says so.

Cloud migration best practices start with a dependency map you trust

Migrations fail in the same place they have always failed: the undocumented dependency discovered at cutover. A batch job nobody owns writes to a share that a reporting system reads at 3am on the last business day of the quarter. Nothing in the CMDB records this. It surfaces eleven weeks into the programme, on a Sunday.

The traditional countermeasure is a discovery tool plus a series of interviews, and it has always been weak because it relies on people remembering systems they have not thought about in years. The honest baseline is that most organisations enter a migration with a dependency map that is roughly 70% accurate and 100% trusted, which is the dangerous combination.

The genuinely useful change here is that dependency discovery has become an observational problem rather than an interview problem. Network flow logs, eBPF-based tracing, and query-log analysis produce an empirical map of what actually talks to what, and language models are unusually good at the tedious remaining step — reading decades of undocumented scripts, stored procedures, and cron definitions and explaining what they touch. A team that would have spent a quarter on archaeology can now spend three weeks, and end up with better coverage.

Two cautions, both learned expensively. Observational discovery only sees what runs during the observation window, so run it for a full quarter-end cycle or you will miss exactly the periodic jobs that hurt most. And treat model-generated explanations of legacy code as leads to verify, not conclusions to act on — they are confidently wrong often enough that a single unchecked summary can put a false assumption into your cutover plan.

The seven Rs, re-scored for the AI era

The familiar migration patterns still apply, but their relative economics have shifted enough that mechanically reusing a 2019 decision matrix produces the wrong portfolio.

• Rehost — still correct for the long tail of stable, low-change applications. The old objection was that you carry inefficiency into the cloud, which remains true and remains acceptable for systems nobody will touch again.
• Replatform — now more attractive than it was. Managed database and container services have matured to the point where the classic middle option is less often a compromise and more often the right destination.
• Refactor — the pattern most changed by AI-assisted tooling. Code translation, test generation, and dependency upgrades that dominated refactor budgets are meaningfully faster now, which pulls applications across the threshold that previously made refactoring unaffordable.
• Repurchase — unchanged in principle, but evaluate whether the SaaS replacement will let you reach your own data. A product that locks your records behind an API with no bulk export becomes a serious constraint the moment you want to build retrieval over them.
• Retire — consistently the highest-return category and consistently under-used. Observational discovery usually reveals that 10–20% of the estate serves no live traffic at all.
• Retain — legitimate for genuine latency, licensing, or regulatory reasons; illegitimate as a way to defer a hard conversation. Re-examine every retain decision at the halfway mark.
• Relocate — useful for wholesale VMware-style moves, with the caveat that it optimises for speed of exit rather than fitness of destination.

The portfolio-level shift is that the refactor column should be larger than it was three years ago and the retain column smaller. If your plan looks like a 2019 plan, the assumptions underneath it have probably not been revisited.

Where AI genuinely helps, and where it will mislead you

It is worth being precise about this, because the vendor claims are inflated and the backlash against them is equally unhelpful. AI assistance is transformative for a specific, bounded set of migration tasks and close to useless for another set, and the two are easy to confuse when a demo looks impressive.

It helps materially with mechanical translation at volume — converting stored procedures between SQL dialects, upgrading framework versions across hundreds of services, generating characterisation tests for code with no coverage, and reading legacy source to explain intent. These are high-volume, pattern-heavy, verifiable tasks, which is exactly the shape the technology suits. Teams report the largest gains in test generation, because writing tests for code you did not author is the tedious step that most often gets skipped, and skipping it is what makes refactoring dangerous.

It does not help with the decisions that actually determine whether the migration succeeds: which applications matter to the business, what latency the trading desk will tolerate, whether the finance team will accept a two-hour reporting outage, or who owns the system nobody claims. Those are organisational questions. A model will produce a plausible answer to each of them, and the plausibility is precisely the hazard — an unverified answer to an organisational question looks identical to a verified one in a planning document.

The practical rule we apply on delivery: use AI to compress the mechanical 70% of migration effort, and reinvest the time saved into the political 30% rather than banking it as schedule. Programmes that treat the tooling gain as pure acceleration tend to arrive at cutover faster with the same unresolved organisational risks, which is not an improvement.

Data gravity is the cost driver nobody models early enough

The single most consequential planning decision in a modern migration is where the data lands, because everything else follows it. Compute is portable and cheap to move. Petabytes are neither. Once a large dataset is resident in a provider and region, the applications that read it are effectively pinned there by egress economics and latency, regardless of what your architecture diagram claims about portability.

This matters far more than it used to because AI workloads read enormous volumes repeatedly. Training and embedding pipelines do full-corpus passes. Retrieval systems read continuously. If your document corpus sits in one provider and your model endpoint in another, you are paying egress on every pass, and that line item grows with usage rather than staying flat.

Plan data placement first, then place compute around it, rather than the reverse. In practice this means deciding early which datasets are your gravity wells — usually the transactional record, the document corpus, and the event stream — and treating their location as a near-irreversible commitment that everything else accommodates. Teams that migrate applications first and sort out data later routinely discover they have distributed a single logical system across two providers, and the fix is a second migration.

GPU capacity changes your region strategy

Classic region selection weighs latency to users, data residency, and price. AI workloads add a constraint that catches teams off guard: accelerator availability is not uniform across regions, and the region you chose for good latency reasons may simply not have the capacity you need when you need it.

Capacity for current-generation accelerators is allocated, queued, and in periods of scarcity effectively rationed. A region that serves your users well may have months of lead time for reserved capacity, while a region two hops further away has availability now. This is a genuine architectural constraint, not a procurement footnote, and it belongs in the migration design rather than surfacing later as a surprise.

• Confirm accelerator availability in your target regions before committing to a landing-zone design, and get lead times in writing.
• Separate inference placement from application placement — inference can often sit in a different region from the app tier without harming user experience, provided the data path is designed for it.
• Keep a managed-endpoint fallback for burst demand rather than sizing reserved capacity for your peak, which is usually the more expensive of the two mistakes.
• Model the cost difference between reserved commitments and on-demand at realistic utilisation — the break-even point is frequently higher than vendors suggest.

Networking and egress: the bill nobody forecasts

Egress charges are the most reliably under-modelled item in migration business cases. They are invisible on-premises, where cross-system traffic costs nothing incremental, and they become a metered line item the moment you move. Architectures that were free to chat constantly between components start generating a bill proportional to their chattiness.

Hybrid states make this sharply worse, and hybrid states last longer than anyone plans. A migration that runs eighteen months with half the estate in each location can spend more on inter-environment traffic than on the target compute. The conventional advice to migrate application by application is what causes this, because it maximises the period during which tightly coupled components are separated by a paid network boundary.

Migrate in dependency clusters rather than by application. Identify groups of systems that talk to each other frequently and move them together, even when that makes individual waves larger and harder to schedule. A larger wave with a clean boundary is cheaper and less risky than six small waves that each straddle the network divide. This single sequencing choice tends to have more effect on total migration cost than any instance-sizing exercise.

Cutover patterns that do not require a weekend war room

The big-bang weekend cutover persists mostly because it is easy to plan, not because it works well. It concentrates all risk into a window with no meaningful rollback, staffed by people who have been awake for fourteen hours. When it goes wrong, the decision to roll back is made at 4am by someone with incomplete information and a strong incentive to push on.

Incremental patterns are more work to build and substantially safer. Strangler-fig routing moves traffic per endpoint, so each step is small and individually reversible. Dual-write with reconciliation lets both systems run in parallel while you verify consistency against real traffic. Shadow traffic sends production requests to the new system without serving its responses, which surfaces behavioural differences before any customer is exposed.

The common objection is that these patterns require building throwaway infrastructure — routing layers, reconciliation jobs, comparison tooling — and that is accurate. The counter-argument is simply the expected cost of a failed cutover on a system that matters, which is usually an order of magnitude larger than the throwaway scaffolding. Reserve big-bang for systems where a few hours of downtime is genuinely acceptable, and say plainly which those are rather than assuming.

Whichever pattern you choose, define the rollback trigger numerically and in advance — error rate above x, p99 latency above y, reconciliation mismatch above z — and give one named person authority to call it without convening anyone. Rollback criteria negotiated during an incident are rollback criteria that never fire.

Landing zones and the guardrails that prevent year-two chaos

The landing zone is the account structure, network topology, identity model, and policy set that every migrated workload lands into. Getting it wrong is recoverable but expensive, because remediation means touching every workload that already landed. It is worth several weeks of deliberate design before the first wave, and it is consistently the step compressed when schedules tighten.

The guardrails that repay the effort are mostly about defaults rather than restrictions: encryption on by default, public network exposure denied unless explicitly granted, tagging enforced at creation so cost allocation works from day one, and centralised logging that a workload cannot opt out of. Policy-as-code makes these preventive rather than detective, which matters because detective controls in a fast migration generate a backlog nobody clears.

Add AI-specific guardrails now rather than in a later pass: model endpoints restricted to approved providers and regions, outbound network allowlists for anything running agent tooling, and a requirement that data classification metadata travels with datasets into the new environment. These are cheap to establish at landing-zone design time and awkward to retrofit across a populated estate. The same reasoning applies here as in any cloud application development effort — the defaults you set early determine what is possible later.

FinOps after the migration, when the bill changes shape

Most organisations build a cost model during migration that describes steady-state infrastructure — instances, storage, databases — and then find it does not survive contact with AI workloads, whose costs are driven by usage volume rather than provisioned capacity. A feature that becomes popular gets more expensive in direct proportion, which is not how the rest of the estate behaves.

Instrument for this before you need it. Token consumption and inference calls should be attributed per feature and per customer segment from the first deployment, because retrofitting attribution across a live system is painful and the question — which feature is driving this bill — always arrives urgently. Unit economics per transaction is the metric that keeps the conversation rational when a finance stakeholder asks why the AI line grew 40% in a month.

Expect the optimisation levers to be different too. Rightsizing instances is a tuning exercise; the equivalent levers for AI workloads are model selection, caching, prompt size, and batching, and they are typically worth far more. Routing routine requests to a smaller model and caching aggressively often reduces inference spend by half without a perceptible quality change, which is a larger saving than most infrastructure optimisation will ever deliver.

The 30% that no tooling touches

Every honest account of a large migration eventually concedes that the hard part was never technical. The team that will not release ownership of their server. The vendor contract with a termination window that does not align with your plan. The business unit that agreed to a cutover date and then discovered it collides with their busiest fortnight. The application whose only expert left the company.

These consume more calendar time than the engineering, and no tooling improvement addresses them. What helps is structural: name an accountable owner per application with real authority, get executive agreement on the retire list early because deletion is where the resistance concentrates, and publish a wave schedule that business units can plan around rather than negotiating each one separately.

The other structural help is refusing to start the technical work on an application until its organisational questions are closed. Teams that migrate the willing systems first and leave the contested ones for later do not eliminate that work — they concentrate all of it into the final third of the programme, when schedule pressure is highest and goodwill is lowest. Front-load the arguments; they do not get easier with time.

A sequence that holds up

Pulling the above together, the ordering that repeatedly works is: build an empirical dependency map and run it through a full business cycle; decide data placement and commit to it; design the landing zone with AI guardrails included; agree the retire list at executive level; then migrate in dependency clusters using incremental cutover patterns, with numeric rollback criteria and cost attribution instrumented from the first wave.

What that sequence protects against is the three failures that account for most migration overruns — the undiscovered dependency, the data-placement decision made implicitly by whichever team moved first, and the hybrid period that outlasts its budget. None of those are solved by tooling. They are solved by deciding the irreversible things deliberately and early.

If you are planning a migration where AI workloads are part of the destination, we help engineering teams make these calls before they harden — particularly data placement and landing-zone design, where the cost of a late change is highest. Have a look at how we approach custom software development and AI development services, or talk to us about your estate.

Frequently Asked Questions

What are the most important cloud migration best practices?

Build an empirical dependency map from network and query telemetry rather than interviews, decide data placement before compute placement, migrate in dependency clusters instead of application by application, use incremental cutover patterns with numeric rollback criteria, and design the landing zone with guardrails before the first wave lands. Those five decisions determine most of the outcome.

How long does a typical enterprise cloud migration take?

For a mid-size enterprise estate of a few hundred applications, eighteen months to three years is realistic. AI-assisted tooling has meaningfully compressed the code and testing work, but discovery, organisational negotiation, and cutover scheduling have not compressed proportionally, so total timelines have shortened less than tooling vendors suggest.

Should we lift and shift first, then modernise?

It is a defensible strategy for a datacentre exit with a hard deadline, but the second phase frequently never receives funding once the first phase declares success. If modernisation genuinely matters, do it for the applications that warrant it during the migration, when the budget and attention exist. Lift and shift the long tail that will never be touched again.

How do we control cloud egress costs during migration?

Move tightly coupled systems together as a cluster so they are not separated by a paid network boundary, and shorten the hybrid period as much as possible. Egress between environments during a long hybrid state is the single most under-forecast cost in most migration business cases, and sequencing is the main lever against it.

Does AI actually speed up cloud migration?

Yes, for mechanical high-volume work: code and SQL dialect translation, framework upgrades, characterisation test generation, and reading undocumented legacy code. No, for the decisions that drive the timeline — ownership, business risk tolerance, and cutover scheduling. Expect real gains on the engineering portion and little change to the organisational portion.

Where should AI workloads run relative to our data?

As close as possible, ideally in the same provider and region as the primary dataset. AI workloads read large volumes repeatedly, so cross-provider or cross-region data paths generate egress charges and latency that scale with usage. Data placement should be decided first, with inference placed around it.

What is the biggest cause of cloud migration failure?

Undiscovered dependencies surfacing at cutover, closely followed by hybrid periods that run far longer than budgeted. Both stem from an incomplete dependency map that the programme nonetheless treats as authoritative. Empirical discovery across a full business cycle addresses both more effectively than any other single intervention.

How should we budget for AI workload costs after migrating?

Model them as usage-driven rather than capacity-driven, and instrument token and inference attribution per feature from the first deployment. The effective optimisation levers are model selection, caching, prompt size, and batching — typically worth considerably more than instance rightsizing, and easier to apply when attribution data already exists.