Occasionally calls come in like this: the site was originally made by another company, now unreachable, the site has issues with no one to fix them, and source code is unavailable—can you take it over? Taking over someone else's custom website begins not with rushing to find a fixer, but with inventorying assets on hand, then judging if it's worth repairing or better to rebuild. This article explains the evaluation criteria.
Stay Calm: Inventory Assets Before Taking Over
In practice, bosses often discover an unmanaged site and immediately ask who can fix it. But before seeking help, understand what resources are available. Spend half a day confirming the following items one by one.
For example, taking over a house built by someone else requires checking for keys, title, and utility accounts. A website is similar—domain is the address, hosting is the foundation, source code is the blueprint, and backend credentials are the door keys. Missing any item increases difficulty in subsequent handling.
One machinery parts export client approached us with only a working URL and nothing else: unknown domain registration location, unknown hosting provider, forgotten backend credentials. In such cases, tools may even be needed to reverse-lookup the server. The good news is that as long as the domain remains under control, solutions usually exist.
When inventorying, first answer these three questions:
- Who originally bought the domain (URL)? Under whose name is it registered? This determines ultimate control over the site.
- Is anyone charging hosting or domain fees annually? The payer usually holds the account.
- Can you still access the backend? Access means at least content can be edited, a relatively better situation.
7 Assets That Must Be Retrieved
After inventory, these 7 items must be retrieved before taking over any site. Sorted by criticality, the higher ones are more troublesome if missing.
| Asset to Retrieve | Importance | What Happens Without It | Where to Retrieve It |
|---|---|---|---|
| Domain Management Rights | ⚠️ Critical | URL may be suspended or transferred anytime, unrecoverable | Domain registrar (e.g., GoDaddy, Gandi, Chunghwa Telecom) |
| Hosting / FTP Credentials | ⚠️ Critical | Cannot access server or download existing files | Hosting provider backend, or the party charging hosting fees |
| Database | ✅ Necessary | All member, order, and article data lost | Hosting console (phpMyAdmin, etc.) |
| Source Code | ✅ Necessary | Cannot modify or migrate; must rebuild | Original vendor, or download via hosting FTP |
| Backend Admin Credentials | ✅ Necessary | Cannot even edit a line of text or swap an image | Original vendor, or reset via database |
| SSL Certificate | ⚠️ Important | Site shows "not secure," customers hesitate to order | Most can be re-applied for free; no need to retrieve |
| Third-Party Service Accounts | ⚠️ Important | Payment, email, analytics data disrupted | Payment provider, email service, GA backend |
A key concept: domain and hosting are separate, often registered in different places. Many bosses assume "since one company built the site, everything should be together," only to discover the domain is with company A, hosting with platform B, and backend set up by engineer C. Tracing one by one is the correct approach.
If the original vendor is truly unreachable, follow this order: first reverse-check via payment records (credit card statements or transfer records show the recipient holding the account), then confirm the registrar via domain WHOIS lookup, and finally appeal as the "domain owner" through the registrar. As long as the domain was originally registered under your company or personal name, this path is almost always viable.
How to Decide: "Repair" or "Rebuild" This Site?
This is the core judgment in takeover cases. I've seen too many bosses spend heavily rescuing a site that should have been rebuilt, and others hastily rebuild when minor fixes would suffice. The table below shows criteria used in actual evaluations.
| Criterion | Tend Toward "Repair" | Tend Toward "Rebuild" |
|---|---|---|
| Can source code be obtained? | ✅ Full source code in hand | ❌ Only a working URL |
| Technology age | ✅ Mainstream tech from last 5 years | ❌ Decade-old framework, no longer maintained |
| Code readability | ✅ Clear structure, with comments | ❌ Messy, incomprehensible |
| Scope of existing issues | ✅ Localized bugs, minor features | ❌ Full-site redesign needed |
| Data volume | ⚠️ Large member/order data to retain | ✅ Little content, low migration cost |
Judgment is simple: the more "rebuild" items checked, the less worthwhile hard rescue becomes. Especially "cannot obtain source code"—almost a veto. Without source code, engineers lack blueprints; every change is guesswork, and hours spiral out of control.
A common pitfall: bosses think "rebuilding costs money, so try fixing first," then hire engineers to patch. Engineers spend excessive time "guessing what the previous person intended," bills grow, and ultimately more is spent than rebuilding, yet the site retains old problems. The cost of taking over a mess is often severely underestimated.
Recommendation: first ask the new vendor for a technical audit (review code, check tech versions, estimate modification costs), then compare the report against the criteria above.
Handling Old Site Assets When Rebuilding
If the assessment is "rebuild," don't discard the old site entirely—some parts are valuable and worth migrating. Most important are accumulated data (members, orders, articles) and SEO assets (existing URL structure, search rankings).
If the old site still allows database access, members and orders can be exported and moved to the new site; if the database is also inaccessible, at least scrape visible frontend content (product data, articles, images) manually or with tools.
SEO is similar. Old URLs shouldn't be cut arbitrarily—if old pages already rank in Google, ensure "old URL to new URL" redirects are set during rebuild, or hard-earned traffic vanishes overnight.
Prepare These Before Finding a New Vendor
Before engaging a new vendor (whether for repair or rebuild), prepare the following to save significant back-and-forth time and yield more accurate quotes:
- An asset list: List domains, hosting, source code, backend credentials identified earlier; mark unavailable items as "unobtainable."
- Existing site issue list: What's broken, what to change, what to keep—be as specific as possible.
- Accessible permissions: If hosting or backend access remains, prepare credentials for the new vendor's audit.
- Original vendor contract (if found): May detail copyright ownership and delivery scope, serving as basis for clarifying responsibilities.
Honestly, the preparation process itself helps clarify "what exactly is on hand." The more complete the preparation, the faster the new vendor can assess, and the less likely quotes will contain ambiguities.
Why Source Code Is Unobtainable, and How to Avoid Being Held Hostage Next Time
By now, it should be clear—the root of these troubles almost always points to one thing: the original contract never clearly stated "who owns the source code and how it will be delivered."
In practice, inability to retrieve source code usually stems from three scenarios: the vendor intentionally withholds it as leverage to prevent switching providers; the vendor closes or staff depart, leaving no one to deliver; or certain "locked" platforms or templates were used, making full source code technically unobtainable from the start.
So how to avoid stepping into the same pit next time? Before signing, confirm these points in writing:
| Item to Confirm | Why It Matters |
|---|---|
| Source code delivery method and timing | Specify "full source code delivered within X days after launch" to avoid disputes later |
| Domain registered in your name | Never let the vendor register the domain under "their name"—this is the most fatal hostage point |
| Hosting under an account you control | Hosting account is best under your own name, or at minimum credentials must be obtainable |
| Backend and third-party accounts held by you | Payment, email, analytics accounts should all be yours, not the vendor's |
| Copyright and usage rights ownership | State clearly to avoid future disputes |
Conclusion: Inventory First, Then Decide Repair or Rebuild
Taking over someone else's custom website isn't scary—what's scary is acting without first understanding what cards you hold. Remember these 3 points:
- Inventory before acting—Confirm domain, hosting, source code, backend credentials one by one; domain and hosting are lifelines, prioritize retrieving them.
- Don't force repair without source code—Without blueprints, every change is guesswork; hours spiral out of control, and rebuilding is usually more cost-effective.
- Clearly document delivery and ownership in future contracts—Full source code delivery and domain registered under your name are fundamental to avoiding future hostage situations.
