Taking Over a Legacy System With No Documentation
Contents7
Key takeaways
- The original developer is gone, there is no documentation, the expert has left: the system can still be taken over.
- The source code on your server is the most accurate documentation there is. Reading it tells us how the system works.
- Even before you choose a new maintainer, there are things you can check today.
- Left alone, a system like this cannot be patched against vulnerabilities such as October 2026's PHP2shell.
"We can't reach the company that built it." "There is no documentation." "The one person who understood the system has left." Even then, a legacy system can be taken over and maintained.
The source code on your server is the most accurate documentation there is. By reading it we can rebuild a picture of every screen, every calculation and every business rule. This article covers what to check today and how a handover works, whether the original developer has vanished or you simply want to change maintenance provider.
Does this sound familiar?
The developer is unreachable
They closed down, left the business, or the person in charge is gone.
No documentation
There never was any, or it no longer matches how the system behaves.
The expert has left
The one person who knew the system quit, and it became a black box.
Unhappy with your maintainer
Slow, expensive, or leaving the system on old PHP with no upgrade plan.
None of this is unusual. The older a system is, the more likely it ends up here.
The risks of leaving it alone
- Security holes stay open: with no one able to fix the system, new vulnerabilities go unpatched.
- Outages no one can fix: when an error stops your work, no one can find the cause.
- Rules change, the system doesn't: tax rates, laws or partners' systems change and you cannot follow.
- Contracts lapse: if no one knows who holds the server and domain contracts, a renewal can be missed and the site goes dark.
What happened in October 2026
"Security holes" are not hypothetical. In October 2026 a critical PHP vulnerability, "PHP2shell", was disclosed.
PHP releases fixes
Two vulnerabilities that let an attacker run code without logging in are closed.
Japanese security alerts
IPA and JPCERT/CC urge everyone running PHP to update.
Confirmed exploitation
The US agency CISA adds both to its catalogue of known exploited vulnerabilities.
A system with someone to look after it gets the fix right away. A system without one stays exposed. See what to do about PHP2shell.
Nobody looking after it
- Fixes for new vulnerabilities can't be applied
- After an outage, there's no way to know when it will be back
- Years pass with no one who understands it
Taken over and maintained
- Vulnerabilities are patched promptly
- Outages are investigated and fixed
- Documentation exists, so the next person is never stuck
Checklist for today
Even before you pick a new maintainer, checking these will make the handover much smoother.
- Find out who can get in
Who holds the server and domain contracts, and who can log in to their control panels.
- Protect the data
Check that a backup exists, and how recent it is.
- Gather the clues
List the users, leftover documents, connected services and old contracts.
| Check | Why it matters | Urgency |
|---|---|---|
| Who holds the server and domain, and who can log in | With access, the code and data can be examined | Top priority |
| Whether a data backup exists | Your lifeline if something goes wrong | Top priority |
| Who uses which features, for what | Shows which parts matter most to the business | Soon |
| Leftover documents (quotes, invoices, emails, notes) | Often reveal what the system was built to do | Soon |
| Connected services (payments, email, accounting) | Must keep working during the handover | Soon |
| Old development and maintenance contracts | May cover source code ownership and how the contract ends | Before handover |
Share passwords safely
Never put passwords in an email. Share them only with someone you trust, through a secure channel.
How we take over a system with no documentation
Even without documents, the program itself is still on the server. We read it, run it to confirm what it does, and turn what we learn into clear documentation.
At Digi Dinos, a handover with no documentation and no original vendor follows these steps:
- Discovery
How you use the system day to day, and what is going wrong.
- Assessment
Server, PHP and framework versions, database and integrations.
- Code analysis
We read the code ourselves and run it in a test environment to recover the business rules.
- Documentation
Lists of screens and features, data fields and the server setup, written up clearly.
- Risk report and plan
What must be fixed now, what can wait and rough costs, with options: keep maintaining, fix parts, or rebuild.
- Ongoing maintenance
Security fixes, incident response and small improvements.
The documents we rebuild
| Document | What it tells you | When it helps |
|---|---|---|
| Screen list | Which screens exist and who uses them | Deciding the scope of a change |
| Feature list | The calculations and rules the system follows | Changing code without breaking what matters |
| Data fields | What information is stored, and where | Backups and data migration |
| Server setup | Servers, PHP and framework versions, integrations | Planning security fixes and upgrades |
The real goal of a handover
Documentation that lets anyone take over next. You should never again depend on a single company or person just to keep the system running.
Changing maintenance provider: the steps
- Check your current contract
Its term, and how much notice you must give.
- Talk to the new provider
They assess the system and plan the handover.
- Ask the current provider to hand over
Source code, server details and any documents.
- Overlap for a while
Both providers stay involved until everything is confirmed working.
- Switch to the new provider
From here, the new provider is responsible.
If the current provider can't be reached
Skip steps 3 and 4 and start from the code on the server. Access to the server's control panel is the most important starting point.
FAQ
Can we hand over without telling the original developer?
It depends on your contract, which may say who owns the source code and copyright. Check it first, and ask us if you are unsure.
Is our system too old?
No. We work with PHP 5 and with custom code that uses no framework. The older the system, the sooner it is worth having someone look inside.
Is our system too small?
No. An internal tool used by a few people, or just a contact form, is fine.
Can we communicate in Japanese?
Yes. Our Japanese-speaking team handles the work, and we also work in English and Vietnamese.
Can you upgrade it afterwards?
Yes. Based on the assessment we can plan PHP, framework and server upgrades together. See PHP upgrade cost and process.
Hand your legacy system to Digi Dinos
Digi Dinos is a software company with offices in Vietnam and Japan (Yokohama), with eight years of experience and more than 150 projects.
We investigate it ourselves
No documents, no original vendor, no one who understands it: we rebuild the specifications.
Vulnerability patching
Newly published CVEs handled quickly.
Full upgrades
PHP, Laravel, CakePHP or custom code, servers and operating systems.
Permanent warranty
For as long as your maintenance contract continues.
Besides PHP, we take over legacy systems in Java, Node.js and other languages.
Legacy system takeover
A system no one understands any more? Talk to us
If you can still log in to the server, we can start from there. We'll sort out where you stand, together.
Sources
- IPA security alert on PHP2shell, in Japanese
- JPCERT/CC alert, in Japanese
- CISA Known Exploited Vulnerabilities Catalog
Information as of 28 October 2026.
Related articles
PHP Vulnerability CVE-2026-109618 (PHP2shell): What to Do Now
PHP Upgrade Cost: Moving From PHP 5 or 7 to PHP 8
Node.js Security Release, October 2026: What to Do
Java Vulnerabilities, October 2026: IPA Alert and Licence Changes
Securing Legacy Systems: Where to Start (2026 EOL Guide)
Superior Features of ChatGPT 4o (4 Omni)
What Is Digital Transformation? Definition, Roadmap and Examples
The Secret to Happiness!
What Is an IT Comtor? Role, Skills and How It Differs from a BrSE
