How Much Does It Cost to Redesign or Update an Old Website in 2026?

An old website does not always need to be replaced completely. If the backend is stable, the page structure still reflects the business, content is indexed properly, and the main issues are outdated design, mobile usability, or frontend performance, a significant part of the existing system can often be preserved. This can reduce both the budget and the time required to launch the updated version.

The opposite situation is also common. A company plans to “refresh the design a little,” but a technical audit reveals an outdated CMS, a theme modified by dozens of incompatible plugins, a mobile version built around workarounds, and business logic that is tightly coupled with legacy code. In that case, what initially looked like a small redesign can quickly become a complete frontend rebuild or full technical modernization.

This is why the age of a website alone is not enough to estimate the project. The real question is how much of the current system can still be used safely.

Below, we break down how much website redesign and modernization can cost in 2026, what directly affects the budget, when updating the existing website is reasonable, and when rebuilding it from scratch becomes the more practical option.

How Much Does It Cost to Update an Old Website in 2026?

For professional web development in 2026, a small update to an existing website may start at around $500–$1,100, a full UX/UI redesign of a corporate website may cost approximately $2,000–$4,500, while technical modernization involving a new frontend, partial functionality rebuild, or migration can reach $5,000–$15,000+.

These figures are not fixed packages. They indicate the approximate level of investment for projects that involve analysis, UX/UI work, responsive implementation, development, testing, and SEO migration where required — rather than simply replacing a template or changing several colors.

The biggest mistake when estimating this type of project is treating “redesign” as a single standardized service.

For one website, redesign may require 40 hours of designer and frontend developer work. For another, it may involve hundreds of hours of auditing, UX planning, development, data migration, integration work, and testing.

A proper estimate therefore does not start with the question “How many pages does your website have?”

It starts with three questions:

• What can be kept as it is?
• What needs to be rebuilt?
• What dependencies will be affected by the update?

What Does “Redesigning a Website” Actually Mean?

Clients often use the terms redesign, update, modernization, reconstruction, and rebuild interchangeably.

From a development perspective, however, these can represent very different scopes of work.

A website can be visually updated without touching its backend at all. It can receive an entirely new frontend while keeping the existing backend. Or the project may preserve only the content and business data while almost the entire technical system is rebuilt.

Cosmetic Update

The smallest scope applies when the website generally works correctly but looks outdated or has several usability problems.

Changes may include:

• colors;
• typography;
• buttons;
• banners;
• spacing;
• cards;
• forms;
• icons;
• navigation;
• selected UI elements.

For example, a corporate website may have a stable CMS, a reasonable structure, existing organic traffic, and fully functional forms, but its visual design was created six years ago.

In this situation, rebuilding the backend only to achieve a more modern appearance would make little sense.

Even cosmetic updates should still follow a system. If individual elements are changed without a consistent design system, the website can quickly become a collection of unrelated styles again.

Website Redesign

A proper redesign is not simply changing blue to green or replacing the hero image. The process normally begins with analyzing page structure, user journeys, navigation, CTA placement, forms, information hierarchy, and behavior across screen sizes. Only after this does the team create new wireframes and UI design. For example, a service page may currently contain ten sections. The designer's task is not necessarily to redraw all ten in a more attractive style. Some may need to be combined. Others may need to be moved, shortened, expanded, or removed. This is why the cost of website redesign depends more on the number of unique user journeys and page templates than on the raw number of URLs.

Frontend Rebuild

Sometimes the existing backend works perfectly well.

The administration panel, API, CRM integrations, catalogue, orders, and core business logic may all be stable. The real problem is the frontend.

In this case, the business can create completely new UX/UI and rebuild the client-facing part of the website while keeping the existing backend.

This is already a much larger project than a visual redesign.

The new interface must be implemented responsively and connected to forms, authorization, search, filters, analytics, data sources, and existing backend logic.

If the backend provides a well-documented API, this approach can reduce the budget considerably.

If the frontend and backend are tightly coupled, however, the savings may be far smaller.

Functionality Upgrade

Website redesign projects often expand beyond visual changes.

A business may want to add features that were not present in the old version:

• online payments;
• calculators;
• customer accounts;
• CRM integration;
• advanced search;
• filters;
• booking functionality;
• API connections;
• automated lead processing.

At this point, the project is no longer just a design task.

A good example is an “Pay Now” button.

Creating the button in a design file may take only a few minutes. Implementing a real payment flow can require payment gateway integration, transaction statuses, webhooks, success and failure pages, error handling, test environments, and CRM synchronization.

This is why functionality is estimated separately from the number of screens.

Complete Technical Modernization

The largest scope involves replacing not only the interface but also the technological foundation of the website.

This can include:

• migration from an outdated CMS;
• changing the framework;
• rebuilding the backend;
• creating a new API;
• migrating databases;
• restructuring the architecture.

In such projects, the old website often becomes a source of content, data, SEO history, and business requirements rather than a codebase that needs to be preserved at all costs.

What Affects the Cost of Website Redesign and Modernization?

Two websites with the same number of pages can require budgets that differ several times over.

The reason is not some vague concept of “complexity.” It is the actual amount of work required to move safely from the old system to the new one.

Number of Unique Pages

Fifty URLs do not necessarily mean fifty unique designs.

An ecommerce website may contain 20,000 product URLs while using only one product-page template.

A corporate website with 30 URLs may contain a homepage, seven different service templates, case studies, portfolio pages, a blog, vacancies, contact pages, a calculator, and several landing pages.

For redesign purposes, the number of unique templates and components matters much more.

If ten pages use the same system of reusable blocks, changing the design system can update all ten relatively efficiently.

If every page was built independently without reusable components, each one may need to be analyzed and adjusted separately.

Condition of the Existing Code

Legacy code does not automatically mean bad code.

Often it simply refers to a system that has existed for many years, survived dozens of changes, and accumulated dependencies that are no longer obvious.

Problems begin when changing one module unexpectedly affects three others.

Before estimating modernization, the development team should understand:

• how isolated individual components are;
• whether there is duplicated logic;
• what library versions are used;
• whether the project has documentation;
• whether the architecture is understandable;
• how risky future updates will be.

If a developer needs several days simply to understand why a particular feature works in a particular way, this directly affects the cost of the project.

CMS or Technology Used by the Existing Website

Updating a current WordPress installation with a clean theme and controlled plugin set is one type of task.

Working with an unsupported CMS, heavily customized legacy PHP, or a framework whose ecosystem has largely moved on is completely different.

Outdated technology does not only slow development.

It may also create problems with:

• security;
• server environments;
• package compatibility;
• library updates;
• future maintenance.

Sometimes a framework can be upgraded incrementally.

In other cases, the gap between versions is so large that building a new application beside the old one is safer and more cost-effective.

Whether the Backend Can Be Kept

This is one of the biggest factors affecting the final budget.

If the existing backend already handles the required business logic and provides a stable API, the team may focus mainly on UX/UI and frontend development.

But keeping the backend does not necessarily mean leaving it completely untouched.

The new design may require data the old API does not provide. Existing endpoints may be tightly connected to the previous frontend. New functionality may also require extensions to the backend.

Therefore, “we will keep the backend” should never be interpreted as “no backend work is required.”

Complexity of the New Design

A visually unique design does not necessarily require technically complicated development.

Frontend cost is affected much more by elements such as:

• complex animation;
• interactive sections;
• dynamic states;
• configurators;
• maps;
• large data tables;
• drag-and-drop interfaces;
• unusual scroll interactions;
• advanced filtering;
• real-time updates.

For example, a static section showing three pricing plans and an interactive calculator that recalculates pricing based on 15 different parameters may occupy roughly the same amount of space in a design file.

The implementation effort is completely different.

Mobile Responsiveness

In 2026, creating a responsive website does not simply mean shrinking the desktop layout.

Mobile interfaces often need:

• different content order;
• simplified data tables;
• alternative navigation;
• mobile-friendly filters;
• larger touch targets;
• adapted forms;
• optimized animations and media.

If the old website was never built on a proper responsive system, rebuilding the frontend may actually be cheaper than trying to fix hundreds of CSS exceptions.

Functionality and Integrations

CRM systems, ERP software, payment providers, delivery services, telephony, analytics platforms, email services, external catalogues, and third-party APIs all create dependencies.

They may not appear to change visually during a redesign, but the development team still needs to make sure they continue working correctly.

After the frontend is rebuilt, the team must verify that:

• leads still reach the CRM;
• ecommerce events are tracked correctly;
• payment systems receive valid data;
• delivery integrations work;
• external APIs return expected results;
• authentication remains stable.

The more integrations a website has, the larger the regression-testing scope becomes.

Content Migration

If the CMS and URL structure remain unchanged, very little content migration may be needed.

If the website moves to a new CMS or data architecture, however, the team may need to migrate:

• text;
• images;
• products;
• attributes;
• categories;
• SEO fields;
• authors;
• publication dates;
• files;
• structured data.

For an online store with 15,000 products, this becomes a separate technical task.

Automated import can significantly speed up migration, but the migration scripts still need to be developed, tested, and validated.

SEO and Preserving Existing Google Rankings

This factor is particularly important for websites that already receive organic traffic.

A redesign may appear to be a visual project, but from a search engine's perspective many things can change at the same time:

• URLs;
• HTML structure;
• internal linking;
• content;
• canonical tags;
• XML sitemap;
• indexing rules.

One of the worst scenarios is launching an attractive new website and only then discovering that important URLs now return 404 errors, pages were moved without 301 redirects, valuable content was reduced dramatically, H1 and title tags were replaced, and internal links from blog articles disappeared.

Canonical tags, robots.txt, XML sitemap, meta robots directives, and structured data also need to be reviewed.

For websites with meaningful organic traffic, an SEO migration plan should therefore be prepared before development begins, not on the final day before launch.

When Is a Redesign Enough, and When Should the Website Be Rebuilt?

The key question is not whether the old website looks dated.

The real question is whether its technical foundation can support the future needs of the business.

A redesign makes sense when the current website still has a healthy technical foundation. In this situation, the business does not need to pay again for logic that already works. For example, a corporate website may have a stable backend, administration panel, CRM integration, and dozens of well-indexed pages. If the main weaknesses are outdated UI, confusing navigation, and poor mobile experience, replacing the entire system may be unnecessary. Now consider the opposite scenario. The business wants to change navigation, every page template, the CMS, catalogue, API, checkout, customer account, and server-side logic. Technically, the project could still be called a redesign. In practice, however, almost nothing from the old system would remain except the content and domain. In this case, the modernization budget should be compared with the cost of developing a new website at the required level.

If the difference is relatively small, a new architecture may be the better investment because the company avoids continuing to invest in the limitations of the legacy system.

When Can Redesigning an Old Website Cost More Than Building a New One?

It may seem logical that modifying an existing system must always be cheaper than creating a new one.

In software development, that is not always true.

In a new project, the development team controls the architecture, component structure, library versions, APIs, and database model from the beginning.

In an existing project, the team first has to understand decisions made by someone else.

If documentation is missing, developers may need to reconstruct business logic by reading the code and observing how the system behaves.

Hidden dependencies can then appear.

Updating one library may break another. A legacy module may work only with a specific PHP or Node.js version. A CRM integration may rely on an undocumented endpoint.

Another difficulty is preserving existing business logic.

Imagine an online store where custom rules for discounts, delivery, order statuses, and accounting synchronization have accumulated over five years.

Even if some of those rules look unusual from the perspective of a new architecture, they cannot simply be removed. Real business processes depend on them.

The team therefore spends time not only implementing new functionality but also studying, protecting, and testing existing behavior.

Consider a simplified example.

Keeping the existing backend requires 80–100 hours for auditing, fixing legacy issues, and adapting the API.

Building the required backend functionality from scratch is estimated at 120 hours.

On paper, keeping the old backend saves 20–40 hours.

Once the risks of undocumented dependencies, more complex QA, and higher maintenance costs are considered, however, that saving may disappear completely.

In situations like this, a professional development team should not recommend repairing the old system merely because it already exists.

Website Redesign Budget Examples

The following examples illustrate how modernization budgets can differ depending on how much of the existing system can be preserved.

These are not fixed packages.

Small Corporate Website

Imagine a corporate website with 10–15 pages.

The CMS works properly, content can be edited easily, forms submit leads correctly, and URLs are already indexed.

The main problems are an outdated visual style, poor mobile experience, and ineffective service pages.

The project may retain:

• CMS;
• database;
• URLs;
• most existing content.

The team redesigns UX, the homepage and key page templates, creates responsive layouts, and updates forms and frontend components.

Approximate budget: $2,200–$4,000.

Typical timeline: 4–7 weeks.

Corporate Website With an Old CMS

Consider a website with 40–70 URLs, a blog, several language versions, and CRM integration.

The interface requires a complete redesign, while the CMS still works but the frontend theme is outdated.

The team first needs to determine whether the backend can remain.

Then the project may include:

• new page templates;
• frontend rebuild;
• CMS adaptation;
• partial data migration;
• SEO checks.

Approximate budget: $4,000–$7,500.

Typical timeline: 6–10 weeks.

If the audit shows that the CMS also needs to be replaced, the scope moves into full modernization.

Ecommerce Website

An ecommerce project may include:

• catalogue;
• categories;
• filters;
• shopping cart;
• checkout;
• payment processing;
• user account;
• CRM;
• delivery integrations.

Even a visual redesign affects many different states.

Products may be available or unavailable. Different delivery options may appear. Promo codes can be valid or invalid. Payments may succeed or fail. Mobile filters may behave differently from desktop filters.

If the existing ecommerce backend can remain but most of the frontend needs to be rebuilt, the budget may reach $6,000–$14,000.

A typical timeline is approximately 2–4 months, depending on the number of templates and integrations.

If the CMS, product architecture, or ordering logic also needs to change, the project becomes a full ecommerce migration.

Website With Customer Accounts or Complex Functionality

Imagine an online service where users register, create requests, download documents, communicate with managers, and view the history of their operations.

Here, the number of “pages” becomes much less useful as an estimation metric.

A single dashboard screen may contain:

• multiple states;
• role permissions;
• API connections;
• authentication checks;
• complicated business logic.

If UX, frontend, and part of the backend all need to be redesigned, the budget can reach $8,000–$20,000+, with a typical timeline of 3–6 months.

Website That Is 7–10+ Years Old

Age alone does not mean that a website needs to be rebuilt.

Some older systems still have simple, understandable architecture and reliably perform their task.

Problems arise when a website has been modified by multiple developers for ten years, accumulated dozens of plugins, moved between hosting environments, and received several partial redesigns.

In this situation, a technical audit is essential before estimating modernization.

Such a project may require approximately $4,500–$11,000.

But the more important question is not the number itself.

If the audit shows that 70–80% of the system needs to be replaced anyway, it may be more practical to develop a new version alongside the old website and migrate the business to it in a controlled way.

How Long Does Website Redesign or Modernization Take?

Small improvements may take several days.

A full rebuild of a complex platform may require several months.

Typical ranges are:

The reason is simple: “redrawing the design” is only one part of the process.

Before design starts, the team needs to understand the current structure and technical limitations.

After design, the new frontend must be developed, integrated with the backend, populated with data, tested across devices and browsers, checked for SEO issues, and launched safely.

Even having ready-made design files does not reduce this process to a few days.

For large projects, testing and migration alone may require as much time as the development of several key pages.

How Does the Website Update Process Work?

Professional modernization does not start in Figma.

The first step is understanding what already exists and which parts of the current system still have value.

1. Technical and SEO Audit

The team reviews:

• technologies;
• codebase;
• CMS;
• server environment;
• URL structure;
• sitemap;
• indexing;
• performance;
• Core Web Vitals;
• integrations;
• key page templates.

If the website already receives organic traffic, pages with existing search visibility are recorded separately.

The purpose of the audit is not to find as many problems as possible.

It is to divide the current system into three categories:

keep, improve, replace.

2. Decide What Can Be Preserved

There is no reason to rewrite an order-management module simply because the design of the product page is changing.

At the same time, there is little value in preserving an old WordPress theme if developers will spend most of the project fighting its limitations.

This stage determines the technical strategy of the modernization.

3. Create the New UX and Structure

Once technical constraints are understood, the team can work on user journeys.

The team determines:

• which pages remain;
• which pages should be merged;
• whether navigation needs to change;
• where CTAs should appear;
• how users move from initial visit to conversion.

If the existing information architecture already works, it does not need to be changed just because the visual design is being updated.

4. Design the New Interface

The project normally begins with key screens and a design system.

This includes:

• typography;
• colors;
• buttons;
• forms;
• cards;
• fields;
• spacing;
• reusable components.

Once the system is approved, applying it to additional pages becomes much faster.

Mobile behavior for complex elements should also be designed intentionally rather than left entirely to developers during implementation.

5. Frontend and Backend Development

The new frontend is connected either to the existing backend or to a newly built one.

At this stage, the quality of the initial audit becomes particularly important.

If dependencies were identified properly, the team works through the planned scope.

If development started without understanding the old system, this is where endless “unexpected” tasks usually appear.

6. Content and SEO Data Migration

Content migration should not be checked only visually.

The team also needs to preserve or correctly transfer:

• URLs;
• title tags;
• meta descriptions;
• H1 headings;
• canonical tags;
• images;
• alt attributes;
• internal links;
• other SEO elements.

Large websites often require a dedicated URL migration document.

7. Testing

Testing covers:

• mobile devices;
• desktop;
• major browsers;
• forms;
• APIs;
• authorization;
• payments;
• search;
• filters;
• analytics;
• third-party integrations;
• error states.

A website should not be tested only through the successful or “happy” path.

For example, a payment flow should be tested not only when a transaction succeeds, but also when it fails or a user returns to the website after an interrupted payment.

8. Launch and Post-Launch Monitoring

After the new version goes live, the team checks:

• page status codes;
• redirects;
• XML sitemap;
• robots.txt;
• forms;
• analytics;
• application logs.

SEO migration does not end on launch day.

Google Search Console, 404 errors, indexing, and the performance of priority landing pages should be monitored after release.

How to Redesign a Website Without Losing SEO Rankings

For a website with existing organic traffic, redesign should be treated as a migration.

A new version can be faster, cleaner, and visually much stronger, but that does not automatically guarantee that existing Google rankings will remain unchanged.

The core principle is to preserve as many valuable signals from the old website as possible.

If a URL already receives traffic, has backlinks, and is performing well, it should not be changed simply because a different URL would look cleaner.

When changing a URL is necessary, create a mapping table:

old URL → new URL → redirect type → reason for change

Moved pages should normally receive a 301 redirect to the most relevant new equivalent, not simply to the homepage.

Title tags, meta descriptions, H1 headings, and important content should also be recorded before migration.

During redesign projects, there is often pressure to shorten content dramatically because a shorter page may look cleaner.

That decision should be made carefully when a page already ranks for a broad set of relevant queries.

The migration should also include checks for:

• canonical tags;
• structured data;
• XML sitemap;
• robots.txt;
• meta robots directives.

Internal linking requires particular attention.

A change in navigation, related-content blocks, or page structure can cause important pages to lose a significant number of internal links even when their URLs remain unchanged.

Before launch, it is useful to crawl the old website and preserve the results.

After release, crawl the new version and compare:

• status codes;
• indexed URLs;
• titles;
• canonicals;
• internal links.

After launch, monitor Google Search Console for:

• 404 errors;
• indexing issues;
• crawl problems;
• ranking changes on priority pages.

Some short-term fluctuations may occur while Google recrawls and reassesses the website.

However, widespread disappearing URLs, rapid growth in 404 errors, or major indexing problems require immediate investigation.

A redesign without an SEO migration plan can reduce organic traffic even when the new website is technically and visually better than the previous version.

Can a Website Be Updated Gradually?

Yes.

A phased redesign can be a good solution when a company does not want to commit the entire budget at once or cannot pause product development for several months.

For example, the team may first update:

1. the homepage and core design system;
2. key commercial pages;
3. the blog and informational sections;
4. additional functionality.

This approach works especially well when the frontend is modular and old and new components can temporarily operate side by side.

Phased modernization also gives the business an opportunity to validate new solutions using real traffic instead of changing the entire website at once.

However, gradual redesign is not always the best approach.

If the project involves changing the framework, backend API, global authentication system, or data architecture, maintaining two versions simultaneously may make the project more complicated and expensive.

It can also be risky when frontend components are heavily interconnected.

In these cases, developing the new version in a separate environment, testing it thoroughly, and then performing a controlled migration is often the better approach.

How to Know When an Old Website Is No Longer Worth Repairing

There is no rule saying that every website older than five years should be replaced.

There are, however, several practical warning signs.

One of the strongest signals is when each new feature becomes more expensive than the previous one not because the feature itself is complicated, but because the existing system creates additional constraints.

For example, the company may want to add a simple new page template, but doing so requires modifying three modules, rewriting part of the theme, and retesting checkout functionality.

Other warning signs include:

• recurring technical problems;
• very slow page performance even after basic optimization;
• inability to create a proper mobile experience;
• unsupported libraries or CMS versions;
• server updates that break the application;
• disproportionately expensive simple changes;
• security problems;
• unclear or undocumented architecture;
• every modification creates new bugs;
• maintenance costs continue to rise.

A combination of several of these factors is especially important.

If the website simultaneously uses unsupported technology, has poor mobile usability, complex architecture, and requires major functionality changes, a cosmetic redesign will usually only delay the need for full modernization.

In that situation, the budget is better invested in a system designed to support the next several years of business development.

How to Prepare Your Website for a Redesign Estimate

The more information a development team receives before estimating the project, the lower the chance of getting an extremely broad range such as “between $3,000 and $15,000.”

For an initial assessment, start by providing the URL of the current website and a short description of what you want to change.

It is also useful to prepare:

• functionality that must remain;
• functionality that needs to be added;
• examples of websites or interfaces you like;
• Google Analytics and Search Console access where possible;
• information about the CMS or technology stack;
• hosting information;
• list of CRM, payment, or third-party integrations;
• planned structural changes;
• preferred launch timeline.

Analytics access is particularly useful when the structure needs to change.

For example, a business owner may consider one old page unnecessary, while Search Console data may show that this page consistently generates organic traffic.

Instead of deleting it, the team can decide how to preserve its value in the new structure.

For complex projects, an accurate estimate is sometimes impossible from the public-facing website alone.

The team may need to review:

• source code;
• CMS configuration;
• API documentation;
• database structure;
• infrastructure.

A few hours spent on technical auditing at this stage can prevent dozens of hours of unexpected development later.

Conclusion

The cost of website redesign depends less on how old the website is and more on how much of the existing system can still be used safely.

If the backend is stable, the structure works, SEO is healthy, and the main problems are related to UX/UI and frontend implementation, updating the website can be significantly more cost-effective than rebuilding it.

If the project requires replacing the design, CMS, frontend, backend, integrations, and architecture at the same time, repairing the existing system can easily become the more expensive and risky option.

Before choosing between “redesign” and “rebuild,” it is therefore worth conducting at least a basic technical and SEO audit.

WebUI Studio can review the current website, determine which parts are worth keeping, identify what needs to be rebuilt, and prepare a modernization estimate without unnecessarily replacing parts of the system that already work well.

FAQ

How much does a website redesign cost in 2026?

Minor design and UX improvements may cost approximately $500–$1,100. A complete UX/UI redesign of a corporate website can range from about $2,000 to $4,500. If the project also requires a new frontend or functionality changes, the budget can exceed $3,500–$8,500.

How much does it cost to completely rebuild an old website?

A complete modernization of a corporate website may cost approximately $6,000–$15,000 or more. Ecommerce websites, portals, and systems with customer accounts can require substantially larger budgets. The final cost depends heavily on whether the existing backend, CMS, database, and integrations can be preserved.

Is it cheaper to update an old website or build a new one?

Updating is usually cheaper when a significant portion of the existing system can be preserved without extensive modifications. If most of the frontend, backend, and architecture must be replaced anyway, building a new version can cost roughly the same or even less.

Can I redesign a website without changing the CMS?

Yes. If the CMS is stable and supports the required structure and functionality, it can remain while the UX/UI and frontend are replaced. The team should first verify how tightly the existing theme and templates are connected to the CMS.

Can website redesign affect SEO?

Yes. The biggest risks involve changed URLs, deleted content, incorrect redirects, modified H1 and title tags, lost internal links, and canonical or indexing errors. Websites with organic traffic should have a dedicated SEO migration plan.

How long does a website redesign take?

A redesign of a small corporate website may take approximately 2–5 weeks. If the project includes frontend development and backend integration, the timeline may increase to 1–2 months. Complex modernization can require 2–6 months.

Can a website be redesigned in stages?

Yes, provided that the architecture allows old and new components to operate in parallel. A company can update the homepage and key commercial pages first, followed by the blog and other sections. If the framework, backend, or overall architecture is changing, a phased approach can become more complicated and expensive.

When should an old website be rebuilt instead of redesigned?

A rebuild is usually worth considering when the technology is no longer supported, the code is difficult to maintain, the website frequently breaks, a proper mobile version cannot be implemented, or most new features require workarounds. If nearly the entire technical foundation needs replacement, building a new version is often the more rational option.