Rehosting, replatforming, refactoring, and rewriting are modernization strategies distinguished by what they change. They are not four effort estimates or four successive stages through which every application must pass.
Rehosting changes where an application executes. Replatforming changes selected supporting platform services. Refactoring changes internal structure while preserving observable behavior. Rewriting creates another implementation of required behavior. A programme can combine these strategies, but each changed boundary still needs its own acceptance evidence.
Rehosting changes execution location
A rehost retains the application while moving its execution to another environment. In cloud migration terminology, this includes moving an application to cloud infrastructure without changing the application itself.
The retained code does not make the new environment identical. Identity, network routes, storage, attached devices, and scheduled execution can change around it. A successful boot establishes less than a completed business workflow with working recovery.
Suppose an application calls a file share through a mapped drive established in a user’s session. Moving the executable to a server does not recreate that session or its path mapping. The application change is small or absent; the deployment dependency remains decisive.
Replatforming changes platform behavior
A replatform replaces selected runtime, database, or infrastructure services while retaining substantial application logic. Moving storage to another database service is one candidate. The important question is which behavior the application previously obtained from the old platform.
Queries, transaction handling, administrative privileges, file access, and operational procedures form part of that boundary. If the target lacks a required behavior, the application or its operation must change. Replatforming therefore does not imply a universally small amount of code work.
Its result is an application operating against a changed platform contract. Acceptance must demonstrate required behavior through that contract, including the difficult dependency rather than only the easiest request.
Refactoring preserves an observable contract
Refactoring, in the software-engineering sense, restructures existing software without changing its observable behavior. Extracting repeated logic or introducing an internal abstraction can reduce a named maintenance difficulty while callers continue to receive the same results.
A deliberate behavior correction is a separate change. If a calculation currently produces an incorrect result, preserving behavior and fixing that result are different objectives. Combining them without recording the distinction makes a comparison failure ambiguous.
Cloud strategy taxonomies also use refactor to include rearchitecture. The context must therefore accompany the label. A statement of work that says only refactor has not established whether behavior-preserving restructuring or a different application architecture is intended.
Rewriting reimplements required behavior
A rewrite constructs a new implementation from requirements recovered through source, observed operation, records, tests, and business knowledge. Resemblance to the original source is not its acceptance criterion. The required outcomes and deliberate changes are.
The uncertainty lies partly in deciding what the old system actually does and which of those behaviors remain necessary. Generated code does not resolve a missing requirement. A plausible implementation can encode an unverified assumption as efficiently as a verified rule.
Rewriting also leaves a transition problem. Old and new implementations need defined responsibility for requests, data, and external effects during coexistence or cutover. Completing the new code does not retire the old dependencies.
Strategies are descriptions of change
Take an application whose tables move to another database while its forms remain. That storage intervention is a replatforming boundary even if selected queries require rewriting. Later restructuring of those forms can be refactoring, while replacement of the user interface creates another implementation.
The useful description states which parts change, which required behaviors remain fixed, and how the result will be demonstrated. The strategy name compresses that description. It cannot substitute for it, establish a budget, or rank the alternatives without evidence about the deployed system.