Improve the existing site when the important problems are isolated and the current platform can support the fix. Replatform when the content or technical system prevents the team from maintaining a good site, but the core information architecture and journeys remain sound. Rebuild when the structure, templates, content model, and priority journeys are wrong together. Choose the smallest level of change that removes the real constraint, not the option with the most dramatic presentation.
These terms are often used loosely. In this article, an improvement changes selected content, design, templates, or performance work within the current system. A replatform moves the site to a different content management or technical foundation while preserving much of the intended structure. A rebuild redesigns the site architecture and experience and may also change the platform.
Diagnose the failure before discussing the solution
Begin with observed problems, not stakeholder preferences. "The site feels old" is a reaction. "Visitors cannot tell which location offers the service" is a problem that can be tested. "Editors cannot update a shared insurance notice without changing twelve pages" is an operating constraint.
Collect evidence from five places:
- high-intent visitor journeys such as finding a service, location, provider, or contact route
- shared templates and components
- content ownership and publishing workflow
- performance, accessibility, analytics, and search diagnostics
- integrations such as forms, scheduling, directories, and customer systems
For each issue, note how widely it appears and what causes it. A broken heading on one page is not a reason to rebuild. The same defect across every service page may point to a template. Repeated conflicting facts may point to the content model or ownership, not the visual design.
Use this change-level scorecard
Score each statement as true, partly true, or false. Do not add the answers into a magic total. Look for the level at which the constraints cluster.
Question • Improvement is plausible • Replatform is plausible • Rebuild is plausible
- Are problems limited to a small set of pages or components? | Yes | Not usually | No
- Can the current templates support the desired journeys? | Yes | Usually | No
- Can editors maintain shared facts without duplication? | Yes | No | No or only after structural change
- Is the current architecture understandable and scalable? | Yes | Yes | No
- Are security and maintenance needs supportable on the current foundation? | Yes | No | Maybe, depending on the wider structure
- Can essential integrations work reliably without fragile workarounds? | Yes | No | No, with journey redesign also needed
- Would preserving current URLs and page roles still make sense? | Yes | Yes | Many need deliberate change
One strong "no" can matter more than several "yes" answers. For example, an unsupported platform with a serious maintenance problem may justify replatforming even when the visible site looks acceptable. Conversely, poor copy across many pages does not automatically require a new platform.
When is an improvement enough?
An improvement program is appropriate when the site can already support the intended result. Typical work might include rewriting priority pages, simplifying navigation labels, repairing forms, improving mobile layouts, creating a better service-page template, or addressing measured performance problems.
Choose this route when the team can publish and maintain the repair without hidden manual work. Test one representative page before committing to a broad rollout. If the new version can be created, approved, measured, and kept current inside the existing system, a rebuild may add cost and migration risk without adding value.
Set a boundary around the program. "Improve the website" is too broad. "Repair the appointment journey for five priority services and create one maintainable template" can be planned and accepted.
Replatform when the operating system is the blocker
Replatforming is appropriate when the current content management system, hosting setup, or integration layer prevents reliable maintenance, security work, performance, or publishing. The important distinction is that the target experience and page roles are mostly understood.
Examples include an editor being unable to update structured location data, a platform that no longer receives required support, or a form and scheduling layer held together by unowned custom code. Moving systems may solve those constraints, but it does not automatically improve weak content or confusing journeys.
Write down what should remain stable before choosing technology. That may include the canonical page list, service-location relationships, analytics definitions, approved content, and critical integrations. Evaluate platforms against those requirements rather than selecting one from a feature demonstration.
Rebuild when the site is solving the wrong problem
A rebuild is warranted when the current structure cannot support how visitors and the organization now work. A growing group may have added services and locations into a navigation designed for one clinic. Provider pages may duplicate service information without clear roles. Contact journeys may branch unpredictably. The content model may have no way to represent shared facts once and reuse them safely.
In that situation, changing colors or moving the same pages to a new platform preserves the underlying confusion. The project needs a new architecture, defined page responsibilities, redesigned priority journeys, and a migration plan. The platform decision follows those requirements.
A rebuild still needs limits. Define which journeys and content types are changing and what will be preserved. Avoid using the project as an excuse to rewrite or redesign everything regardless of evidence.
Compare three realistic options
Imagine a multi-location specialty practice with slow mobile pages, outdated service copy, and an awkward editing interface.
**Option one improves the current site.** A technical review finds that image delivery and a few templates cause most performance problems. Editors can update content, and the service-location structure is sound. Targeted template, content, and performance work is the sensible first choice.
**Option two replatforms.** The journeys and URL structure work, but the unsupported system cannot receive maintenance updates and every content change needs a developer. Moving the existing model to a maintained platform may solve the operating constraint while preserving the experience.
**Option three rebuilds.** The practice has expanded from one site to eight, services vary by location, visitors cannot find the right combination, and facts are duplicated across dozens of pages. The architecture and content model need redesign. A simple platform move would carry the confusion forward.
The same visible symptoms can lead to different answers because the cause is different.
Account for migration risk before approving change
Any option that changes URLs or site structure needs a deliberate migration plan. Google Search Central advises mapping old URLs to relevant new destinations, using permanent server-side redirects, updating internal links, and monitoring the move. Its guidance also cautions against combining multiple major changes when they can be separated, because diagnosing a problem becomes harder.
That guidance does not promise stable search performance. It identifies controllable migration practices. Preserve an inventory of current URLs, traffic and conversion context, backlinks where relevant, metadata, structured data, and page ownership. Decide what moves, merges, redirects, or is retired before launch.
Approve the option against outcomes
Ask each proposal to show how it resolves the observed problems. A good decision document can fit on one page:
- the priority visitor and editor problems
- the cause of each problem
- the smallest change level that addresses the cause
- what will be preserved
- major migration and operational risks
- acceptance tests for the repaired journeys
- cost, timeline, and owner assumptions that still need confirmation
If two options meet the same acceptance tests, prefer the one with less unnecessary change and a maintainable path forward. If no option meets them, the team has not defined the requirement clearly enough.
The right healthcare website design decision is rarely "new versus old." It is whether the chosen level of change can solve the verified problem without preserving a structural blocker or creating avoidable migration work.