Many companies depend on software that nobody currently looks after: an internal portal built years ago, a web application from a vendor that stopped responding, a mobile app whose developer moved on. The software still runs — until something changes. Taking it over properly starts not with new features, but with an honest assessment.
1. Secure access to everything first
Before anyone reads a line of code, make sure the company actually controls its own software. Collect and verify:
- Source code — the full repository, including history, not just a zip of the latest version.
- Hosting and servers — cloud accounts, server logins, control panels.
- Domains and certificates — who owns the domain and when certificates expire.
- Third-party accounts — email services, payment providers, app store accounts, API keys.
- Databases and backups — where they are and whether a backup can actually be restored.
Accounts registered in a former developer's personal name are a common and serious risk. Move them into the company's name as early as possible.
2. Review the code
A code review at this stage is not about style. It answers practical questions:
- Can the project be built and run locally from the repository alone?
- Is the structure understandable, or is logic scattered and duplicated?
- Are there automated tests, and do they pass?
- Are passwords or keys hard-coded in the source?
- Which parts are critical to the business, and which are rarely used?
3. Check dependencies and versions
Every project relies on frameworks, libraries and a runtime environment. Over time these age. List them and note:
- which versions are no longer supported or receive no security updates,
- which libraries are abandoned by their authors,
- how far the project is from current versions, and how big the upgrade steps are.
Outdated dependencies are not an emergency by themselves, but they determine how much effort every future change will cost.
4. Look at security
- Known vulnerabilities in the dependencies you just listed.
- How users log in, and how passwords are stored.
- Who has administrator access, including accounts of people who have left.
- Whether traffic is encrypted and servers are patched.
- Where personal data is stored and who can reach it.
Fix the urgent findings first — removing old access, rotating exposed keys, patching critical vulnerabilities — before planning anything else.
5. Understand deployment
Ask a simple question: how does a change get from the code to production? In inherited projects the answer is often "someone copied files to the server manually". Document the current process, then move towards a repeatable one — ideally an automated CI/CD pipeline, infrastructure described as code and basic monitoring, so you know when something breaks before users tell you.
6. Gather and write documentation
Existing documentation is often thin or out of date. Collect what exists, then write down what you learn during the assessment: architecture overview, how to run the project, how to deploy it, external services it depends on and known issues. This alone makes the software far less dependent on any single person.
Modernise or rewrite?
After the assessment comes the big question. A full rewrite is tempting, but it is expensive and risky: the old system encodes many small business rules nobody remembers, and a rewrite has to rediscover all of them. In most cases, gradual modernisation is the safer path:
- Modernise when the core works, the business logic is sound and the problems are mainly outdated versions, missing tests or manual deployment.
- Replace parts when specific modules are the source of most problems — rebuild those while the rest keeps running.
- Rewrite only when the technology is truly obsolete, the structure blocks every change, or the business needs have changed fundamentally.
In short
- Secure code, hosting, domains and accounts in the company's name
- Review the code and check it builds and runs
- List dependencies and their support status
- Fix urgent security issues first
- Make deployment repeatable and add monitoring
- Document as you go, then choose modernise, replace or rewrite
How int32 can help
We take over and modernise existing software — assessing the code, securing access, setting up deployment and monitoring, and then maintaining it by agreement. Read more about business software, cloud & DevOps and maintenance & support, or get in touch and tell us what you've inherited.