After Custom Website Development, If You Want to Switch Maintenance Companies but Can't Get the Full Original Code, Do You Have to Rebuild?

After custom website development, if you want to switch to another company for maintenance, not getting the full original code does not mean you have to rebuild, but the smoothness of the handover depends on whether the previous company handed over runnable source code, a database, and account credentials. Based on 2026 project delivery experience, for a typical custom corporate website with complete materials, it usually takes a few days to two weeks for the new maintenance provider to take over and understand the structure; for projects lacking documentation, credentials, or deployment steps, the provider has to reverse-engineer first, often leading to significantly higher quotes and timelines—sometimes close to rebuilding.

Why Switching Maintenance Companies Can Also Get Stuck

In users' eyes, a website is just "a bunch of pages that can be opened"; when switching maintenance providers, what really needs to be handed over is a set of runnable assets, including front-end source code, back-end code, database, server permissions, domain console, and third-party services. Many websites only deliver the live front-end outcome without organizing these assets into handover materials, so the new company dares not make commitments, and the original company says, "It's not that we won't provide them; we didn't keep them back then."

• The domain, server, and ICP filing may be under different handlers' accounts, so after personnel changes, you might not even find the login entry.
• The live files may be minified or encrypted, without editable local source code, making future modifications guesswork.
• The database may only have an exported backup, without rebuild scripts or field documentation, making it difficult to restore on a new environment.
• SMS, payment, map, and other services may be bound to the original company's entity, requiring new API keys when switching servers.
• The original contract may not include handover obligations, or final payments are unsettled, so the other party is unwilling to cooperate.

When we take on handover assessments, we've encountered a typical scenario: the client only has packaged live website files, while the database, back-end source code, and server console are all with the original company, and the original company is unreachable (constraint). Our approach is to first run a "clean-environment deployment recovery test," checking the source code, database scripts, and external service credentials item by item (method). As a result, two projects took an extra three weeks of back-and-forth to complete migration, with costs about 40% higher than a normal takeover—this is the "missing materials" tier in the experience range: when materials are complete, handover takes a few days to two weeks; when materials are missing, it typically stretches to three to eight weeks. In some cases, the assessment fee alone approaches the first year's maintenance cost, making the switch no longer cost-effective.

Before Switching, Do These Four Checks

Breaking the handover issue down, the main factors affecting how fast a new company can take over are four areas. Before asking for quotes from new companies, do a self-check in the following order to save a lot of time arguing.

1. Can the source code be independently restored: You need front-end source files, back-end project, database scripts, and the ability to redeploy in a clean environment; only packaged files do not count as complete source code.
2. Are the domain and server permissions controllable: At least one person should be able to access and operate the domain registrar, server console, and ICP filing account; otherwise, you'll get stuck during site migration.
3. Is third-party service registration clear: The login entry, account entity, and expiry date for payment, SMS, file storage, and analytics code should be listed.
4. Is the original maintenance relationship closed: Whether the original contract is terminated, any outstanding payments, and whether the handover deadline and material obligations are included in the terms.

If all four checks pass, the new provider is usually willing to commit to response times; if source code is missing, the website can only support shallow content maintenance; if domain, account, or ICP filing information is missing, the handover will require extra effort for migration and repeated configuration, multiplying time and costs.

Continue with the Original Team or Switch? Compare Four Aspects Before Deciding

According to common 2026 maintenance contracts, website maintenance is usually signed annually, with the quote including basic bug fixes and a limited number of minor changes. Whether to switch can be viewed from four dimensions:

• Change cost: The original team knows the code, so minor changes have lower communication costs; a new team needs to get familiar first, and it's common for similar changes to incur several extra person-days. In the experience range, the first minor changes by a new team often cost 3 to 10 extra working days compared to the original team.
• Responsiveness and stability: If the original team is still providing normal service, renewing short-term is less troublesome; if the team is unreachable or chronically delayed, switching is just cutting losses—don't wait for improvement.
• Code health: For an old site with documentation and version history, the handover cost is low; for an undocumented old site, the first month or two after handover can only be spent on understanding the code, so it's not wise to pile on new requirements at the same time.
• Deployment location: If you only change the maintenance contact without changing servers, the risk is much lower; if you need to move to servers under the new company's name, confirm the ICP filing status with the access provider first to avoid domain resolution interruptions.

One judgment criterion: whether to keep the original company should not depend on "who built it initially," but on whether they can reliably handle future changes; website maintenance is a long-term service, not determined by one delivery.

To Reduce Future Handover Costs, Prepare Three Things During the Development Phase

Instead of scrambling to gather materials when changing teams, it's better to follow the standard of "handover-ready for any developer" from the design and development phase. In our team's custom projects, we emphasize three corresponding items, not just document thickness.

1. Version and commit history: Track what was changed in each release, avoiding verbal arguments about "what was changed in the last version."
2. Deployment and configuration instructions: Clearly document server environment, database import, and static resource publishing; being able to restore and run on a new environment based on documentation is the pass criteria.
3. Third-party service registration form: Record the management address, account entity, and expiry date of external services; otherwise, there's no entry point to troubleshoot when problems arise.

You can do your own acceptance test: ask a developer who has never been involved in the project to restore the website from scratch using the existing materials, then modify a content section in the backend and roll it back. If this succeeds, the website is ready for a team change at any time, and you'll have more leverage when negotiating prices.

When to Switch, and When to Hold Off

Whether to switch, you also need to distinguish two questions: can you switch, and is it worth switching now. For corporate websites that only need text and image updates, staying with the original company for maintenance is usually more time-efficient; if you need to integrate payment, membership, or core process adjustments, and the old code lacks documentation, switching may also uncover a chain of hidden issues.

Suitable for switching: The original company has closed or the contact is unreachable; after the maintenance contract expires, the price increase is significant and service boundaries are not stated; the website is about to integrate a new system, and the existing code has no architecture documentation.

Not suitable or unnecessary: The website is built on an online website builder or SaaS platform without transferable complete source code—switching companies only means changing the operations administrator; the project is still within the free maintenance period, so existing issues should be handled by the original company first; before a large-scale redesign, consider evaluating a rebuild instead of spending another assessment fee on old code.

Another boundary: if the upfront assessment cost of a handover approaches two years of maintenance fees, not switching is also a rational choice. Keeping old code doesn't mean preserving business capability; if major changes are needed, building a new site may actually be more cost-effective.

Common Questions

Do I necessarily need to get the complete source code when switching maintenance companies?

If you only change text and images, source code isn't strictly necessary; but if you need to change features or debug bugs, the new provider needs buildable front-end and back-end source code; otherwise, every change is guesswork, and long-term maintenance costs will rise.

What if the original developer won't provide the complete code?

First, check whether the contract stipulates source code and material delivery obligations; if yes, demand fulfillment accordingly. If not stipulated, you can only negotiate—this is a major reason why website handovers get stalled.

Will switching maintenance companies affect search rankings?

As long as domain resolution doesn't break, URL structure isn't arbitrarily changed, and temporary downtime is handled in advance, switching providers itself won't make rankings disappear; ranking fluctuations are more related to website content and server stability.

How long does a new company usually take to fully take over?

For a typical corporate website with complete materials, familiarizing with the backend and code takes about one to three days; for sites missing documentation and source code, it typically takes one to three weeks for assessment, and quotes will be correspondingly higher—this is a common experience range.

If you are considering switching maintenance providers, don't rush to sign a contract. Send the four-item checklist above to the new company and ask them to do a pre-takeover inspection and provide a written report. Again, emphasize the applicable boundary: for corporate websites that don't involve feature iterations, staying with the original company is more cost-effective; once you need to touch the database, APIs, or make version-level changes, if the website's runnable source code cannot be preserved, rebuilding is often more cost-effective than rescuing the old system.