The inspection app keeps most of its code but swaps self-managed MySQL for a provider-managed database. Which migration strategy best describes this?
Select an answer to reveal the explanation.
Short Explanation
Replatform is a light remodel — keep the house layout, swap the furnace for a managed one. Most code stays; MySQL becomes a provider-managed database. That mid-step between pure lift-and-shift and a full rewrite is replatform.
Full Explanation
Replatforming adopts managed cloud services with only modest application change while preserving most of the existing codebase. Swapping self-managed MySQL for a provider-managed database on an inspection app while keeping most code is a classic municipal replatform move: cloud benefit without a full rewrite. Rehost with zero service changes, still running self-managed MySQL on cloud VMs, fails because a managed database swap is a deliberate platform change beyond pure lift-and-shift. Retire the inspection app and delete its database fails because the workload continues with a replacement data service. Retain MySQL forever on-premises with no cloud database involvement fails the migration action described. Exam caveat: Cloud+ distinguishes rehost (same stack, new location) from replatform (limited cloud service substitution) from re-architect (major structural change)—managed database adoption usually signals replatform. Operational check: prove dump/restore or replication cutover, validate connection string and TLS settings, test backup/restore in the managed service, and update runbooks for the civic DBA team that no longer patches MySQL VMs. In municipal platform operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand the failure modes avoided for citizen services. Re-check the decision after the next provider feature change or compliance update to ensure the same answer still holds for the city's estate.