When a system has been around for years, a rebuild can sound like the obvious answer. Yet one team may struggle with an awkward screen, another may copy figures between tools, and a third may depend on a feature the vendor no longer supports. Those are different problems.
Find the work that is blocked
Ask regular users to complete a common task while you watch. Is the information hard to find, repeatedly entered or impossible to update? Note how often it happens and who it affects. That helps separate interface problems from missing features and disconnected data.
If reports disagree, a new screen alone will not fix them. The sources may use different definitions or update at different times. First decide which record is authoritative.
Keep the parts that still work
A rebuild is not the only option. A system that reliably handles sales can stay in place while new tools support replenishment or stock enquiries. In CodeCraft's anonymised retail project, the existing POS remained while operational tools were added in stages.
Adding a tool still creates responsibilities. Decide which system owns each piece of data, how often it updates and who handles failed synchronisation. More tools without clear ownership can make daily work harder.
When replacement deserves serious consideration
Replacement becomes more likely when code cannot be safely changed, support is no longer available or a security issue cannot be addressed in place. Even then, it need not mean switching every function on the same day.
Data migration, dependencies and continuity during the switch often need answers before screen design. For a system used every day, allow time to reconcile records as work moves across.
Choose the next change, not a slogan
List the few issues causing the most disruption and consider whether each part should stay, be connected, be extended or be replaced. Different parts of one system can have different answers. Follow the work and its data before choosing the size of the change.