Every modernization conversation reaches the same fork. The system works, the business has outgrown how fast it can change, and there are three credible things to do about it. Which one is right is an empirical question, and it is usually decided on temperament instead.
Replatform: the infrastructure is the constraint
Move the workload to a modern runtime without materially changing the application. Appropriate when the business logic is sound and well understood, the constraint is operational (scaling, deployment, hosting cost, an expiring data-center lease), and the change history shows the code is not being modified much anyway.
It is the cheapest option and the one most often dismissed unfairly. It is also the one most often chosen for the wrong reason, which is that it looks like the low-risk option on a slide.
Refactor: the structure is the constraint
Keep the logic, restructure the code. Appropriate when the domain model is still correct but the implementation has accumulated coupling that makes every change expensive and every release risky.
Refactoring is only viable with test coverage. Without it you are rewriting behavior you cannot verify, which is a rebuild that nobody agreed to fund. If coverage is absent, building characterization tests first is the actual first phase, and it should be planned as such.
Rebuild: the model is the constraint
Justified when the business process the system encodes has genuinely changed. Not when the code is ugly, and not when the current team did not write it.
The honest test: can you articulate a business capability the current model cannot represent at any reasonable cost? If the answer is a list of technical grievances rather than a capability gap, the case is for refactoring.
The evidence to gather first
These questions are answerable in a few weeks, and answering them changes the decision often enough to be worth the delay.
- Change history: which files change, how often, and by whom. Churn concentrates in a small part of most systems.
- Test coverage, honestly measured, on the parts that actually change.
- Dependency profile: what is unsupported, what is Windows-only, what has no upgrade path.
- Integration inventory: what consumes this system, and what contract are you obliged to keep.
- Data quality and volume, because migration effort is usually underestimated by a wide margin.
- Whether the business process itself is changing, which is the only argument that justifies a rebuild.
It is rarely one answer
Large estates usually warrant all three at once: replatform the stable periphery, refactor the parts that change weekly, rebuild the one capability the model can no longer express.
Applying a single strategy uniformly across an estate wastes money in both directions, and it is the most common reason modernization programs cost more than the business case allowed for.
Discuss a modernization program
If this describes something you are working through, we can talk it through against your specific environment.