The starting point
A dated interface or a difficult release can make starting again feel attractive. Before replacing the product, separate what is frustrating from what is still valuable. The business rules, integrations and everyday habits around an application deserve as much attention as the screens you want to change.
Describe the problem before choosing a rebuild
Ask the people using and maintaining the product to describe a recent difficulty. Was a task hard to complete, a small change hard to release, or information unavailable when someone needed it? These are different problems, and they may not share the same solution.
Record the affected journey, who experiences the issue and what an improvement would look like. Keep observations separate from assumptions. A preference for a newer framework is not, by itself, a clear reason to replace working software.
Understand what must keep working
Map the records, permissions and connections behind the journey. Include less-visible dependencies such as scheduled reports, exports, third-party tools and manual steps that people use to fill gaps. Ask who owns each dependency and who can confirm that it still works after a change.
Collect representative examples in an appropriate test environment. Capture the behaviour that needs to remain intact, including unusual cases. This gives the team something more useful to check against than a broad instruction to make the new version work like the old one.
Choose a contained change with a clear boundary
Compare a focused interface improvement, a change to one workflow and a broader replacement. For each option, consider the dependencies it touches, the uncertainty it leaves and the transition work it creates. Start with the smallest scope that meaningfully addresses the agreed problem—not simply the easiest screen to redesign.
A first increment might improve one complete request journey while retaining the existing records and integrations. Use it to test the proposed direction and expose assumptions before expanding. Write down what remains unchanged so everyone understands the boundary.
Plan the transition, not just the implementation
Discuss how people will move to the changed experience. Depending on the application, that may include a trial migration, updated help material, a release window or a period where old and new parts coexist. Agree these decisions with the people responsible for operating the product.
Define the checks needed before and after release, the person authorised to proceed and the response if something goes wrong. A rollback may also need a plan for information created after the change. Keep those recovery questions visible rather than assuming that deploying the old code will reverse everything.
Put the thinking into practice
Ready for your next step?
