If your business depends on software whose developer can no longer be reached, whose source code is incomplete or which has no documentation at all, we take that system over, establish how it works on the basis of evidence, and bring it back to a state where it can live on.
Prepared by Pan Innovation House, a software company based in Gaziantep, Türkiye · Last reviewed:
Many manufacturing businesses in Türkiye still run on a custom program written fifteen or twenty years ago by a single developer. As long as the system works, no problem is visible; but when the developer retires, contact is lost or the relationship breaks down, the picture is always the same: the source code is missing or incomplete, nobody knows how any given calculation inside the program is performed, no new feature can be added, and even a small bug carries the risk of stopping production.
This is not a software development problem; it is an archaeology problem. Writing a new program is impossible without knowing the correct behaviour that the running system must be replaced with — and that behaviour is written down nowhere; it lives only inside the running code and the database. So the first step of the job is not writing code but collecting evidence: extracting the business logic from the compiled application, mapping the objects in the database, and clearly separating what is certain from what is inference.
Our method in a takeover is this: we examine a compiled application and its database only where you can show that you hold the rights to the software or have written permission from the rights holder. Every finding is labelled by evidence level: what is read directly from the code is marked verified, what is inferred from several independent indirect clues is marked probable, and anything without a sufficient source is marked unverified. An unverified finding is not handed over as if it were verified. The most dangerous thing in a takeover is to hand over a guess as if it were fact; that distinction sits at the centre of our method.
Businesses whose production, cutting, order or progress-payment tracking runs on a program written by one person who can no longer be reached. The system may still be running; but it cannot be changed or migrated, and there is nobody to step in when it fails.
Companies whose commercial relationship with their software firm has ended, or who are unhappy with the quality of service. During handover we verify that the source code has been delivered in full, and make the transition safe by demonstrating that we can stand the system up independently.
Businesses where a critical system is carried by a single employee or consultant. Transferring the knowledge to the organisation before this person leaves is far cheaper than trying to extract it afterwards; the handover file reduces this dependency in a measurable way.
Parties who want an independent view of the technical state of a company, division or software asset before buying it, together with family businesses passing to the second generation. We put in writing what is being taken over, what risk is being carried and what continuity depends on.
Analysing the compiled application, reconstructing the screen and menu hierarchy, establishing which screen touches which table and in what order the calculations are performed. The result is a readable map of business rules describing what the program does.
Rewriting stored procedures, functions and views whose source cannot be found, working from where they are called, the parameters they take and the results they produce. For each object the contract and the body are handled separately; the result is compared with existing outputs on a copy taken from live data, and any object that cannot be confirmed is marked as unverified in the report.
Identifying dependencies, licences and configuration; setting up an environment where the project can be compiled and run from scratch. The handover counts as complete only once this step is done; software you cannot change keeps you dependent in practice.
A report in which every finding is labelled with its source: certain knowledge read directly from the code, probable findings drawn from the intersection of multiple indirect clues, and areas that could not be verified for lack of sources are each shown separately. That way you know what you do not know as well as what you do.
Keeping the system running throughout the takeover: closing critical bugs, backup and restore drills, priority response to failures that stop production. The business does not stop while the analysis runs.
If the decision goes towards a rewrite, the old and new systems run side by side for a period; the transition is not considered complete until the outputs produced from the same inputs match exactly. Instead of a one-shot cut-over, we design a transition that can be rolled back.
Not every program whose developer has gone, or whose support has ended, needs a takeover. If the original developer or firm can still be reached, an agreement with them is usually the first route to try; if what the program does is standard, moving to an off-the-shelf package may make sense. The first table below sets out four routes side by side: when each is enough and where it struggles. We ask the same questions in the first call and say plainly when a takeover is not needed.
Three questions settle most of the choice: what you hold (documents proving your rights, source code, database), how specific the program is to your business, and how long the system needs to keep running.
| Route | Enough when | Where it struggles | Cost structure |
|---|---|---|---|
| An agreement with the original developer or firm | They can still be reached and are open to handing over the source code, build environment and documentation, or to continuing support. If the system only needs to keep running for a short while, continued support alone may be enough. | It fails if the developer has retired, the firm has closed or the relationship has broken down. Unless someone checks independently that the delivered source is complete and builds, the dependency remains. Receiving the source code does not necessarily mean receiving the rights: put in writing which rights the agreement covers alongside the source code, and have a lawyer confirm the scope. | Depends on what you agree with them: a handover fee or ongoing support charges. Having the completeness of the handover verified independently is a separate item. |
| Takeover: evidence-graded analysis and handover | The program still does the job correctly, its rules have built up over years and are written down nowhere, and the system needs to keep running for some time yet; you can document that you hold the rights to the software or have the rights holder's written permission. | How much of the program's logic can be extracted is known only at the end of the first stage. If neither ownership nor written permission can be documented, this route is closed. | Fixed-scope stages, each priced separately; an optional maintenance agreement afterwards. |
| Rewriting from scratch | The program no longer meets your needs, the technology underneath is no longer supported, or your processes have changed so much that they need redefining; the new system is expected to grow over many years. | A new system written without a full picture of what the old one does may miss some of its work; unwritten rules may only surface at go-live. The old system has to stay up throughout the transition. | A project fee, data migration from the old system, keeping the old system running during the transition, and a maintenance agreement. If the analysis of the old system is skipped, its cost can come back later as change requests. |
| Moving to an off-the-shelf package | What the program does is standard in your industry, you are prepared to adapt your process to the package, and a fast start matters most. | Calculations, reports and approval flows specific to you need customisation when they do not fit; what comes as standard varies by product and version, so ask the vendor. Moving old data into the package is a separate job. | Licence or subscription; for perpetual licences, any annual maintenance and update fee; installation and customisation; plus data migration. These items vary by product and licence model, so check current terms with the vendor. |
On both the takeover and the rewrite route, the source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. Your rights in the original program itself depend on the rights you already hold; our examination does not change them.
Before deciding anything, stop further loss. You do not need us or any other team for these steps, and each one makes every later route easier.
| Step | Why | Watch out for |
|---|---|---|
| Back up the database and check the backup opens | Even if the program breaks, the record of your business lives in the data. | Keep the backup somewhere other than the machine the program runs on, and test that it opens in a separate environment. |
| List all access | If it is unclear who holds the server, database, domain, hosting, email and remote-access accounts, and in whose name, even a small fault cannot be fixed. | Before changing passwords, check whether the program depends on those accounts; otherwise it may stop working. |
| Find the contract and ownership documents | They are the precondition for any work on the source code or the compiled program. | If there are none, clarify the position with a lawyer; we do not give legal advice. |
| Try to reach the original developer in writing | Handing over the source code, build environment and documentation may be the shortest route. | Keep your request and any reply in writing, and list everything that is handed over. |
| Freeze changes and log errors | Every change to an unknown system increases risk. | Ask users to note the screen, date and task when an error appears; these notes are used in the analysis. |
This page is for software written specifically for you. Licences, upgrades and official support for packaged software such as Logo, Netsis or Mikro are handled through that product's authorised partners.
Proof of rights is needed before the first stage starts. None of the other items stops the work on its own, but each one directly affects scope, duration and how much can be established with certainty; any gaps among them we inventory together in the first stage.
| Item | What to look for | Why it matters | If it is missing |
|---|---|---|---|
| Proof of rights | The contract signed when the software was commissioned and any clauses transferring the intellectual property rights; if someone else holds the rights, their written permission. Invoices and correspondence are supporting documents; whether they are enough to establish your rights is for your lawyer to judge. | It is the precondition for examining the compiled program and its database, which is why we ask for it before the first stage. | Work does not start. If no document can be found, you need to clarify the position with a lawyer; we do not give legal advice. |
| Source code and build environment | The latest source code or whatever fragments remain, the development tool and its version, third-party components and their licences, installer files. | Software you cannot change keeps you dependent in practice; a handover is complete only once the project can be compiled and run from scratch. Whether the code you hold matches the version running live is compared separately, and any differences that cannot be resolved are recorded in the report. | We work to extract the business logic from the compiled application; how much can be recovered depends on the language, how it was compiled and whether the code was obfuscated. This takes longer and some information may not be recoverable. If licences or installers for old components cannot be found, their replacement is planned separately. |
| Database backup and schema | A current backup that has been test-restored; tables, stored procedures, functions and views. Server-level settings such as scheduled jobs, logins and linked servers are, in many database systems (SQL Server, for example), not included in that backup and must be exported separately. | Some of a program's rules may live in its database objects. The analysis runs on a copy of this backup, without touching the live system. | Backup and restore are secured first. For objects whose source cannot be found, we attempt to rebuild them from the places they are called and compare their results with existing outputs on a copy of live data; any that cannot be verified are marked as unverified in the report. |
| Server and licence access | Administrator accounts for servers and the database, domain and hosting control panels, operating system and database licences, and any remote access or backup services. | If access sits only with the former developer, stepping in becomes very hard, even for a minor fault. Whether licences can be moved or renewed depends on whose name they are in and on their terms; check with the licence provider. | How access to accounts that belong to you will be recovered, through the provider's official recovery routes, is set out in the first stage. For accounts whose registered owner is unclear, you may need to contact the provider yourself. |
| User and workflow knowledge | The people who use the program every day, which screen is used for which task, end-of-day and month-end steps, known bugs and manual corrections. | A rule read from the code only makes sense once it is matched to how the program is actually used, and users can say which parts are really in use. That way less time goes on parts nobody uses. | The analysis rests on the code alone; unused code and critical flows are told apart late, and priorities may be set in the wrong order. |
If a third-party commercial product's licence prohibits reverse engineering or examination of its compiled code, we do not carry out this work on that product.
If these are ready, we can assess your situation more realistically in the first call and write the scope of the first stage more precisely. Proof of rights is needed before the first stage starts; anything else that is missing we inventory together in the first stage.
First we stop the risk: we inventory what you have (installer files, fragments of source code, database backups, licences, and the documents showing your rights to the software or the rights holder's written permission) and secure backup and restore. The output of this stage is a realistic preliminary assessment of whether the job is genuinely feasible.
The application and the database are analysed line by line; screens, roles, tables and calculation flows are connected to one another. Every finding is labelled with its evidence level; a class or file name alone does not count as evidence, and inferences are grounded in the intersection of multiple independent clues.
We attempt to rebuild database objects and code fragments whose source cannot be found, and compare the result with existing outputs on a copy taken from live data. Areas that cannot be verified are recorded in the report as gaps; they are not presented as closed.
An environment where the project compiles and runs is set up; installation steps, dependencies, configuration and known risks are put in writing. The handover file contains the minimum information someone other than you needs in order to keep this system going.
With the full picture in hand, we put the two options on the table with their numbers: keep the existing system alive, or rewrite it gradually. The decision is yours; the cost, duration and risk of both paths are compared in the same document.
In most cases, yes. If you have the compiled application and the database, most of what the program does can be extracted. But some information lives only in the source and cannot be recovered from the compiled form. That is why the output of the first stage is not a promise but a map showing what could be extracted and what could not.
No — and we recommend treating anyone who does with caution. Committing to an outcome without looking at the material is impossible. Our commitment concerns time and scope: at the end of a fixed period we deliver a report covering what we found, which parts of the system could be rebuilt and which paths are open from there. That report is valuable even if recovery proves impossible, because you then take the rewrite decision knowingly rather than blindly.
It depends on the size of the application, the complexity of the database and the material you have. That is why we structure the work as fixed-duration, fixed-scope packages; at the end of each period you see what came out and decide whether to continue. That way you never face an open-ended consultancy bill.
No. The analysis runs on a copy of the system and a backup of the database; the live environment is touched only with your approval and in pre-agreed maintenance windows. If a failure that stops production occurs during the takeover, priority response is in scope.
We carry out this examination only where you can show that you hold the rights to the software or have written permission from the rights holder; the decisive question is who owns the software. If the program was written for you, on your commission, taking it over usually means working on your own asset; but if the transfer of economic rights is not explicitly written into the contract, the situation can become contested. Before starting work we review your existing contract with you and, where needed, ask you to clarify it with a lawyer. If a third-party commercial product's licence prohibits this kind of analysis, we do not carry it out on that product. We do not build work on top of legal uncertainty.
Four things: an evidence-graded analysis report describing what the program does, the rebuilt database objects, an environment where the project compiles and runs, and the handover file another team needs in order to carry on. The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences.
It is not right to take that decision before the analysis is done. A running system contains a large number of business rules accumulated over the years and written down nowhere; a new program written without seeing them usually ends up more incomplete than the old one. First we extract what is there, then we put the two options side by side in terms of cost and risk.
We listen to what you need and tell you whether custom development or an off-the-shelf product fits better. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We find the cause of systems that lock up at end-of-day close, month-end reports that never open, and screens that stall when a few users log in at once — by measuring. Not with guesswork, but with query plans and profiling data, measuring before and after with the same rig.
Details →We protect your critical business flows with automated tests: written acceptance criteria, end-to-end scenarios, a regression suite and automated pre-release runs. What an update broke should be learnt from the tests, not from a customer.
Details →We run security audits on delivered or inherited applications: authorisation and data access flaws, authentication weaknesses, injection risks, secrets and key management, dependency vulnerabilities. We also work on the side of closing the findings.
Details →We assess your existing software estate independently: an architecture map, a technical debt inventory with prioritisation, dependency and vendor lock-in risk, the team's way of working and a realistic roadmap. It is a piece of work that sets direction without writing code.
Details →We turn a working piece of software written for a single client into a sellable product: separating the core from the client-specific layer, a configuration engine, multi-tenant data isolation, installation and release management, and subscription infrastructure.
Details →We make it visible from one place where demand and supply diverge, which supplier is holding to its promised date and where the goods are waiting right now. The aim is not to install a new ERP; it is to gather the information your current system does not hold and tie the planning decision to data.
Details →
