A county finance ERP on aging on-premises hosts shows chronically high change-failure rates and fragile release processes. During portfolio selection, which 7R direction should architects favor instead of a blind rehost?
Select an answer to reveal the explanation.
Short Explanation
Lifting a wobbly filing cabinet into a nicer building does not stop the drawers from falling out. If change-failure is already ugly, choose replatform or refactor at selection time—don't just rehost the mess.
Full Explanation
A county finance ERP on aging on-premises hosts with chronically high change-failure rates and fragile release processes should not be blindly rehosted during portfolio selection. Favor replatform or refactor so reliability improves rather than lifting fragility unchanged into AWS. That 7R direction treats migration as an opportunity to reduce municipal change risk for payroll and ledger integrity. Retaining the ERP forever and canceling any AWS landing-zone work for finance fails continuous improvement and freezes a failing change system. Rehosting the identical brittle stack to a single EC2 instance with no platform changes fails the reliability goal by relocating the same failure modes and fragile releases. Relocating the ERP to another vendor's data center without addressing change-failure root causes fails because geography change is not architecture improvement. Exam caveat: high change-failure workloads often warrant replatform or refactor over naive rehost. Operational check: baseline change-failure and lead-time metrics, choose replatform targets such as managed databases and CI/CD hardening or a bounded refactor scope, keep landing-zone work alive, and gate go-live on improved deployment controls for finance.