When Not to Modernize an Application Already on AWS
Quick summary: Five stop conditions, checked 4 October 2026. If the SLO is met and the only pain is a bill, modernization is the wrong program. Continue only when change rate, a seam, or a renewal forces it.
Key Takeaways
- Five stop conditions, checked 4 October 2026
- A portfolio review on 4 October 2026 had five applications in a modernization wave
- This page is the stop, for estates already on AWS
- Then go to the serverless playbook or the Transform capability branch, not back to this checklist
- Where this fails > What broke — Lab, 4 October 2026
Table of Contents
A portfolio review on 4 October 2026 had five applications in a modernization wave. Two of them met their SLO. Nobody in the room could name a seam, a renewal, or a change rate. The wave existed because the slide said “modernize.”
The migration strategy post already explains Retain for staying on-premises. The refactor post chooses a path once you are modernizing. Scale-in-place says not to split a monolith that can still scale. The ROI post is the board narrative after you have a reason. This page is the stop, for estates already on AWS. It has no R matrix.
Reproduce this — Copy the stop-rule checklist. One application per copy. If any stop row is true, take it out of the wave.
Stop
Stop the program when any of these is true:
- Remaining life is shorter than the program. A system with a dated retirement does not need a new runtime to reach that date.
- The SLO is met. Modernization is not a reward for a quiet on-call.
- The team cannot absorb the change. A design that needs a team you do not have is a slide.
- The license is already clean. Do not open an engine project because a neighbor application has a renewal. The Oracle and SQL Server decision is for the renewal that is real.
- The only pain is a bill. Rightsizing and the post-migration FinOps handoff own that pain. This page does not invent a savings number.
We recommend leaving the application in place when a stop row is true. The trade-off is that a later seam will cost more to open. Take that trade when nothing is forcing the change. “We might need it” is not a force.
Continue
Continue only when one of these is true: the change rate is already hurting delivery, an integration seam is the actual project, or a renewal date is on the calendar. Then go to the serverless playbook or the Transform capability branch, not back to this checklist.
Where this fails
What broke — Lab, 4 October 2026. Not a customer account. The review marked a stable internal tool for a rewrite because its EC2 bill was visible. Detection: the checklist’s bill row was true and every continue row was false. Recovery: remove it from the wave and send the bill to FinOps. Lesson: a modernization program that starts from a cost explorer graph is the wrong tool.
What to Do This Week
- List the applications in the proposed wave. Score each one on the five stop rows.
- Remove every application that hits a stop and has no continue condition.
- For a bill, open the FinOps path. Do not open a design doc.
- For a real renewal or a real seam, leave this page and open the article that owns that decision.
- If the remaining wave is large enough to be the engagement, talk to application modernization.
What This Post Doesn’t Cover
It does not explain the 7 Rs, rank refactor against replatform, calculate ROI, or design a strangler. Those pages exist. Linking them is the point of this one.
Frequently asked questions
When should we leave an application alone?
When should we not treat Retain as this decision?
What could go wrong if we modernize because the bill is high?
Does scale-in-place already say this?
Where does a renewal fit?
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
