A monolith for citizen casework is redesigned into microservices and managed services to gain cloud-native scalability. Which migration strategy is this?
Select an answer to reveal the explanation.
Short Explanation
Re-architect is tearing down interior walls to build something that actually uses the new building's strengths — microservices, managed services, cloud-native scale. That is deeper than parking the old monolith on a bigger VM. Big structural change for cloud benefit equals re-architect.
Full Explanation
Re-architecting redesigns application structure—often decomposing a monolith into microservices and adopting managed services—to exploit cloud elasticity, resilience, and operability. Redesigning a citizen casework monolith that way is re-architect, not a light move. Rehost the unchanged monolith onto a single large VM fails because the stem describes significant structural change, not lift-and-shift. Retire the casework system fails because a redesigned system is being built rather than removed. Retain the monolith on-premises indefinitely fails because redesign for cloud-native scalability is underway. Exam caveat: pick re-architect when the stem emphasizes microservices, managed services, and structural change to gain cloud benefits; do not dilute it into replatform when the change is transformational. Operational check: establish service boundaries, data ownership, and inter-service SLAs; deploy progressive delivery for civic casework paths; and measure scalability under peak filing periods before retiring monolith nodes. 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.