Refresh a website when its underlying system can support the changes you need. Consider rebuilding when that system is the obstacle. The age of the design alone does not settle the question. Ask a provider to demonstrate the limitation, describe what can be retained, and explain the cost of each realistic route.
For a Punta Gorda business with useful service pages, familiar branding, or years of project photos, starting again should not mean discarding the business's history. Equally, keeping an old platform is not a saving if routine changes remain difficult or inquiries still fail to arrive.
Define the outcome before debating the platform
Write three changes that would make the website more useful. For example:
- Staff can update service information without waiting for a developer.
- Customers can understand which projects the business accepts.
- Estimate requests include enough detail and reach the right person.
These are testable requirements. “Make it modern” is not enough to choose between a visual refresh and a rebuild.
Take a fictional Punta Gorda renovation company. It has good project photographs and useful descriptions, but all services sit on one crowded page. If the current platform can support better organization and an accessible inquiry form, a content and design refresh may be enough. If the owner cannot maintain the pages or the form depends on an unsupported component, a technical rebuild deserves consideration. These are two different diagnoses, even when the old homepage looks identical.
Use four demonstrations to reveal the real constraint
Ask the provider to work through these tasks on the current site or explain why it cannot safely do them:
| Demonstration | A refresh may fit when… | A rebuild needs consideration when… |
|---|---|---|
| Change a service and photo | The editing system works and staff can use it | Access, platform constraints, or unsupported software prevent a maintainable result |
| Read and navigate on a phone | The layout can be corrected within a sound system | The existing structure cannot support the required usable layouts without extensive replacement |
| Explain separate services | Pages can be reorganized with accurate content | The required content model or functionality exceeds what the system can reasonably support |
| Submit and receive a request | The form can be repaired, simplified and tested | Delivery relies on an unsuitable integration or the necessary workflow cannot be supported |
One failed test does not automatically require a complete rebuild. Ask whether the problem is isolated, whether it can be reproduced, and what a repair would involve. A slow page, for example, could have oversized images rather than an unusable platform.
Compare two scopes against the same requirements
When both approaches are feasible, ask for two short scopes: what the refresh preserves and changes, and what the rebuild replaces and why. Both should address the same customer and editing needs.
Compare the build work, recurring platform costs, migration effort, remaining limitations, and expected maintenance responsibilities. If the cheaper option leaves a known requirement unsolved, record that explicitly. If the rebuild adds capabilities you will not use, challenge whether they belong in the first phase.
At Local Legacy, we recommend a refresh when the foundation works and the main problems are dated visuals, unclear messaging, or a few weak pages. We recommend considering a rebuild when the site is hard to update, performs poorly on phones, has a confusing structure, or needs substantial changes to what it does. Our Legacy Refresh and website-design service describe those starting paths.
A focused refresh can take 1–3 weeks. A larger rebuild usually takes longer, particularly when content or approvals are still being gathered. We give a more useful timeline after reviewing the scope. Improving the offer and message comes first: a new design cannot fix an unclear offer.
Preserve useful content deliberately
Before removing anything, inventory priority service pages, project stories, downloads, and contact routes. Record what the business still offers and what customers still use. An old-looking page can contain valuable information even if its presentation needs work.
For a company operating in Punta Gorda and nearby areas, retain accurate local project context and actual coverage details. Remove outdated promises. Do not replace real project descriptions with city-name variations that add no new information.
Choose a destination for each important item: keep it, improve it, merge it into a relevant page, or retire it with an appropriate outcome. Our older-website refresh plan provides the more detailed preservation and launch checklist once you have chosen the scope.
Decide what happens to existing page addresses
A new visual design does not inherently require a new domain or new URLs. Keep useful addresses where practical. When an address must change, map it to the relevant replacement and test the result.
Google's site-move guidance calls for preparation and URL mapping, and warns that significant changes may cause temporary search fluctuations. A provider should explain the migration plan without promising unchanged rankings.
Ask who will check redirects, navigation, internal links, the sitemap, and important old links after launch. Also identify email and other services tied to the domain before changing its configuration. A working homepage is only one part of a successful changeover.
Make the final recommendation understandable
A useful assessment should end with a statement you can repeat to a colleague:
“We can keep these pages and this platform. We need to rewrite the service structure, update the mobile layout, and fix inquiry delivery.”
Or:
“The content is useful, but the current system cannot support the editing and inquiry workflow we need. We recommend rebuilding the site while retaining approved content and mapping changed URLs.”
These are example recommendations, not claims about a client. Each explains the reason, preserved value, and work involved.
Does rebuilding mean losing my domain?
Usually a rebuild can use the existing domain, subject to account access and the technical plan. Ask for any proposed domain change to be explained separately.
Will a redesign restore lost traffic?
Not necessarily. Investigate the affected pages, search data, tracking and technical behavior before assigning a cause. Our brand and old-website guide separates discovery, confidence, and contact problems.
Can we improve the site in stages?
Often the work can be phased, but the provider should identify dependencies. Fixing a contact problem first may be practical; rewriting every page before deciding a new structure may create rework.
Request a website review. Bring your current URL, the changes you need, and the tasks that are difficult today. We can discuss a scope for your Southwest Florida business.