Managed Service Substitution
Replacing a self-managed component with a managed equivalent during migration, without changing the application's architecture.
Replatforming makes targeted changes that remove a disproportionate operational burden while leaving the application's structure alone. The archetypal move is a self-managed database to a managed one.
Why it is frequently the best value in a migration programme: the operational cost of a self-managed data store — patching, backup and verified restore, high availability, upgrades, capacity, on-call — is substantial and invisible, expressed in engineer-days rather than invoices. Removing it changes the economics without touching application code.
Other high-return substitutions: a self-hosted message broker for a managed one; a hand-built deployment pipeline for a managed service; a self-managed identity component for a provider; and container orchestration moved from self-managed to managed control plane.
The costs to weigh honestly: maintenance windows and forced upgrades on someone else's schedule, which must be designed for rather than discovered; feature and version differences from the self-managed original, which is where migrations of long-lived databases hit friction; and exit cost, which is higher than the self-managed equivalent.
The sequencing point: replatforming is best done as part of the migration rather than afterwards, because the application is already being tested and cut over, and doing it twice doubles the verification effort.