When a website becomes difficult to manage, everyone seems to have a different recommendation.
One developer says it can be repaired. Another says the entire site needs to be rebuilt. A platform specialist tells you to migrate everything somewhere else.
All three could be right.
They could also be looking at one part of the problem without understanding the rest of the system.
A website can look outdated while functioning perfectly well underneath. It can also look fine while relying on fragile code, abandoned plugins, broken integrations, or a platform that no longer supports what the business needs.
Before you approve a repair, rebuild, or migration, you need to understand where the problem actually lives.
The basic difference between repairing, rebuilding, and migrating
These terms are often used interchangeably, but they describe different kinds of work.
Repairing a website
A repair addresses a contained problem while preserving most of the existing website.
That might include:
- Fixing a form that stopped sending notifications
- Correcting a mobile layout issue
- Replacing an abandoned plugin
- Improving page speed
- Repairing an integration
- Updating templates or content
- Correcting analytics or conversion tracking
- Improving an editing experience that has become unnecessarily difficult
Repair is usually the best path when the current foundation is sound and the problem can be isolated.
Rebuilding a website
A rebuild replaces much of the website’s underlying structure.
The business may keep the same domain, content, branding, or even the same platform, but the templates, code, content structure, and administrative experience are rebuilt.
A WordPress website can be rebuilt in WordPress. A Shopify store can be rebuilt in Shopify. Changing platforms is not required.
A rebuild makes sense when the platform still fits the business, but the current implementation has become too fragile, restrictive, or difficult to maintain.
Migrating a website
A migration moves the website, its content, or its data into a different technical environment.
That may involve:
- Moving to a different content management system
- Changing e-commerce platforms
- Moving from a proprietary platform to an open system
- Consolidating several websites
- Moving to new hosting
- Changing domains or URL structures
- Replacing a legacy application
- Moving product, customer, membership, or account data
Some migrations are relatively straightforward. Others involve a complete rebuild because the old and new systems organize information differently.
The important question is not whether the site can technically be moved. It is whether the new system will solve the problems that justified moving it.
Start by separating the symptom from the cause
This is where website projects often go wrong.
A business sees a problem and assumes the visible symptom identifies the solution.
For example, a contact form may display a success message while the sales team receives nothing. That does not automatically mean the form is broken.
The failure could involve:
- Conditional logic inside the form
- An email authentication problem
- A CRM connection
- A webhook
- An automation rule
- User permissions
- Lead assignment settings
- Spam filtering
- A third-party service
- Conversion tracking that makes a successful submission look unsuccessful
Replacing the form might do nothing.
The same applies to many common complaints.
A slow website does not always require a rebuild. The problem could be oversized images, poor hosting, unnecessary scripts, an overloaded database, or one badly configured feature.
A difficult editing experience does not always mean the platform is wrong. The current theme or content structure may simply have been built poorly.
Before deciding what kind of project you need, identify whether the problem is:
- Contained within a specific feature or workflow
- Built into the current implementation
- Caused by the platform itself
- Outside the website entirely
That distinction determines whether repair, rebuild, migration, or no website work at all is the most reasonable response.
When repairing the current website makes sense
Repair is usually the right choice when the website still has a healthy foundation.
The platform supports your current needs. Your team can access and manage the site. The important content still reflects the business. Search traffic is stable. Most features work correctly.
The problem is limited enough that someone can define it, test it, and confirm when it has been resolved.
Signs that repair may be the best path
Consider repairing the website when:
- The problem affects one feature or a limited number of pages
- The platform still receives security and software updates
- The current website can support the functionality you need
- Your team has reliable access to the website, hosting, domain, and connected tools
- The site already performs well in search
- The content and page structure are still useful
- Most of the website works correctly
- The underlying code is reasonably maintainable
- The repair can be tested without placing the rest of the site at significant risk
Repair can preserve years of useful content, search visibility, links, analytics history, and staff familiarity.
It can also be considerably faster than rebuilding a system that mostly works.
When repeated repairs become a warning sign
Repair stops being economical when every fix exposes another problem. These patterns can be signs that the website has become too fragile to keep repairing.
You may replace one plugin and discover that three other features depend on it. A routine software update may break the theme. A small content change may require a developer because the administrative system was never designed for normal use.
At that point, the business is no longer paying to improve the website. It is paying to preserve a fragile arrangement.
One complicated repair does not automatically justify a rebuild. A pattern of repeated repairs deserves a closer look.
Ask:
- How much has been spent maintaining the current setup over the last year?
- Are the same problems returning?
- Does every change require a workaround?
- Can the website be updated safely?
- Are qualified developers willing to support the existing code?
- Is the current setup preventing otherwise reasonable improvements?
The cost of a website includes the time and risk required to keep it operating.
When rebuilding makes more sense
A rebuild becomes reasonable when the platform can still serve the business, but the existing website was built in a way that limits progress.
This is common with websites that have passed through several agencies or developers. Each person adds a plugin, template, script, or workaround without fully understanding what came before. If you have recently taken responsibility for a site like this, start with these 10 things to do when you inherit a website before approving major changes.
Eventually, the site contains several ways of doing the same thing. No one knows which components are safe to remove. Small changes take longer than they should. Our guide to taking over a website built by another developer explains how to investigate that kind of inherited system before changing it.
Signs that the website may need to be rebuilt
A rebuild may be the better choice when:
- The theme or template system is no longer supported
- Custom code is undocumented or unreliable
- Normal software updates regularly break the site
- Several plugins perform overlapping jobs
- The content structure no longer matches the organization
- Editors cannot make routine changes without developer assistance
- Accessibility problems are embedded throughout the templates
- Performance problems are spread across the entire build
- Important functionality depends on fragile workarounds
- The website cannot be tested or deployed safely
- The cost of continued repair is approaching the cost of replacement
A rebuild provides an opportunity to keep the parts that still have value while replacing the parts that create risk.
That may include preserving:
- Strong content
- Existing URLs
- Search rankings
- Brand assets
- Analytics history
- Useful integrations
- Product or service information
- Customer or member data
Rebuilding should not mean blindly starting over.
The existing site may contain years of business knowledge. Throwing everything away because the code is messy can create a different set of problems.
When migration is the better decision
Migration becomes the leading option when the current platform itself is the limitation.
A poorly built website can often be rebuilt on the same platform. A platform that cannot support the business model is a different problem.
Signs that it may be time to migrate
Consider a migration when:
- The platform cannot support required functionality
- The software is no longer maintained
- The business does not control its website or data
- The platform restricts access to code, content, or integrations
- Essential third-party services no longer support it
- The website depends on a vendor that is closing or becoming unreliable
- Licensing or transaction costs no longer make sense
- Product, account, membership, or content management has become unworkable
- The business has outgrown the platform’s reporting or operational tools
- Continuing with the platform requires increasingly complicated workarounds
A migration should solve a clear limitation.
Moving from one system to another because the new platform is popular can leave you with the same problems in a different interface.
Before selecting a destination, document:
- What the current website does
- What it should do
- Which systems it connects with
- Which data must be preserved
- Which workflows are business-critical
- Who needs to edit or administer it
- What failed in the current setup
- What cannot be lost during the move
That document should guide the platform decision. A sales demonstration should not.
A hosting move is not always a platform migration
This distinction causes unnecessary confusion.
You can move a website to a new hosting provider while keeping the same CMS, domain, URLs, content, and design. Google treats this as an infrastructure move when the public URLs remain unchanged. The migration process focuses on preparing the new infrastructure, updating DNS, monitoring traffic, and making sure temporary crawl restrictions have been removed.
Changing platforms or URL structures is more involved because search engines and users need to be directed from the old locations to the new ones.
Understanding which type of move you are planning matters. The checklist for changing hosting is very different from the checklist for rebuilding a site on a new CMS.
What happens to SEO during a rebuild or migration?
SEO should be part of the project before development begins.
It should not be added during the final week before launch.
A rebuild or migration can affect:
- URLs
- Page titles and descriptions
- Internal links
- navigation
- structured data
- canonical tags
- image locations
- downloadable files
- page content
- performance
- tracking
- conversion actions
- Search Console verification
Google recommends creating a mapping between the current URLs and their corresponding new URLs, using permanent server-side redirects, testing those redirects, updating sitemaps, and monitoring the move through Search Console. Google also warns that rankings may fluctuate temporarily while the new URLs are crawled and indexed.
One of the most common mistakes is redirecting every old page to the new homepage.
That may be convenient for the development team, but it provides a poor experience and can be treated as a soft 404 when the destination is not relevant. Each valuable old URL should lead to the closest appropriate new page.
Google recommends keeping site-move redirects in place for at least one year. From a user-experience standpoint, it can make sense to keep them longer.
A proper migration plan should also preserve:
- Important page content
- Existing backlinks
- Analytics configuration
- Google Tag Manager
- Conversion tracking
- Search Console access
- Form attribution
- CRM lead-source data
- Canonical settings
- Indexing rules
- XML sitemaps
A website can appear to launch successfully while quietly losing search visibility or conversion data.
The decision framework I use
When I evaluate an existing website, I start with a few practical questions.
1. What is actually failing?
List the visible symptoms.
Then trace each one through the systems involved. A broken customer journey may cross the website, a form provider, email delivery, a CRM, an automation platform, and an internal user account. This becomes especially difficult when every vendor says its system works.
Do not choose a project type until you understand the likely source of the failure.
2. Can the current platform support the desired outcome?
Separate what is difficult from what is impossible.
Something may be difficult because the current implementation is poor. That suggests repair or rebuilding.
Something may be difficult because the platform does not expose the necessary data, code, integration, or workflow controls. That may justify migration.
3. What already has value?
Identify what should survive the project:
- Pages that generate search traffic
- Content that answers customer questions
- Existing links
- Product or service data
- User accounts
- Integrations
- Design elements
- Administrative workflows
- Historical reporting
A good plan preserves useful assets rather than treating the old website as disposable.
4. What is the cost of staying where you are?
Look beyond the next repair estimate.
Consider:
- Ongoing maintenance
- Staff time
- Lost leads
- Manual data entry
- Failed transactions
- Vendor fees
- Development delays
- Security exposure
- Inaccurate reporting
- Opportunities the platform prevents you from pursuing
A cheap repair can be expensive when it preserves the wrong system.
5. What new risks will the project create?
Every option carries risk.
A repair may disturb a fragile website. A rebuild may introduce new bugs. A migration may affect data, URLs, search visibility, integrations, and staff workflows. Businesses dealing with an undocumented or inherited system may need website takeover and technical rescue support before implementation begins.
The best path is the one with manageable risks and a clear testing plan.
6. Can your team manage the result?
A technically impressive system can still be a bad solution.
The people responsible for the website should be able to perform normal tasks without calling a developer every time. The final system should fit the team, budget, and operational reality.
A Quick Comparison
Sometimes the right answer is to wait
There are situations where repairing, rebuilding, and migrating are all premature.
A business may be considering a new website while still changing its core services, audience, pricing, or internal process. Rebuilding immediately can result in a new website based on requirements that no longer apply six months later.
Waiting does not mean ignoring a broken system.
It may mean making a limited repair, documenting the current setup, and defining the business requirements before committing to a larger project.
This is especially important when several stakeholders disagree about what the website should accomplish.
Development cannot resolve a strategy problem that the organization has not made a decision about.
Do not start with three rebuild quotes
When the correct path is unclear, requesting several rebuild proposals may give you three versions of the same assumption.
Agencies tend to quote the work they are structured to sell. A design agency may recommend a redesign. A development company may recommend rebuilding. A platform specialist may recommend migrating to its preferred platform.
That does not mean anyone is being dishonest. Their recommendations are shaped by the problems they normally solve.
A better first step is to document the current system and answer these questions through an independent technical website assessment:
- What is broken?
- Why is it happening?
- What should the business be able to do?
- Which parts of the current system are worth preserving?
- What are the available options?
- What does each option cost?
- What could go wrong?
Once those questions have credible answers, implementation proposals become much easier to evaluate.
Get a clear recommendation before committing to the project
Kismet’s Technical Website Assessment is designed for situations where the answer is not obvious.
We review the website, the connected systems, the desired outcome, previous attempts, and the technical constraints. You receive written findings, recommended next steps, an implementation roadmap, and an estimated implementation range. You are not required to use Kismet for the implementation.
That separation matters.
The goal of the assessment is to identify the most practical path, even when the answer is a focused repair, a rebuild on the same platform, a full migration, or waiting until the business requirements are clearer.
Before spending money replacing a website, make sure you know which problem you are replacing it to solve.
—
Still unsure which path makes sense?
A Technical Website Assessment can identify the source of the problem, document the available options, and give you a practical implementation roadmap.
Request a Technical Assessment
—
Written by Joey Zuccarini
COO at Kismet Creative Co.