How Much Can You Save by Keeping Your Existing Backend During a Website Redesign?

How much you can save by keeping the existing backend during a website redesign depends on how much of the old system can be reused as-is. If its product management, content publishing, inquiry workflows, and permission features meet the needs of the redesigned site, retaining the backend can reduce the cost of rebuilding these modules and some data migration expenses. If the new pages require extensive interface changes and the old system has accumulated maintenance issues, the potential savings will be smaller.

Therefore, when approving a website redesign budget (costo de rediseño web), do not simply apply a percentage based on “how much cheaper it is to keep the backend.” A more reliable approach is to ask suppliers to quote both options for the same scope of work, then calculate the additional costs of compatibility work, repairs, and ongoing maintenance under the retention option.

The main savings come from avoiding the rebuild of existing business capabilities

For websites serving foreign trade companies or manufacturing plants, the backend may already support product categories, technical specifications, downloadable materials, multilingual content, and sales inquiry management. Keeping these functions can reduce the work involved in redevelopment, importing historical data, configuring user permissions, and training staff.

However, page design, mobile adaptation, front-end development, browser compatibility, and launch testing still need to be completed to meet the new requirements. Even if the database remains unchanged, changes to how the new pages access product images, filter options, and form fields may require modifications to interfaces and templates.

“Keeping the backend” can also mean different things. Retaining only the data, keeping the existing admin interface, or retaining the interfaces and deployment environment as well all involve different workloads. If a quote simply says “reuse the existing system,” it is difficult for the finance team to determine which costs have actually been avoided.

Ask the supplier to break down the costs into three parts: design and front-end work required for both options; backend redevelopment and migration work avoided by keeping the existing system; and the additional adaptation and repair work required by the retention option. The difference between the latter two is the closest estimate of the actual savings on this redesign.

Use the same requirements checklist to calculate an approvable cost difference

Initial net savings = total cost of the rebuild option for the same scope − total cost of the option that retains the backend. Both quotes should cover the same number of pages, language versions, features, testing, launch support, and taxes. Otherwise, the price difference may reflect a reduction in deliverables.

Here is a hypothetical example purely to illustrate the calculation: a complete rebuild is quoted at RMB 100,000, while a basic redesign that retains the backend is quoted at RMB 70,000, which appears to save RMB 30,000. But if interface adaptation, repairs to the old system, and additional testing cost another RMB 10,000, the initial total for the retention option is RMB 80,000. The actual savings are RMB 20,000, or 20% of the rebuild budget. These figures only illustrate the calculation method; they do not represent market prices or industry averages.

Next, consider ongoing expenses. If licensing, maintenance, and necessary upgrade costs for the retention option are RMB 10,000 higher than those for the rebuild option over the same comparison period, the cumulative savings fall to just RMB 10,000. When seeking approval, choose a comparison period that matches the company’s planned use, and distinguish confirmed costs from those triggered only under certain conditions.

Historical plugin renewals, interface usage fees, service provider handover, data export, and maintenance of the old environment are among the costs most likely to be overlooked in this type of budget. For adaptations that have not yet been assessed, specify the scope of the review, pricing method, and change approval conditions in the contract to avoid ongoing additional charges after signing a low-price agreement.

Which backends are worth keeping, and which can make a redesign increasingly expensive?

Keeping the backend is more justifiable when the redesign mainly addresses an outdated look, mobile user experience, and content presentation, while the underlying business processes remain largely unchanged. This assumes that the company can obtain the necessary administrative permissions and interface documentation, as well as code or service support suited to its maintenance approach, and that the incoming team can handle deployment and troubleshooting.

If the redesign involves restructuring multilingual content, upgrading product filters, adding e-commerce transactions, or integrating with a customer management system, first verify that the old system can support these changes. For example, if the existing backend has only one field for product descriptions, while the new site requires parameters, downloadable files, and search information to be maintained separately for each language, reusing the backend may still require substantial modifications.

Before approval, ask the technical lead to clearly answer the following questions:

• Which new requirements can be reused as-is, and which require changes to the data structure or interfaces?
• Can the existing operating environment, plugins, and licenses continue to be used, and who will cover the maintenance costs?
• Can the incoming team handle backups and recovery, security updates, and troubleshooting?
• If the service provider changes later, can the data, configuration, and necessary documentation be handed over in full?

If these questions do not have clear answers, there is little basis for the low quote to retain the backend. For systems that can only be modified by the original supplier, also compare response times, change rates, and exit terms to avoid turning one-time redesign savings into long-term maintenance costs and dependence on the supplier.

For marketing websites, also account for continuity in inquiries and advertising

Keeping the backend does not guarantee that search traffic and advertising performance will be preserved. A redesign may change page URLs, content structure, form submission methods, and conversion tracking. How old URLs will be redirected, whether inquiries will enter the correct sales workflow, and whether ad conversions can be tracked accurately should all be included in the deliverables and acceptance criteria.

If the company also purchases advertising tools such as AI+SEM Intelligent Ad Placement Marketing System, list the related integration and acceptance costs separately, and check that the website data required for monitoring core metrics and data analysis is complete. The tool provides monitoring capabilities, but the website must also be configured correctly to support comparisons of performance before and after the redesign.

For websites with ongoing advertising campaigns, the launch plan should also cover form testing, checks of key landing pages, and preparations for rollback. Potential losses in inquiries are difficult to price precisely in advance; acceptance criteria can help reduce risk. Avoid using unsupported revenue forecasts to overstate the advantages of either option.

The budget submitted for final approval should clearly state how much redevelopment work will be avoided, what additional costs retaining the old system will incur, and what other confirmed costs will arise during the comparison period. As long as the cost difference is supported by an itemized list, the functions have been verified, and maintenance responsibilities are clear, keeping the backend represents a quantifiable saving. If the apparent advantage mainly comes from omissions and subsequent additional charges, the lower figure in the budget should not be used as a basis for the decision.