Should You Repair Your Website or Rebuild It?

Compare a website update, focused repair, migration and rebuild. Start with the customer problem and agree on how the result will be checked.

Updated October 21, 2026.

Start by identifying the problem your website needs to solve. A broken form, an overdue update or a security announcement is a reason to investigate. You need more information before deciding to replace the whole site.

A focused repair may restore the function you need. A migration may move a useful site to a maintainable environment. A rebuild may make sense when the existing system cannot support the way your business needs to work. The right proposal should explain that choice in terms you can understand.

Separate the urgent fix from the larger project

The October 21 PHP announcement calls for affected systems to be updated. A new homepage design does not establish that the underlying software has been patched. Ask the person responsible for hosting to confirm the relevant fix, and ask who will check the application afterward. PHP's official security notice

If the provider identifies an urgent issue, agree on its immediate response. Keep any wider design proposal clear: what is necessary to address the current problem, and what is an improvement you can consider separately?

For older installations, ask about vendor-maintained packages and documented fixes. PHP's notice distinguishes those from upstream releases. An old-looking version label alone does not provide the full answer.

Our October PHP update guide includes a question you can send your provider and a short list of customer functions to check.

Compare the options against a real task

Choose a task customers depend on: requesting a quote, booking a visit, buying a product or finding important information. Describe where it stops and what a successful result should look like.

For example: “The inquiry form shows success, but staff cannot find the request.” That gives the team something specific to investigate. “The website needs optimization” leaves the problem undefined.

Update and verify

When to examine it: The site meets your needs and the required software change is compatible.

What the proposal should explain: What is updated, who applies it and which customer tasks will be checked.

Focused repair

When to examine it: A particular form, integration or workflow is failing.

What the proposal should explain: The observed failure, affected parts, proposed change and completion check.

Migration

When to examine it: The hosting or software environment is the constraint.

What the proposal should explain: What moves, what stays, how data is preserved and how the change is verified.

Rebuild

When to examine it: The present system cannot support the required business workflow through a sensible repair.

What the proposal should explain: The requirements, alternatives considered, scope and evidence needed for acceptance.

This is a way to structure a conversation, not a diagnosis of your website. More than one option may be relevant.

Give a repair a clear finish line

A useful repair proposal names the issue and the result it must produce. Ask which pages or functions will change, what will be backed up and who can authorize work on the live system.

Then agree on a completion check. For an inquiry form, a visitor should be able to submit the request, the record should reach the intended place, and staff should know how to respond. For booking, distinguish a request from a confirmed appointment. For checkout, agree on how to verify the order without creating an unwanted charge.

Also ask what happens if the first change does not solve the problem. A defined next step is more useful than an open-ended promise to “keep working on it.”

Consider migration when the foundation is the constraint

Moving the technical environment does not always mean discarding the design and content. Ask for a simple inventory of the hosting, application, extensions and connected services the site depends on.

Which dependency is creating the difficulty? Can it be updated or replaced while preserving the rest? What would moving it interrupt? Those answers help distinguish a provider change, a software migration and a larger rebuild.

Have the team explain the transition and recovery approach. Identify who keeps the existing system available, who verifies the new environment and how the business will handle the switch.

Rebuild around an explicit business need

A rebuild becomes a reasonable option when the current system cannot support the required work, essential parts cannot be maintained, or repeated repairs leave the underlying problem unresolved.

A business might need customer accounts that its brochure site was never designed to provide. A public organization might need several teams to review and publish content. These are illustrative requirements; each needs discovery before it becomes a project scope.

Define success through the people using the site. What can the visitor finish? What can staff see and manage? What evidence will the owner review before accepting the result?

Preserve the parts your business owns

Before a migration or rebuild, list what must carry forward: the domain, useful page addresses, approved copy and images, business records, consent history and operational knowledge.

Confirm who controls the hosting and source files. Identify integrations that cannot be judged from a screenshot, including payments, bookings, notifications and account access. Ask how each will be checked in the environment the business will actually use.

A local demonstration and a working live integration are different evidence. Keep that distinction visible in the delivery record so you know what is complete and what still needs attention.

Ask for a recommendation you can act on

For each viable option, request the scope, exclusions, expected disruption, dependencies and acceptance checks. Ask what can remain in place and why a more substantial change is justified. Pricing should match that scope; a starter-site package is not automatically the answer to an existing site's repair problem.

You should finish the conversation knowing what needs to change, who owns the work and how you will assess the result.

Start with a free initial website review

FAMtastic Designs can help review the issue and carry out agreed website repairs, compatibility work or a rebuild when needed. Send your public site address, the problem you have observed and any recent explanation from your provider.

The initial review is free. Implementation is scoped separately, with the functions to be checked agreed before work starts. Do not send passwords or private customer data in the first message. Public organizations can use their established procurement process for any subsequent engagement.

Message FAMtastic Designs on Instagram for a free initial review.

Common questions

Can you keep my existing design?

That is a discovery question. The review should identify what can be preserved before proposing replacement.

Will a rebuild fix every security concern?

A redesign alone establishes no such guarantee. The runtime, application, access, integrations and operating practices need their own assessment.

Is the initial review a commitment to buy?

No. Further work requires an agreed scope; requesting the review does not authorize changes to your site.