Software Project Takeover: First Aid When Your Developer Is Gone

Before you think about a takeover, secure what exists. Start by checking which access you hold yourself: the hosting panel (Plesk, cPanel), CMS login, domain management, code repositories (GitHub, GitLab), cloud and email accounts. Search old emails, invoices, and contracts for credentials — the original setup emails often contain more than you expect.

While any access still works, create a complete backup: website files, databases, email mailboxes, source code, and a list of every API key and third-party service. If you are in an active dispute with the provider, also change the passwords on every account registered in your name.

Clarify the domain. What matters is who is listed as the registered domain holder. If that's you, your registrar can help you move forward. Transferring to a new provider requires an auth code; for .de domains, if the old provider refuses to cooperate, DENIC — the German .de registry — offers the AuthInfo2 procedure. Any transfer lock on the domain has to be lifted first.

On the legal side: set the previous provider a written deadline, sent by registered mail — even if they no longer respond. This documents your claims for every later step, and it runs in parallel with the technical securing work, not instead of it.

The answer is sobering: under German law, copyright in software cannot be transferred at all. As the client, you receive usage rights, and their scope is whatever the contract says. If the contract is silent, German courts apply the purpose-of-transfer doctrine (Zweckübertragungslehre): you hold only a simple, non-exclusive usage right limited to the original contract's purpose — with no automatic right to have a third party continue development.

You also have no automatic claim to the source code. Germany's Federal Court of Justice (BGH) has ruled that even fully paid custom software does not come with a source-code handover obligation by default. Such a claim can exist if it was apparent to the contractor that third parties would later need to modify the software. Section 69b of the German Copyright Act — which assigns the economic rights in software to the employer — applies only to employed developers; with freelancers and agencies, the contract alone decides.

If the agency becomes insolvent, your license can fall into the insolvency estate; for contracts not yet fully performed, the insolvency administrator may elect non-performance. The BGH's "M2Trade" and "Take Five" rulings (2012) did at least clarify that simple usage rights can survive the loss of the main license. In practice, though, a usage right without source code and documentation is worth very little — which is exactly why the technical securing steps are so urgent.

A serious takeover starts with a technical assessment — not with a quote. What has to become visible: dependencies, interfaces, data flows, risks, and how the system has been operated so far. The result is a written report that belongs to you — even if you award the follow-up work to someone else.

For timing expectations: a compact scope (backend only) typically delivers first results in 5 to 10 days; a comprehensive review across frontend, backend, and processes takes more like 2 to 4 weeks.

Only then comes the core decision: can the existing code be built on, or is a rebuild the more economical path? That question can only be answered with the code in front of you, not over the phone. QubeLogix works in exactly this order: assessment with a written report first, then a concrete offer for continued operation, stabilization, or further development.

"This all needs to be rewritten from scratch" — said before anyone has seen a single line of your code: that is the biggest red flag. A rebuild is sometimes the right answer, but as a diagnosis without an examination it is a sales pitch, not advice.

Further warning signs: a flat-rate quote without a prior assessment; no written report you are allowed to keep; domain, hosting, or repositories that are to be registered under the new provider's name again — which would recreate exactly the dependency you are paying dearly to escape; and no clear statement about which documentation you will receive at the end.

Project takeover is a specialist discipline. Not every agency will touch someone else's code, and many decline outright. A provider that starts by asking questions about the existing system and names its own limits is usually a better sign than one that commits on the spot.

QubeLogix charges the following prices (net; no VAT charged under Germany's § 19 UStG small-business rule): takeover and setup — technical assessment, securing access, migration to accounts in your name, and a baseline of documentation — from €1,900. Short-term bug fixing and support blocks from €490. Ongoing maintenance and operations from €250 per month.

Larger development work after the takeover is quoted separately; the development day rate is €900. For extensive legacy systems, plan modernization in stages and insist on interim deliverables — a complete rebuild in a single pass is rarely the lowest-risk option.

In your next development contract, put five points in writing: the scope of usage rights (exclusive or simple), the right to modify the software, transferability of the rights, an obligation to hand over the source code, and a documentation obligation. Add an insolvency-proof license clause: if the provider becomes insolvent, a temporary license converts into a permanent one.

Account ownership: domain, hosting, code repositories, and cloud accounts belong in your name — you invite the provider in as a user, not the other way around. This costs nothing and prevents a large share of the cases in which companies end up locked out of their own software.

For business-critical custom software, source-code escrow is worth considering: the source code is deposited with a neutral third party and released to you if the developer becomes insolvent. Entry pricing at HanseEscrow, for example, is €1,200 in the first year and €950 in subsequent years; costs rise with the verification level (completeness, compilability) and redundant deposits. Other providers include TÜV SÜD, Deposix, and Codekeeper.

Standard software instead of custom development: if your website runs on WordPress with a standard theme, a shop builder, or a SaaS product, you don't need a takeover project — you need a new caretaker. Securing access plus a maintenance contract is enough; a deep code analysis would be a waste of money here.

Cooperative exit: if the previous developer is reachable and willing to hand over in an orderly fashion, an accompanied handover is far cheaper than a rescue. Insist on complete access credentials and documentation; often that is all it takes.

Planned replacement: if the software is going to be replaced in the foreseeable future anyway, a clean data export plus minimal operations until the switchover is usually sufficient. That can be commissioned too — but it is a smaller, cheaper undertaking than a full takeover.