When a Redesign Is the Wrong Answer: Rebuild vs Refactor

The redesign proposal arrives before anyone has reproduced the broken enquiry form. It includes a new framework, a new content system and a fresh visual direction. Those may eventually be justified, but they do not yet explain why the current website must be replaced.

A rebuild-versus-refactor decision should begin with a limited technical investigation. The question is whether the important behaviour can be understood, tested and changed safely. A website can look dated while remaining repairable, or look polished while hiding structural problems that make every correction unreliable.

Separate the business complaint from the proposed remedy

Write down the observed failures in terms a customer or operator can recognise. Examples include an enquiry that never arrives, a price that cannot be updated consistently or a mobile menu that blocks navigation. Keep preferences about colours and page style in a separate list.

Then identify the consequence of each failure. Does it stop a purchase, create manual work, expose information or merely annoy an editor? This ordering helps the investigation focus on the paths that matter instead of starting with whichever technology the supplier prefers to replace.

Ask what evidence would change the recommendation. If the answer is nothing, the proposal is a predetermined rebuild rather than a diagnosis. A useful assessment can conclude that some areas need replacement while others should remain, with reasons for each boundary.

Test whether the site can be reproduced

The first practical test is whether another authorised developer can run the site in a suitable non-production environment. They need the code, configuration instructions and representative safe data. Missing credentials or an undocumented manual step may be a handover problem rather than proof of bad architecture.

Record what cannot be reproduced and why. A dependency on an unavailable service, an unsupported component or a database that nobody understands can change the risk assessment. Avoid collapsing these distinct issues into one broad statement that the code is old.

The owner should receive a concise account of the obstacles and their consequences. For example, if only one server contains the working application, a recoverable deployment process may be the first priority. A visual rebuild without solving that dependency would preserve the underlying operational weakness.

Choose one important journey and trace it completely

Follow a representative action from the browser through the application and back to the business record. For an enquiry, that may include validation, storage, email delivery and a confirmation message. Do not stop when the form displays a success alert.

Ask the investigator to identify where the failure originates and what other journeys use the same component. A shared mail handler or pricing function can affect several pages. Fixing only one visible symptom may leave the same defect elsewhere in the site.

This is also a test of comprehensibility. If the team can explain the flow and isolate the failing behaviour, a targeted repair may be credible. If basic actions depend on widespread undocumented side effects, the estimate should include the work required to establish a safe boundary.

Illustrative concept.

Request a small repair trial

Choose a meaningful but bounded defect and ask for a proposed change, its verification and a rollback method. The trial should exercise the real development process. A demonstration on an unrelated new page says little about the maintainability of the existing application.

Evaluate more than whether the fix works once. Did the developer find the relevant callers? Could the change be isolated? Were related behaviours checked? Could the previous version be restored without losing new business records? These observations are stronger evidence than a technology preference.

The trial may reveal that modest refactoring is needed before the repair. That does not automatically justify replacing the entire site. Ask whether the necessary cleanup has a clear stopping point and whether it directly reduces the risk of the requested change.

Identify components that cannot reasonably remain

Some constraints can make replacement appropriate: a required capability the platform cannot support, an unavailable integration with no workable substitute, or a component that cannot be maintained within the business's requirements. Verify those constraints against current vendor information and the actual configuration.

Distinguish unsupported from merely unfamiliar. A supplier's team may prefer another stack, but that staffing preference should be stated openly. The owner can then compare a new build with maintenance by someone equipped to support the existing system.

Likewise, a long list of plugins is not itself a diagnosis. Identify which components are needed, which conflict and which introduce material maintenance or security concerns. The recommendation should connect a concrete limitation to a proposed action rather than treating a count as proof.

Compare equal scopes, including the move

A repair estimate and a rebuild estimate often cover different things. The rebuild may include new content and design, while the repair quote covers only faults. Separate those elements so the owner can see what is required to restore function and what is an optional improvement.

Include migration work in the replacement case. Existing URLs, downloads, customer records, integrations and administrative workflows do not transfer themselves. Google advises planning URL mappings, redirects and monitoring when URLs change; those tasks remain necessary even if the replacement software is excellent. Google site-move guidance.

Ask for the assumptions behind each estimate. An unknown data export or unavailable account should be listed as an unresolved dependency, with an investigation step. A precise-looking total based on unverified access is less useful than a bounded assessment that states what remains unknown.

Consider replacing one boundary at a time

A mixed approach may fit a site whose public pages work well but whose administration or booking integration does not. The important question is whether a clear boundary lets the failing component change without destabilising the rest. Do not add a second system merely to avoid making a decision.

For a hypothetical service company, the enquiry path might be repaired immediately while an obsolete catalogue editor is replaced in a later phase. The company can then verify the urgent fix independently. This example describes an option, not a promise that staged work will always be cheaper.

Phasing introduces its own responsibilities. Document which system owns each record during the transition and how duplicated data is prevented. A partially replaced site is manageable only when the temporary arrangement is explicit and has a planned end state.

Define acceptance before committing to either option

For a refactor, acceptance should include preserved behaviour as well as the repaired defect. For a rebuild, it should include migrated content, working integrations and operational handover. The new website looking correct is only one part of a completed replacement.

Retain a small set of representative customer journeys as regression checks. Include the less convenient paths: invalid form input, an unavailable product, a cancelled booking or a failed payment where applicable. Those cases reveal whether the system handles ordinary setbacks coherently.

Agree who verifies business records after release. A developer can check that an email was sent, but the business should confirm that the right team received the enquiry and can act on it. Technical and operational checks complement each other rather than substitute for one another.

Ask for a recommendation you can audit

The final assessment should list observed failures, tests performed, confirmed constraints and remaining unknowns. It should recommend repair, selective replacement or a full rebuild, with a clear explanation of why the narrower alternatives do or do not satisfy the requirements.

When approaching website recovery, bring access details through an approved channel and a short list of reproducible problems. Ask for diagnosis before committing to a new platform. A defensible decision comes from the existing site's behaviour and the business's needs, not the age of its design.