Application replatforming changes part of an application's technical foundation without redesigning the whole system. The application moves to a new platform and adapts where necessary, but its main business capabilities, user-facing behaviour, and large-scale boundaries remain recognizable.
What changes during replatforming
A replatforming project has a defined technical target. It may replace an unsupported runtime, move a database to a managed equivalent, package an application for a different deployment system, or adopt a supported operating system. Each change requires compatibility work, but the project does not use the move as a reason to redesign unrelated parts.
| Platform area | Possible change | Compatibility evidence |
|---|---|---|
| Runtime | Supported language or framework version | Build and automated test results |
| Database | Managed engine or supported edition | Schema, query, and transaction checks |
| Deployment | New package or container format | Repeatable deployment and rollback |
| Operations | Platform-native logging and monitoring | Alerts, dashboards, and recovery test |
The boundary between platform work and product work should be explicit. A change that alters business rules, service ownership, or user workflows has moved beyond replatforming.
How an audit defines the boundary
A legacy codebase audit identifies dependencies on the current platform. Some are declared in build files and configuration. Others appear only in runtime behaviour, database features, file-system assumptions, or operational scripts.
The audit should record:
- Supported targets: Platform versions that can run the application and its dependencies.
- Incompatible features: APIs, database functions, drivers, or tools absent from the target.
- Required adaptations: Code and configuration changes limited to platform compatibility.
- Operational changes: New deployment, monitoring, backup, and access procedures.
- Acceptance checks: Behaviour and performance evidence needed before cutover.
This inventory prevents a supposedly small platform move from hiding an unplanned redesign.
Replatforming compared with other strategies
Application Rehosting aims to move the system with minimal application change. Replatforming accepts specific changes to use the target platform. Application Rearchitecture goes further by changing component boundaries, data ownership, or interaction patterns.
These strategies can appear in one programme at different scopes. A stable reporting component may be rehosted, a supported database may be replatformed, and a tightly coupled workflow may need rearchitecture. The classification matters because each scope produces different estimates, tests, and rollback conditions.
What the migration plan must preserve
Replatforming still requires behavioural continuity. Interfaces, scheduled work, data meaning, security controls, and failure handling must be checked on the target platform. Where the target behaves differently, the plan must distinguish an intentional platform adaptation from an accidental change.
The work becomes manageable when each adaptation has a reason, an owner, and a verification method. That discipline connects a platform decision to the practical cost of moving and maintaining legacy software, rather than treating the new platform as proof that the application itself has been modernized.
