Contents
A difficult codebase does not automatically need replacing, and a familiar system does not automatically deserve preserving. Separate the behaviour the business needs from the implementation that currently provides it. Then compare options against the same outcomes, constraints and operating responsibilities.
Be precise about the proposed change
Martin Fowler defines refactoring as restructuring software internally while preserving its observable behaviour. A change to the business workflow or feature set is therefore a separate product decision, even if it is delivered alongside internal restructuring.
Ask a team proposing a rebuild to define its boundary. Does it mean replacing one component, introducing a new interface or moving every user and record to a new application? Those are different programmes. Name the parts that will remain and the connections that must continue to work.
Assess business fit and technical constraints separately
List the workflows the business still needs and the behaviour that should change. Involve people who handle exceptions and administration, not only the most visible users. Record requirements that the existing system satisfies quietly, such as reconciliation or approval history.
Separately, identify the technical obstacles to the next changes. Ask what evidence shows that a constraint cannot be addressed within the current implementation. If the assessment depends on an unfamiliar part of the system, investigate it before making replacement the default answer.
Examine a bounded improvement option
Choose a representative change and ask what would make it easier to deliver safely. The answer might be clearer module boundaries, better understanding of a calculation or a reliable set of checks around a workflow. Define the behaviour that must be preserved and demonstrate it before and after the intervention.
Assess whether the resulting boundary creates a useful next step. A small change is valuable when it reduces a real obstacle or establishes evidence for the next decision. Avoid dividing work into small tasks that leave the product unusable until an undefined final integration effort.
Evaluate replacement as a migration programme
A replacement needs a plan for data, users, integrations and operation. Identify which records move, how their meaning is preserved and who accepts the migrated result. Decide what happens to work in progress during transition and how the old and new systems stay consistent if both operate temporarily.
Define the cutover and recovery arrangements. A fallback that depends on moving updated data back into an incompatible old system needs investigation, not a sentence saying rollback is available. Include training, support and the eventual retirement of the old application in the scope.
Compare options and set a review point
Compare the smallest useful improvement, staged replacement and broader rebuild against the same required outcomes. Include the cost of keeping the existing service running while the work takes place. Identify dependencies, uncertainties and the people needed to resolve them.
Record why the chosen option is preferable and what evidence could change that decision. If a key assumption is unresolved, commission a bounded assessment or rehearsal. The result should support a concrete next commitment rather than merely restating that the system is old or complicated.
Compare refactoring and rebuilding the same workflow
Imagine a fictional booking system with useful customer records and a reliable payment connection, but pricing rules copied across three places. Option A keeps those working parts and refactors pricing behind one tested interface. Option B replaces the booking platform and migrates all records. A must demonstrate unchanged booking behaviour; B must demonstrate correct migration, payment compatibility, staff training and recovery at cutover.
Use a comparison sheet with preserved capability, required changes, unknowns, transition work and acceptance evidence. For A, the decisive unknown is whether the existing boundaries allow a safe isolated change. For B, it is whether the replacement can reproduce the essential rules and history. Inspect one difficult booking in each approach, including a correction after payment. An attractive new interface does not answer either question.
Choose a trial before a full commitment: capture expected results from controlled bookings, exercise a small refactoring boundary and test a representative export in the replacement. If A cannot be isolated safely, update its estimate. If B loses necessary history, resolve that before calling it simpler. Fowler’s refactoring reference concerns changing internal structure while preserving observable behaviour; a changed business workflow needs its own acceptance decision.
How this relates to Veda Software’s work
Encounter illustrates a broader move from paper processes to a digital product. It is adjacent evidence about workflow change, not a claim that a particular codebase was refactored or rebuilt.