Migration strategies: rehost, replatform, refactor, and the two that are not moves

Why this matters

CompTIA's bullet is planning and executing migrations. This lesson is the planning half, and it is largely about one decision made per workload: what shape should this take when it lands?

The decision matters because the effort ranges from days to quarters and the benefit ranges from "cheaper hosting" to "a fundamentally better system". Get it wrong in one direction and you spend a year rewriting something that should have been moved as-is; wrong in the other and you lift a badly-behaved application into a cloud where it costs more and behaves no better.

Exam questions on this objective give you a workload with constraints and ask which strategy fits. The constraints — deadline, budget, remaining life, skills, licence model — decide it, not the technology.

The lesson

Rehost, replatform and refactor, and the effort and benefit curve across them

Rehost ("lift and shift"). Move the workload substantially unchanged — same operating system, same application, same architecture — onto cloud infrastructure. Usually via a migration tool that replicates the server.

• Fastest, lowest risk, least disruptive to the people who run it.
• Gains: leaves the data centre, becomes elastic in a crude way, gets modern hardware and cloud backup and monitoring.
• Does not gain: nothing architectural. An application that cannot scale horizontally still cannot.
• The common criticism is half right. Rehosting a badly-utilised server onto an equivalently-sized instance often costs more than the depreciated hardware. Rehosting with right-sizing (objective 2.1) usually does not. The failure is skipping the sizing, not the strategy.

Replatform ("lift and reshape"). Move with targeted changes that take advantage of the platform, without rewriting the application.

• The usual moves: put the database on a managed service, put static content in object storage, put the app behind a managed load balancer, containerise without re-architecting, move scheduled jobs to a managed scheduler.
• Modest effort, disproportionate benefit — this is where most of the operational savings actually come from, because managed services remove work permanently.
• The most commonly correct answer in exam scenarios that mention reducing operational burden without a long project.

Refactor (or re-architect). Substantially rewrite for the cloud — break a monolith into services, adopt managed and serverless components, redesign the data layer.

• Highest effort, highest risk, highest potential benefit.
• Justified when the current architecture actively blocks a business need: it cannot scale, cannot deploy frequently, or cannot meet a resilience target.
• Rarely justified purely to be modern, and a scenario stressing a tight deadline is ruling it out.

The curve to hold in mind: effort rises steeply from rehost to refactor while benefit rises too — and the benefit per unit of effort is usually highest at replatform, which is why it is the default recommendation for most estates.

Repurchase and retire as legitimate outcomes of a migration assessment

Two of the standard outcomes are not migrations at all, and forgetting them is a common exam error.

Repurchase. Replace the workload with a SaaS product. The self-hosted email, CRM, ticketing system, wiki or HR system becomes a subscription.

• Removes the workload entirely rather than moving it.
• The work shifts to data migration, integration and change management — which is real work, and the reason this is not always the easy option.
• Strongly indicated when the application is commodity, when it is heavily customised in ways nobody can justify, or when the vendor has already moved to a hosted model.

Retire. Switch it off.

• Every serious discovery exercise finds workloads nobody uses: superseded reporting systems, environments for projects that ended, servers kept "just in case".
• The cheapest possible outcome, and it improves every metric at once.
• Typically 10–20% of an estate in practice, which makes discovery worth doing carefully.
• The discipline is to switch off and wait rather than delete: power down, leave it recoverable for an agreed period, then decommission properly per objective 3.1.

A sixth outcome, retain, is the previous lesson's honest "it stays where it is". Together these give the six standard dispositions: rehost, replatform, refactor, repurchase, retire, retain.

Choosing per workload rather than per estate, and the portfolio that results

The decision is made per workload. An estate-wide mandate — "we are lifting and shifting everything" or "we are refactoring everything" — is wrong in both directions and is a reliable exam distractor.

A simple assessment per workload:

1. Business value and remaining life. Being replaced next year? Retire or retain, never refactor.
2. Technical constraints from the compatibility lesson. Hard blocker? Retain, or repurchase.
3. Is it commodity? If a SaaS product does this, repurchase.
4. Does the architecture block a business need? If yes, and the value justifies it, refactor.
5. Otherwise replatform, taking the managed services that reduce ongoing work.
6. Rehost where the deadline is hard, the workload is stable, or it is a stepping stone.

A realistic portfolio looks roughly like: a meaningful share retired, a few repurchased, most replatformed or rehosted, a small number refactored, and a handful retained. A plan where everything is refactored is not a plan; it is a multi-year programme that will be cancelled.

Sequencing matters too. Start with workloads that are low-risk and instructive — non-production environments, internally-facing systems with tolerant users — so the team learns on something forgiving. Do not start with the crown jewels, and do not start with the hardest thing to prove it can be done.

Online and offline migration, and the downtime each one asks for

Independently of strategy, the mechanism is either online or offline.

Offline. Stop the workload, copy it, start it in the new location.

• Simple, predictable, and the data is consistent because nothing is changing.
• Downtime is the whole transfer, so it is bounded by data size and bandwidth.
• Right for workloads with a tolerable maintenance window, and for very large datasets moved by physical transfer.

Online. Replicate while the source keeps running, then cut over.

• Downtime is only the final cutover — minutes rather than hours.
• More complex: continuous replication, a consistency mechanism, and a cutover procedure. More expensive, and usually requires tooling.
• Right for anything where a long window is unacceptable.

The calculation people skip is how long a bulk transfer actually takes. A useful habit is to work it out explicitly: volume divided by realistic throughput, remembering that available bandwidth is not link speed. Tens of terabytes over a shared internet connection is days, not hours. That sum is what justifies a dedicated circuit (objective 1.3) or a physical transfer appliance — a device shipped to you, loaded, and shipped back — which remains the fastest way to move very large datasets and is a favourite exam answer when the scenario mentions petabytes or a poor connection.

Physical-to-virtual and virtual-to-virtual, and the tooling that performs them

The conversions you will be asked to recognise:

• P2V — physical server to virtual machine. Reads the physical disks and produces a virtual machine, injecting the drivers the new platform needs.
• V2V — virtual machine between platforms or formats, for example from an on-premises hypervisor to a cloud image.
• V2P — the rare reverse, back to physical, usually for a performance or licensing reason.

What actually goes wrong, and what scenarios describe:

• Missing drivers. The converted machine will not boot because it has no driver for the new platform's storage controller. The usual fix is injecting drivers before the first boot; the common symptom is a boot failure immediately after an otherwise successful conversion.
• Boot mode mismatch — legacy BIOS versus UEFI expectations.
• Network reconfiguration. New adapters mean new addresses, and anything hard-coded breaks. This is where the dependency list from the compatibility lesson earns its keep.
• Licence re-activation, because the hardware identity changed — the MAC-bound licensing problem arriving at the worst moment.
• Agents that do not belong, such as backup or monitoring agents pointed at on-premises infrastructure, which should be removed or repointed before cutover.

The providers all ship migration services that handle replication and conversion together, and using the platform's own tooling is usually the right answer over a hand-rolled process — it handles the driver injection, the incremental replication and the test-boot that lets you validate before cutting over.

What to take into the exam

• Rehost = fast, no architectural gain, and it only saves money if you right-size. Replatform = best benefit per unit of effort. Refactor = high effort, needs a business reason, ruled out by tight deadlines.
• Repurchase and retire are real outcomes. Discovery typically finds 10–20% that can simply be switched off.
• Decide per workload. An estate-wide mandate is a distractor.
• Offline = downtime for the whole copy. Online = downtime only at cutover, with replication complexity.
• Do the transfer-time arithmetic. Very large datasets over poor links mean a physical transfer appliance.
• P2V/V2V failures are usually drivers or boot mode, and the symptom is a machine that converts fine and will not boot.