| Author: Abdullah Ahmed | Category: Software Consulting
A pricing change that should take a day now takes a week because the same calculation appears in several places. The application still supports the business, and its data model remains useful. Rebuilding it might remove the duplication, but it would also require recreating many behaviours that are not causing the current problem.
Refactoring can be the better choice when the existing software is functionally suitable and the main constraint is its internal structure. Rebuilding becomes more plausible when the required behaviour, underlying model, or operating constraints no longer fit. The decision needs evidence about the actual system and a fair comparison of transition costs.
Distinguish structural change from new behaviour
Refactoring improves internal structure while preserving externally observable behaviour. Martin Fowler's refactoring resources describe this discipline and its relationship to small, controlled transformations. A project can combine refactoring with feature changes, but the team should keep the intentions distinguishable.
Rebuilding creates a replacement implementation, often with opportunities to change behaviour or technology. It still requires discovering what the old system does, migrating data, coordinating users, and retiring dependencies. Those activities can dominate the transition.
Modernisation is a broader category. Updating a runtime, replacing a module, improving deployment, or redesigning a workflow may involve refactoring, replacement, or both. Avoid letting one label determine the plan before the problem is understood.
State the immediate constraint clearly. If a calculation is duplicated, investigate consolidation. If the business model has changed fundamentally, examine whether the existing domain model can support it. These are different starting points.
Look for evidence that the current behaviour remains valuable
Interview users and operational owners about what works. A system may be unpopular with developers while reliably handling complex exceptions that a replacement estimate overlooks. Preserve those useful capabilities in the decision analysis.
Trace important workflows and identify where the business actually wants change. If most behaviour remains suitable, a targeted structural improvement may deliver value with less transition. If staff routinely work around the application's core assumptions, a broader redesign may deserve attention.
Review support cases and requested changes. Repeated difficulty modifying one area can point to a bounded refactoring opportunity. Problems scattered across incompatible data and workflow models may suggest a deeper limitation.
Do not assume old means unsuitable. Age can correlate with maintenance problems, but the decision should identify the specific support, structure, or capability constraint. Likewise, recent software can still require significant restructuring.
Assess the shape of technical debt
Ask the team to show examples of duplicated rules, tangled dependencies, missing boundaries, or fragile tests. Describe how each affects delivery or reliability. A general statement that the code is messy is not enough to estimate useful work.
Identify the areas that change frequently. Improving a stable module that nobody needs to touch may offer less value than clarifying a small but heavily used pricing or permission component. Prioritise according to expected future work.
Look at dependency direction. If a business calculation relies directly on interface state or external service calls, separating those responsibilities may make testing and change easier. The proposed refactoring should name the boundary it intends to create.
Check whether the difficulty is actually operational. Unreliable deployment, missing environments, or undocumented configuration can make every code change feel risky. Improving those capabilities may be the right first investment.
Create evidence before changing important code
Capture representative inputs and outputs for the behaviour being preserved. Include ordinary cases, edge cases, and known historical rules. These examples help reveal accidental differences during structural work.
Characterisation tests can record existing behaviour even when it is surprising. Label known issues clearly. If the business wants to correct a rule, make that a separate reviewed decision rather than silently changing it during cleanup.
Choose the test level according to the risk. A calculation may benefit from focused tests, while a workflow may need an end-to-end example. Avoid writing tests that merely repeat implementation details without protecting a meaningful outcome.
Establish a reproducible environment and a recovery path for deployment. A good test suite does not remove the need to understand data changes and production configuration. Refactoring should proceed within a delivery process the team can operate.
Use a small change to test feasibility
Select a bounded area with clear value, such as consolidating a repeated discount calculation or isolating an external integration adapter. Define the expected structural improvement and the behaviour that must remain unchanged.
Estimate and perform a small initial slice. Observe how much hidden coupling appears and whether the new boundary helps. This provides better evidence for a larger refactoring plan than a broad estimate made before anyone examines the dependencies.
Have another developer use the improved area for a representative change. Can they understand it, run relevant tests, and identify the intended extension point? The result should improve ordinary delivery, not merely satisfy the original author's preferences.
Record what the experiment implies for the next step. If the boundary is workable, continue incrementally. If the work exposes a fundamentally unsuitable model, use that evidence to reconsider a replacement strategy.
Recognise when rebuilding deserves serious consideration
A replacement may be justified when the core data model cannot support the business's new requirements at reasonable cost. Examples might include a system built around one organisation that now needs true tenant isolation, or a workflow model that cannot represent essential new states.
Unsupported infrastructure or dependencies can also constrain options, but verify the actual support situation and migration routes. An upgrade or partial replacement may be feasible. Do not equate a difficult dependency update with proof that every feature must be rewritten.
Consider whether the existing system can be tested and changed safely enough to reach the required outcome. If every useful increment requires invasive change across the application, the transition cost of refactoring may approach or exceed a well-scoped replacement.
Even then, compare options through investigation. A rebuild should have a defined target, migration plan, and acceptance evidence. “Start clean” is an understandable desire, but it is not a complete business case.
Compare the complete cost of transition
For refactoring, include investigation, safety tests, implementation, review, deployment, and any temporary compatibility work. For rebuilding, include discovery, replacement features, migration, integrations, training, parallel operation, and retirement.
Account for continued business change. The old system may need fixes while the replacement is built. Decide how requirements and data changes are tracked so the new implementation does not chase a moving target without control.
Include internal participation. Experienced users and domain experts may be needed to explain obscure rules and validate results. Their time is part of the transition regardless of whether the code is reused.
Use ranges and assumptions where evidence is incomplete. A precise rewrite estimate that ignores undocumented behaviour is not stronger than a cautious refactoring estimate that acknowledges uncertainty.
Preserve data meaning through either approach
Structural code changes can affect how stored records are interpreted. Review identifiers, status values, rounding, dates, and historical defaults. A refactoring that preserves current screens may still alter an export or background calculation.
A rebuild adds migration concerns: mapping old records, resolving duplicates, preserving relationships, and validating totals. Decide which historical information must remain available and how users will access it.
Rehearse with representative data volumes and difficult records. A small clean sample can conceal performance and transformation problems. Protect sensitive information appropriately in test environments.
Define rollback limits. Once a new implementation writes data the old one cannot understand, switching code back may not be enough. The transition plan needs a deliberate response to that boundary.
Consider replacing one capability instead of everything
A problematic module can sometimes be isolated and replaced while the rest of the application continues operating. This may preserve useful behaviour and reduce the size of the migration. The boundary must be clear enough to manage ownership and data flow.
The Strangler Fig pattern describes gradual replacement through a controlled boundary. It is an option to evaluate, not a guarantee that every legacy application can be separated cheaply.
Keep temporary coexistence costs visible. Adapters, routing rules, duplicate monitoring, and support documentation need maintenance. Plan their retirement so the application does not become permanently more complicated.
Choose independent deployment only when it serves the boundary. A well-structured module inside the existing application may be sufficient. Network separation brings additional operational obligations that should have a business reason.
Work through the pricing example
Suppose discounts are calculated in checkout, an administrative order screen, and a nightly invoice job. The business wants the same existing rules applied consistently. This is a promising refactoring candidate if the rules can be captured and separated.
Collect examples covering ordinary discounts, excluded products, rounding, and historical exceptions. Confirm the intended existing behaviour with the relevant owner. Differences between the three implementations need an explicit decision before consolidation.
Create one calculation boundary and move consumers incrementally. Compare outputs and retain targeted tests. Avoid simultaneously changing the pricing policy unless that change is separately specified and reviewed.
Then implement a small new pricing requirement through the shared boundary. If the change is easier to understand and verify, the refactoring has demonstrated practical value. If hidden dependencies remain, use the result to refine the next increment rather than claiming the whole application is solved.
Use a decision record that can be revisited
Record the problem, options, expected outcomes, assumptions, transition costs, and evidence supporting the choice. Include the conditions that would cause reconsideration, such as a failed boundary experiment or a newly confirmed business requirement.
Distinguish committed work from exploratory work. A short feasibility exercise does not need to imply approval for a complete rewrite. Clear decision stages help leadership manage uncertainty without blocking useful investigation.
Have business and technical owners review the record together. Developers understand implementation constraints; operational staff understand the consequences of changing behaviour. The choice needs both perspectives.
Keep the record concise enough to use during later planning. Its purpose is to explain why a path was chosen and what evidence could change it, not to preserve every discussion.
Measure the outcome after the change
For refactoring, assess the ability to make relevant changes, defect patterns, test clarity, and reliance on individual experts. Use actual examples and avoid promising a universal productivity improvement.
For rebuilding, measure adoption, migration accuracy, operational reliability, and the intended new capability. Launch alone does not establish that the business has moved successfully or that the old system can be retired.
Review new ownership costs. A technically elegant replacement can require more services or specialist support. A refactoring can introduce new abstractions that need explanation. The organisation should understand what it now owns.
Close the transition deliberately. Remove obsolete code or routes after verifying their consumers, update documentation, and confirm who supports the finished arrangement. Cleanup is part of completing the investment.
Separate feature pressure from structural repair
A refactoring effort can lose focus when every nearby feature request is added to it. Keep the behaviour-preserving work visible and explain which future changes it enables. This makes review easier and helps the team identify the cause of any unexpected difference.
Coordinate with the product backlog. If a new feature depends on the improved boundary, sequence the work so the structural change can be verified before the feature alters its behaviour. Small steps provide clearer evidence than one large mixed change.
Do not promise that refactoring removes all future complexity. Business rules can remain complicated because the business itself is complicated. The goal is to make that complexity explicit and manageable, not hide it behind abstractions that only the author understands.
Use naming and documentation to preserve intent. A historical exception may need a comment explaining its business reason and a test demonstrating it. Removing apparent duplication without understanding that reason can change behaviour accidentally.
Protect continuity when knowledge is concentrated
If one person understands the application, include knowledge transfer in the first phase. Pair investigation with another maintainer, record representative workflows, and make setup reproducible. A rewrite does not automatically recover knowledge that was never captured.
Ask the specialist to explain difficult operational cases, not only the code structure. They may know why a scheduled job runs at a particular time or why a record cannot be deleted. Those details belong in the acceptance and ownership material.
Have the second maintainer perform a small change using the new documentation and tests. Their questions reveal gaps that the original expert may not notice. This is useful evidence whether the eventual plan is refactoring or replacement.
Keep access under organisational control. Source repositories, deployment accounts, backups, and external services should not depend on one personal account. Continuity improvements can begin before the larger architecture decision is complete.
A bounded knowledge-transfer exercise can reduce the risk of either option. It also gives leadership a clearer picture of what is known, what remains uncertain, and which assumptions need further investigation.
Agree on the first review point
Set a review after the bounded experiment rather than committing to months of structural work in advance. Bring evidence of preserved behaviour, reduced coupling, and the effort required for a representative change. Identify any new constraints discovered during the work.
The decision can be to continue, consolidate, or investigate replacement. Keeping that choice explicit helps both technical and business stakeholders support useful maintenance without treating the initial recommendation as irreversible. It also prevents a successful small refactoring from being stretched into an unsupported promise that every part of the application can be improved just as easily.
Choose the smallest change that can meet the need
Begin by asking whether the current behaviour and data model still serve the business. If they do, investigate a bounded refactoring around the constraint that slows useful work. If they do not, compare a targeted replacement and a broader rebuild using the same complete scope.
Make the first commitment an evidence-producing step: a dependency map, behaviour tests, or a small boundary experiment. That turns an emotional debate about old code into a practical decision about delivery and ownership.
Refactor when preserving the working system is an advantage and its structure can be improved safely. Rebuild when the required change justifies the full transition. In either case, choose through observable requirements and a recovery plan the business can understand.
Author
With over 15 years of diverse experience spanning front-end and back-end development, UI/UX design, project management, integration, testing, and ongoing support for business applications, I specialize in transforming ideas into seamless digital solutions. I’m committed to leveraging my expertise to drive innovation and contribute meaningfully to the tech community.