An inherited application rarely arrives with one neat problem. It arrives with slow screens, difficult deployments, uncertain dependencies and a team that has learned to avoid particular parts of the code. Replacing everything can feel like the cleanest answer because it postpones those questions to a new project.
A more useful first move is to choose a small, valuable workflow and make it safe to change. That produces evidence about the system and the delivery approach before the business commits to a wider replacement.
Choose a business boundary
A good first slice has a recognisable beginning and end. “Improve the backend” is too broad. “Let the operations team correct a customer reference without editing a database” is a workflow that someone can demonstrate and accept.
Look for a task that is frequent enough to matter, painful enough to justify work and bounded enough to understand. Avoid making the first slice depend on replacing authentication, billing and every shared table at once.
For a hypothetical service business, a manual export might be a better starting point than the entire customer portal. You can learn how data is assembled, where permissions are enforced and what downstream teams expect without immediately changing every customer-facing screen.
Record the existing behaviour
Before redesigning the workflow, observe it. Capture representative inputs, outputs, error cases and the decisions staff make around the software. Ask which odd-looking behaviours are deliberate workarounds for real constraints.
Separate a behaviour that must be preserved from one that the business wants to change. An old report may have an obscure column because another department imports it. Removing that column as “cleanup” can break a process outside the application team's view.
Build a small set of acceptance examples that the business can review. These examples become a shared reference when the old code and the new implementation disagree.
Put an interface around the change
Decide what the new slice reads, what it writes and which system remains authoritative. A replacement screen is easier to manage when it uses an explicit interface instead of reaching unpredictably into old tables and side effects.
Where data must be written to more than one system, define how partial failure is detected and repaired. Do not quietly add a second copy of the truth and assume the copies will remain aligned.
The implementation can still be pragmatic. An adapter around an existing service may be enough for the first step. The purpose of the boundary is to make responsibilities visible, not to create a new platform for its own sake.
Release with a comparison plan
Decide who will use the new workflow first, how you will recognise a bad result and what can be reversed. A small group of internal users may provide a safer first release than immediately replacing a public journey.
Compare the output with the accepted examples and watch the support questions. If a task becomes faster but users cannot recover from an error, the slice needs more work before it becomes the pattern for everything else.
Use what you learn to price and plan the next stage. Some parts may deserve replacement; others may be stable enough to keep. Our legacy modernisation work focuses on that practical route from an inherited system to software the business can change with confidence.