Lift-and-shift is a migration wave, not a destination

Lift-and-shift has a poor reputation, and most of it is undeserved. Moving an application with as little change as possible is often the safest way to get out of a data centre on time. It separates two risky things, relocating a system and redesigning it, so that they do not happen on the same weekend.

The reputation comes from what happens afterwards. The application lands in the cloud, it works, everyone moves on to the next wave, and the "temporary" state becomes permanent. Nobody owns the decision about what happens next, nobody budgeted for it, and nothing triggers it. Two years later the organisation is paying cloud prices for a data-centre design, and the original reason for the shortcut has been forgotten.

This part is about keeping the benefit of rehosting without inheriting that trap. The tool is simple: every rehosted workload carries an exit ticket, and every exit ticket has a date.

Bushbuck Brands is fictional, and its systems and figures are illustrative. Bushbuck, the South African FMCG distributor we follow through this series, rehosted 46 applications in its first wave between February and May 2026, to keep pace with a co-location contract that ends in June 2027. Part 1 described the bill that followed.

When rehosting is the right call

Rehosting, also called lift and shift, moves an application to the cloud with little or no change to the application itself. AWS describes it as moving an application "without making any changes"; Microsoft defines it as a like-for-like migration. It is the right call when the risk of changing the application during the move is greater than the cost of carrying its inefficiencies for a while:

A data-centre or co-location exit has a fixed date. Bushbuck's contract ends in June 2027, and an overrun means an expensive short-term extension, if the landlord offers one at all.
Hardware is failing or out of support. Bushbuck's storage array is already past its support date. Every month on it is a month of unhedged risk.
A contract or licence is ending and renewal would lock in another three to five years of the old model.
Changing the application while relocating it would create unacceptable risk. A vendor product that the vendor supports only on a particular operating system, for example, is not something to redesign under deadline pressure.

The large providers say much the same. AWS's migration guidance advises against refactoring during large migrations and suggests moving first and modernising afterwards. Microsoft's Cloud Adoption Framework adds a useful counterweight: do not rehost workloads that are already problematic, and rehost only where the workload will not need modernising within about two years. Both are right. Rehosting is a sound way to move a stable workload quickly. It is a poor way to move a broken one.

When rehosting becomes a trap

Rehosting becomes a trap when the temporary state has no owner, no budget and no trigger.

No owner means nobody is accountable for the next decision. The migration team has moved on to the next wave; the application team was never asked; operations inherited something they did not design.
No budget means that even when someone notices the waste, there is no money or time to fix it. The fix competes with every new project and loses.
No trigger means nothing forces the conversation. There is no date, no threshold and no review. The application simply keeps running, and keeps costing.

At Bushbuck, the first two problems appeared within weeks. The migration team was busy planning the next wave, and the application owners assumed the migration team would optimise what it had moved. Nobody had written down whose job it was, so it was nobody's.

The exit ticket

The fix is a short, mandatory record attached to every rehosted workload. We call it an exit ticket, because it describes how the workload will leave its temporary state. It has seven fields:

Why rehost was selected. The specific reason: the exit date, failing hardware, vendor support, or risk.
Which inefficiencies are deliberately accepted. Oversized servers, an old backup agent, a public address that should be private. Writing them down turns them from accidents into decisions.
The first optimisation date. When the workload will be reviewed against real demand. Bushbuck chose 90 days after cutover.
The target utilisation and cost baseline. What "right-sized" will mean, and what the workload costs today, so improvement can be measured.
Licensing constraints. Licences can make one size, provider or deployment model materially cheaper or dearer, especially for Windows Server and SQL Server. Record what applies before anyone resizes.
The criteria for the next decision. What would make the workload a candidate to modernise, replace, retain or retire.
The owner who must make the next decision. A named role, not a team or a committee.

Bushbuck's warehouse management system was rehosted because the date and the vendor left no better option. The ticket records the waste accepted on purpose, the date it will be reviewed and who decides what happens next. Details are illustrative.

The ticket is deliberately small. It should take an hour to complete, not a week. Its value is that it converts a vague intention ("we'll optimise it later") into a commitment with a date and a name. An exit ticket without a first optimisation date is not an exit ticket.

Bushbuck created exit tickets retrospectively for all 46 first-wave applications in a fortnight, and made them a condition of cutover for every wave after that. The warehouse management system's ticket, above, is typical: a vendor product supported only on virtual machines, moved as-is because of the date, with its waste written down and a review booked.

After the move: stabilise, measure, decide

A rehost is the first step on a path, not the end of one. The path has three stages before the next decision.

A rehost buys time. After the workload is stable and its real demand is measured, its strategic value decides the next treatment. Rightsizing helps at both ends of the move, but neither fixes a poor application design.

Stabilise. For the first weeks, the priority is that the workload runs reliably in its new home. Resist the temptation to resize on the first day: users are adjusting, monitoring is new, and a performance complaint during this period is hard to diagnose if the size has just changed too.

Measure real demand. Then gather enough telemetry to see the workload's actual shape: CPU and memory at peak and at rest, storage growth, network traffic, the daily and monthly cycles. Ninety days is a sensible minimum for a distributor like Bushbuck, because it captures a month-end and the run-up to a holiday period. A workload with an annual peak needs a plan for that peak, not just three months of averages.

Decide on strategic value. With real demand in hand, the exit ticket's owner makes the next decision. High strategic value points toward replatforming or refactoring: Bushbuck's trade ordering portal, which independent retailers use to order stock, was rehosted only because of the date and has a refactor decision scheduled for the first quarter of 2027. Low strategic value points toward replacing, retaining as-is or retiring: several of Bushbuck's duplicate reporting tools turned out to have a handful of users each and were retired rather than optimised. Part 3 covers how to make that choice consistently across a whole estate.

Rightsizing before and after the move

Rightsizing means matching a workload's allocated capacity to its real demand. It can happen at two points, and both are worth doing.

Before migration, rightsizing removes the obvious waste. If a server has run at 5% CPU for a year, there is no need to carry its full size across. Migration assessment tools from all the main providers will suggest a target size from on-premises performance data. Bushbuck skipped this step for wave 1 to save time, and Part 1 showed what that cost. For later waves it rightsized on the assessment data, conservatively, before the move.

After migration, rightsizing uses real cloud telemetry, which is more trustworthy than on-premises measurements taken on different hardware. This is where the 90-day review earns its keep. It is also the point at which commitment discounts (one- or three-year commitments in exchange for lower rates, offered by all three major providers) become safe to consider, because the baseline they commit to has been measured rather than guessed. Committing before rightsizing locks in the waste. The earlier pieces on what we check in a cloud cost audit and ten practical optimisation changes cover the mechanics of this work in more depth.

Both matter, but neither corrects a poor application architecture on its own. A right-sized server running a chatty application that makes a thousand database calls per page is still a chatty application. If a workload's design is the problem, rightsizing is housekeeping, not a cure. That is a decision for the exit ticket's owner, not for the infrastructure team.

Common mistakes

Rehosting without a date for the next decision. "We'll optimise it later" is how temporary becomes permanent.
Leaving the next decision to the migration team. They are measured on moving the next wave; the application's owner should own its future.
Rehosting a workload that is already failing. A broken application in the cloud is still broken, and now it is broken on a meter.
Committing to discounts before rightsizing. A three-year commitment to an oversized baseline turns waste into a contract.
Resizing during stabilisation. Change one thing at a time; let the workload settle before tuning it.
Treating rightsizing as modernisation. It removes waste; it does not fix design.

A decision you can defend

We will rehost Bushbuck's warehouse management system because the co-location exit date is fixed and the vendor supports it only on virtual machines. We accept its on-premises sizing and the old backup agent until the first optimisation review, 90 days after cutover, when we will rightsize on measured demand and remove the duplicate backup. The Head of Logistics owns the next decision, and we will review it if the vendor's SaaS edition is proven in South Africa before 2028.

What to take from this part

Rehosting is a valid risk-management technique. It separates relocating a system from redesigning it.

The trap is a temporary state with no owner, budget or trigger. Fix all three, not just one.

Every rehost carries an exit ticket. Seven fields, an hour's work, and a first optimisation date.

Rightsize at both ends, and commit only after measuring. But do not mistake rightsizing for fixing the architecture.

Next in the series: Choose a treatment for every workload: the migration Rs as decisions.

How CloudNala can help

We help organisations plan migration waves that meet a hard date without inheriting the cost trap: setting up exit tickets and review dates for rehosted workloads, running the first optimisation reviews against measured demand, and separating the workloads that need rightsizing from those that need a design decision.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Request a Cloud Review or write to us at consult@cloudnala.co.za