The Vendor Went Silent After Delivery — How to Recover the Domain, Server, and Repository

The site still loads today. Orders come in, the admin screen still accepts a login. But the account manager at the vendor stopped reading messages last month, and the main office number is disconnected. Nothing is down. The problem is that there is nobody to touch it when something goes down.

Three dates come before anything else. Hunting for the source code can wait. Each of these three stops the service on a fixed day, with no warning.

The domain expiration date

The SSL certificate expiration date

The name and expiry on the card the cloud and domain charges are billed to

For the domain, run whois on the address from a terminal and read the Expiration Date field, or use the lookup form on the registrar's own site. When a domain expires, the site is not the only thing that stops — company email on that domain goes with it. If order confirmations, tax invoice notifications, and password-reset messages from other services were all arriving at that address, the recovery channels close in the same moment. A gTLD such as .com does not vanish the instant it expires. Under the ICANN lifecycle it moves into a Redemption Grace Period (about 30 days) and then Pending Delete (5 days). It can be brought back during the redemption window, but a separate redemption fee applies, and both the fee and the days remaining are set by the registrar, so ask the registrar directly.

For the SSL certificate, click the padlock in the browser address bar and open the certificate details to see the validity period. Free certificates (Let's Encrypt) are valid for 90 days, which means a renewal job has to keep running on the server for them to hold. If that renewal is wired to a script the vendor wrote or an account the vendor owns, it stops one day. When the certificate expires, every page shows a warning screen and visitors leave at that point. Server-to-server traffic that no human can click through — payment authorization calls, social login callbacks, webhooks arriving from outside systems — has no way to dismiss the warning and simply fails.

The card question is whose name the cloud bill and the domain renewal are charged to. If not a single monthly receipt has arrived in your own inbox, you may not be the party paying. Check the billing screen in the cloud console, or ask the registrar's support desk which account is billed. If the charges were running on the vendor's card, they fail the moment the vendor shuts down, and once the arrears build up the account is suspended — which locks you out of the data as well. In that case the service can stop before either the domain or the certificate expires.

Your real deadline is the nearest of those three dates. Put it on a calendar and plan to finish the ownership checks and recovery requests below inside it. If contact broke off recently and the contract term is still running, the demand letter and the termination-and-settlement route in what to do when an outsourced developer goes silent or falls behind come first. This guide covers what happens after that stage, once there is no contract left to hold anyone to.

The sense that "it's our site, so it's ours" and the ownership actually on record run on separate tracks. The domain can be in your name while the server sits in the vendor's account; the server can be yours while the app was published under the vendor's developer account. One asset being yours does not move the service if the rest are not. Look up all five separately.

The difficulty column is a classification based on one thing: whether recovery requires the other side's consent. It is not drawn from a survey sample, so re-judge it against your own situation.

On gTLDs the registrant's personal details have been redacted since GDPR, but the registrar name and the nameservers are still visible, and those two alone settle which company you need to contact. After that, testing beats researching. Try a login or a password reset at that registrar or cloud provider using your company email address. If the reset mail lands in your inbox, ownership is on your side; if it reports no account on file, it is on the vendor's. If the vendor set up your company email as part of the build — an arrangement we see on small projects — open that mailbox too: signup confirmations and invoices may be sitting in it, and that mailbox is reachable only while the server is still running.

For the code repository, start with whether it sits under an organization account or a personal one. Under an organization there is a clear owner to ask to add your account to the owners list. Under a personal account the platform will not hand it over for you, so the first thing to check is whether the contract contains a clause transferring economic rights in the copyright. Where that clause exists, it is the basis for your claim. The criteria are set out in who owns the source code.

Payment accounts have one more lookup channel. If the settlement account at your payment gateway (PG) is your own business bank account, call the PG's support desk with your business registration number and ask them to look up the merchant account holder. If it comes back in your name, ask on the same call what the procedure is for reissuing the integration keys and which documents they need. Reissuing keys can stop payments that were running on the old keys, so line up a developer to install the new ones before you file the request.

Work in this order.

1. Request the handover in writing and leave a record

2. Determine whether the company has shut down or is merely unresponsive

3. Assemble the ownership evidence in one bundle

4. File separately — the domain with the registrar, the server with the cloud provider

5. Prepare the migration in parallel while you wait

Send the handover request by email and by text even knowing no answer is coming. When you later file with a registrar or a cloud support team, the record that you attempted contact and received no response is itself evidence. Use a channel that preserves the date and the content. In the request, list each item to be handed over one by one — the domain name, the server account email, the repository address — and give a deadline for reply. If the contract has a deliverables-handover clause, cite the clause number. It carries straight across when you escalate to a formal demand letter.

Next comes the question that changes what you do with the rest of your effort: has the company formally shut down, or is it merely not answering? A demand letter still has force against a company that exists and is ignoring you, and none at all against one that has been dissolved. The way to tell is a company-status lookup at the national business or tax registry. In Korea that is the business-registration status lookup operated by the national tax service, which returns active, suspended, or closed against a business registration number — and that number is printed on your contract and on every tax invoice. For an incorporated company, pull the corporate record from the corporate registry in the jurisdiction where the company is incorporated and look for a dissolution or liquidation filing. Screenshot the result either way. If closure is confirmed, there is no counterparty left to negotiate with, so stop waiting for a reply and move to each platform's own procedure. If the record shows an active business that simply will not answer, a formal demand letter (certified mail or legal notice) is still worth sending, addressed to the registered head-office address so that delivery is on record.

Then assemble the ownership evidence in one bundle. Required documents differ by provider, so ask each channel for its own list before filing — but gathering the following into a single folder in advance cuts down the back-and-forth.

The contract and the quote

Bank transfer records for payments you made, plus tax invoices

Card statements showing the domain and server charges

Your business registration certificate (or the equivalent company registration document in your jurisdiction)

Email and messenger history with the vendor, in date order so the requests and the silence are both visible

A screenshot of the company-status lookup result

Trademark registration certificate, if you hold one

The trademark certificate is on that list because recovering a domain on the strength of a mark runs through the Uniform Domain-Name Dispute-Resolution Policy (UDRP), which requires trademark rights, registered or unregistered, before a case can begin — though an unregistered mark means separately establishing the reputation, which is markedly harder. Even with a mark, all three elements have to be made out: that the domain is identical or confusingly similar to the mark, that the holder has no legitimate interest in it, and that it was registered and is being used in bad faith. Where the vendor registered the domain at your request and on your behalf, how you make out that third element becomes the contested point.

Domain and server go through different channels, so file them separately. For the domain, ask the registrar's support desk about a registrant change or an account recovery. If a domain carrying your trademark verbatim is held in the vendor's name, the dispute route above is also on the table — and when it is, write the cost and the elapsed time of the dispute next to the cost and the elapsed time of moving to a new domain, then decide from the comparison. What belongs in that comparison is the search traffic arriving on that domain, the business cards and signage and vehicle decals already printed, the email address your customers and suppliers know, and your business listings on search and map services. The less there is to change, the shorter the new-domain path.

Taking over a cloud account outright requires the other side's consent as a matter of principle. An account transfer means changing the root account email and the payment method, and that control sits with whoever holds the root credentials. So set the realistic objective at getting the data out. While you still have access to the admin screen or the server, pull the database dump, the uploaded files, and the configuration values down to storage you control. Then even if the account is never recovered, the service can be stood up again on a new server.

Finally, prepare the migration while the recovery requests are in flight. A tight expiry date leaves no room to work in sequence. If the registrar account opens, renew on your own card first to buy time; while it stays closed, prepare a new domain and a new server alongside. Use whichever opens first. There is no need to commit in advance to recovery or to rebuilding. Preparing the new server can stop at opening the account and registering a payment method — the migration work itself starts once the data is in your hands.

With no accounts, no code, and only the running screens, the line between what can be recovered and what has to be rebuilt is clear.

Whatever the browser renders, you can keep. The page in front of you has already been downloaded to your own computer. Capture every page with a full-page screenshot, admin screens included, and write the name of each screen and what each button does beside it. That becomes the specification you hand to the next vendor. What it does not contain is the original source code you could edit.

Get the data out now. If the admin screen has an Excel export, download members, orders, and posts today. It works only while the service is alive. With no export function, the fallback is transcribing screen by screen. Personal data comes out with it, so decide where the files are stored and who can reach them before you start, and put a password on what you transfer. Passwords themselves cannot be carried across at all: in a properly built system they are stored as hashes and no original remains. For member accounts, the workable route is sending a password-reset invitation from the new system, or moving people to a fresh signup.

You already have the documentation; it is just scattered. The first quote you received, the feature explanations left in chat and email, the revision requests exchanged during acceptance — those are the only requirements specification in existence. Collect them in date order into one file and hand that to the next vendor, and the quote gets more accurate. Give them the screenshots alongside it and there is less for them to ask about.

From here it is redevelopment. Even where the source code survives, analyzing undocumented code can take 2-4 weeks. With no source at all there is no analysis phase and everything is built new. One condition works in your favor: a running set of screens means what to build is already settled, which cuts down the planning rounds. So start while the service is still alive. Once it stops, neither the screens nor the data can be seen. How quotes are structured when taking over an existing system is set out in legacy improvement and refactoring quote criteria.

When you start with the next vendor, keep every account that money flows out of in your own name and give the vendor permissions only. Permissions can be revoked at any time; ownership can only be moved back with the other side's consent, and the moment contact breaks off, the way to obtain that consent disappears — which is exactly what happened here.

Agree the items below in the contract before development starts, or at minimum in writing by email. Asking for them after the build is finished turns them into a job of moving accounts already created in the vendor's name, and that carries its own schedule and cost.

Which name the server and cloud bills should be charged to, and what goes out every month once you are in operation, is covered in more detail in who pays for the server and cloud.

If you are taking over an existing system or standing it up again, scoping can begin from the screens and the data that remain. Send us what the current state looks like and Freesi will split it into what can be taken over and what has to be rebuilt.