Application rehosting changes the environment in which an application runs while leaving most of the application itself intact. The executable, configuration, and data move to a new hosting target, but the system usually keeps the same major boundaries, dependencies, and runtime behaviour.
What a rehosting move includes
The exact work depends on how the application is packaged and operated. A virtual machine may move as an image, while a physical server may first be reproduced as a virtual environment. Configuration, network access, certificates, scheduled jobs, storage, and monitoring must move with the application or be replaced by equivalent services.
| Area | Usually changes | Usually stays |
|---|---|---|
| Compute | Host, virtual machine, or runtime location | Application process and deployment unit |
| Network | Addresses, routes, firewall rules | Expected ports and communication patterns |
| Data | Storage location and connection details | Schema and ownership model |
| Operations | Provisioning and monitoring integration | Existing runbooks and failure modes |
Minimal code change does not mean no engineering change. Environment-specific assumptions may be embedded in file paths, host names, authentication methods, or deployment scripts. A dependency graph helps expose those assumptions before the move.
Evidence needed before the move
A legacy codebase audit records the application boundary and every resource needed to run it. The migration team needs evidence from configuration, deployment history, runtime logs, and people who operate the system.
A practical inventory covers:
- Runtime requirements: Operating system, language runtime, services, and installed libraries.
- External connections: Databases, file shares, message brokers, identity providers, and outbound services.
- Operational work: Backups, scheduled tasks, monitoring, alerting, and recovery procedures.
- Traffic and state: Entry points, persistent data, session state, and maintenance windows.
- Verification: Health checks and business transactions that prove the moved system works.
These checks define what must be available at cutover and what must be tested afterwards.
What rehosting does not change
Rehosting can remove a hardware or hosting constraint, but it does not by itself change the application's internal structure. Tight coupling, obsolete libraries, undocumented rules, and fragile release processes remain unless the migration addresses them separately. The new environment may also expose assumptions that the previous host happened to satisfy.
Application Replatforming makes bounded changes to the runtime or platform during the move. Application Rearchitecture changes the application's structure and responsibilities. Rehosting is distinct because it keeps those questions outside the immediate infrastructure transfer.
How it fits a modernization plan
Rehosting can be a complete outcome when the application is stable and the hosting constraint is the main problem. It can also be an intermediate state that creates time for later work. The plan should name which outcome applies, because a temporary landing point and a long-term operating model require different follow-up work.
The decision belongs in a migration sequence with explicit dependencies, verification steps, and ownership. That keeps an infrastructure move from being mistaken for structural modernization and connects the move to the broader work of taking over a legacy codebase.
