A web project that works but is slowing everything down. Code that nobody quite understands anymore. An application that runs in production but that nobody dares to touch. These situations are common, and they all raise the same concrete question: do we carry this forward, or do we start over?
The honest answer is: it depends — but not on what most people think. It depends less on how old the code is than on how readable it is, how testable it is, and how clearly the current requirements are understood. This article covers how to approach that evaluation without rushing into a full rewrite that may not have been necessary.
What technical debt actually means
Technical debt is not a moral failing. It is the accumulation of compromises accepted over time: a feature built quickly because the deadline was fixed, a dependency left unupdated because the migration looked painful, an architecture that did not scale with the product.
Every project accumulates debt. The problem is not its existence but its invisibility. Known and documented debt is manageable. Invisible debt is what turns a minor fix into days of debugging.
The most common forms:
- outdated or abandoned dependencies;
- no automated tests on critical paths;
- business logic scattered across controllers, templates, or import scripts;
- configuration duplicated across environments;
- no documentation on structural decisions;
- tight coupling between modules that should be independent.
None of these situations automatically requires a full rewrite. But each one requires honest evaluation before resuming development.
Why taking over a project is different from building one
Starting a new project means laying foundations. Taking over an existing one means understanding what is holding up, what is at risk of collapsing, and what can stay as-is.
This difference is routinely underestimated. You arrive at a project with assumptions about what it does, and fairly quickly discover those assumptions are partially wrong. The actual code reflects past decisions whose reasons are no longer visible. Some business rules exist only in the code, with no documentation. Some behaviours are side effects that became features.
Taking over without an audit phase means navigating blind. Early changes can destabilise seemingly unrelated parts of the system. Timelines stretch. Bugs reappear.
A preliminary audit — even a short one — significantly reduces this risk. It does not need to take weeks. It needs to produce a map of the risk zones.
What a technical audit should cover
A takeover audit is not an exhaustive code review. It is a risk-and-priority-oriented reading of the codebase.
Dependency state
Which versions of frameworks, libraries, and tools are in use? Are any unmaintained, carrying known CVEs, or incompatible with current language versions? A Symfony 4.4 project without a migration path to 5 or 6 carries a different risk profile from a project on a current LTS version.
Test coverage
Are there tests? On which parts? Unit tests on business logic change the nature of the takeover work. Their absence does not block a takeover, but it shifts the confidence level when making changes.
Code readability
Not in the aesthetic sense — in the operational one. Can someone who was not involved in the original development understand what a controller, an entity, or a service does by reading it? Poor readability slows everything: bug fixes, feature additions, code review, onboarding a new developer.
Separation of concerns
Is business logic isolated from the presentation layer and the data layer? A project where calculation rules live in templates, or where SQL queries are embedded in controllers, is harder to evolve and harder to test.
Documentation of structural decisions
Why this architecture? Why this dependency? Why this business rule encoded this way? Missing documentation does not make a codebase unusable, but it turns every takeover into archaeology.
Infrastructure and environments
How does the project deploy? Is there a staging environment? Is configuration versioned? A project with no reliable test environment is riskier to modify, even on apparently simple features.
Carry forward or rebuild: how to decide
A full rewrite is often presented as the clean solution. In practice, it is rarely the fastest or safest.
Rewriting entirely means:
- building a development context from scratch;
- re-encoding business knowledge that is often poorly documented;
- running two systems in parallel during the transition;
- risking the loss of edge cases the existing code handled silently.
Carrying forward with a prior stabilisation phase is usually more reasonable — provided the foundations are sound.
A simple decision framework:
| Criterion | Signal to carry forward | Signal to rebuild |
|---|---|---|
| Dependencies | Outdated but migratable | Abandoned, incompatible |
| Tests | Partial but present | Absent on critical paths |
| Readability | Degraded but understandable | Opaque, undocumented |
| Business logic | Structured, identifiable | Dispersed, impossible to isolate |
| Infrastructure | Deployable, adaptable | Nonexistent or blocking |
| Migration cost | Less than the cost of a rewrite | Greater than targeted rewriting |
This framework is not a strict rule. A project can have signals in both columns. The goal is to make a diagnosis before taking an expensive decision.
Prioritising interventions after an audit
An audit produces a list of issues. They do not all have the same urgency or the same scale. Prioritising them avoids treating cosmetic issues before structural ones.
Priority 1: security and availability. Known vulnerabilities, unmaintained dependencies with published CVEs, exposed configurations, single points of failure. These are risks that can materialise without any development action.
Priority 2: reliability of business logic. Business rules that produce incorrect results, unhandled edge cases, inconsistent data in the database. A tool that runs but produces wrong results is often more dangerous than a slow tool.
Priority 3: observability. Logs, alerts, monitoring. Knowing when something fails and why. Before making significant changes, you need to be able to observe the impact.
Priority 4: testability. Adding tests on critical sections before modifying them. Not to hit a coverage target, but to create a safety net around what must not break.
Priority 5: readability debt. Renames, service extractions, documentation of decisions. Useful, but can wait until the higher priorities are addressed.
The specific case of internal business applications
Internal business applications — request tracking, scheduling tools, data entry portals, custom invoicing systems — have a particular dynamic when it comes to takeovers.
Their business logic is often far more complex than their interface suggests. It was built in successive layers, responding to real situations that were not foreseeable at the start. Calculation rules reflect organisational decisions that are no longer known to the people using the tool today.
On this kind of project, the audit phase must go beyond the code. It must cover actual usage: who uses what, in what order, with what exceptions. Otherwise you risk simplifying a rule that seemed over-engineered but was actually handling a frequent case that went unnoticed.
This connects to the work of framing a new version: framing a business application before development applies equally when taking over an existing tool. You go back to the terrain, not just to the code.
What a developer or agency should tell you before starting
If you bring in an external developer or firm to take over your project, certain questions need clear answers before development begins.
- Do they have access to the source code, a development database, and the environments?
- Are they doing a preliminary audit, or diving straight into the code?
- How do they document what they understand and what they change?
- What is their testing strategy before deploying changes?
- How do they handle the transition if the project is already in production?
A developer who promises to take over a project within a few days without any exploration phase is taking a risk — often at your expense. A serious takeover begins with a reading phase, even a short one.
FAQ
Can you take over a project with no documentation?
Yes, but it takes longer. Missing documentation means reconstructing context from the code, past conversations, current users, and the database. That work has value — it makes implicit knowledge explicit — but it needs to be budgeted for.
How long does a takeover audit take?
It depends on the size and complexity of the project. A quick audit on a modestly sized tool might take a few days. A project with many modules, third-party integrations, and dense business logic may need several weeks of reading before a credible roadmap can be proposed.
Is it better to take over internally or bring in an external developer?
Both can work depending on available resources. An internal takeover capitalises on existing knowledge but requires available time and up-to-date technical skills. An external developer brings a fresh perspective and tested methods, but needs time to absorb the context. In some cases, a combination works best: external audit, internal execution.
What if the project is blocking but a full rewrite is too costly?
This is the most common situation. The answer is prioritisation: identify the three or four issues that carry the most risk or slow usage the most, and address those first. A partial stabilisation beats a rewrite postponed indefinitely.
Can you migrate to a different stack during a takeover?
Yes, but it becomes a project within the project. If the existing code is in PHP without a framework and a migration to Symfony is being considered, treat it as a targeted rewrite with a progressive cutover strategy, not as a like-for-like takeover.
Conclusion
Taking over an existing web project is not the same as starting fresh. It requires a reading phase, a risk-oriented audit, honest prioritisation of interventions, and an informed decision between stabilisation and rebuild.
The impulse to rewrite everything is understandable. It consistently underestimates the cost of reconstructing business knowledge and the risk of regression on edge cases the existing code was handling silently.
The right starting point is the audit. What it reveals determines the roadmap, the realistic budget, and the nature of the first interventions.
If you are in this situation — a project that runs but that nobody dares touch, or an internal application that needs modernising — it is the kind of problem worth discussing directly. The approach starts with understanding what exists before proposing anything.