Taking over an inherited codebase: the first 30 days, week by week
A practical plan for the first month after inheriting a codebase: secure access, make it build, map production, add a safety net, then change things.
The previous developer has left, or the agency contract has ended, and the application is now yours. It runs, mostly. Nobody is quite sure how it is deployed, which server the cron jobs live on, or what happens if you upgrade a dependency. The temptation is to start fixing things straight away. In our experience the first month goes better if you spend it learning and protecting the system instead.
The short answer: in the first 30 days with an inherited codebase, secure access and ownership, get the code building from scratch, map what actually runs in production, put a safety net of backups, monitoring and a few tests in place, then ship small, low-risk changes. Only after that should you decide what to refactor, upgrade or rewrite.
This is the plan we follow when we take over an application from another team. It works for a single developer joining a company as much as for an outside team.
Days 1 to 3: secure access and ownership
Before reading a line of code, find out who controls what. Handovers often fail here: the code is transferred, but the domain is registered to a former employee, or the cloud account is billed to the old agency's card. Make a list and get every item into an account the organisation owns, with at least two people able to log in.
- Source code repositories, including any forks or private packages the build depends on.
- Domain registrar and DNS provider.
- Cloud accounts, VPS providers and their billing details.
- Server SSH access, and who else still has keys on those servers.
- Third-party services: email sending, payments, SMS, maps, error tracking, app store accounts.
- Secrets: database passwords, API keys, signing keys, and where each one is stored.
- Any CI/CD system and the credentials it holds.
Then rotate credentials that departing people knew. Do it carefully and one at a time, because rotating a key that something undocumented depends on is a classic way to cause an outage in week one. Check ~/.ssh/authorized_keys for every user on every server and remove keys nobody can account for, after confirming no automated job uses them.
Week 1: make it build from a clean machine
Clone the repository onto a fresh machine or container and try to build and run it using only what is written down. Every step you have to guess is a gap in the documentation, so write it into the README as you go. Pin the exact runtime versions you find working, for example in an .nvmrc, a .python-version file or a Dockerfile, so the next person does not repeat the hunt.
While you are in the repository, look for secrets that were committed. They stay in git history even after the file is deleted, so scan the whole history rather than the current tree:
# Scan full git history for committed secrets (gitleaks v8.19+)
gitleaks git --redact -v .
# Dependencies with known vulnerabilities
npm audit --omit=dev # Node projects
pip-audit # Python projects
# How far behind the dependencies are
npm outdated
pip list --outdated
Anything gitleaks finds should be treated as leaked: rotate it, then decide whether rewriting history is worth the disruption. Usually rotation is the part that matters.
Also check the runtime and framework versions against their end-of-life dates. In 2026 we regularly find applications on Node.js 18 or 20, both now past end of life, Python 3.8 or 3.9, or Django 4.2, whose long-term support ended in April 2026. The endoflife.date site is a quick way to check each component. An unsupported runtime is not an emergency on day one, but it belongs near the top of the risk list.
Week 1 to 2: map what actually runs in production
The repository tells you what the code says. Production tells you what is really happening, and the two often differ. Log in to each server and record what is running, what is scheduled and what is listening on the network.
# Long-running services and scheduled timers
systemctl list-units --type=service --state=running
systemctl list-timers --all
# Cron jobs for every user, plus system cron directories
for u in $(cut -d: -f1 /etc/passwd); do
sudo crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"
done
ls /etc/cron.d /etc/cron.daily /etc/cron.weekly
# Containers and listening ports
docker ps --format '{{.Names}}\t{{.Image}}\t{{.Status}}'
sudo ss -tlnp
# Web server sites and where they proxy to
sudo nginx -T | grep -E 'server_name|proxy_pass|root '
From this, draw a simple diagram: which domains point to which servers, which processes serve them, which databases they talk to and which external services they call. A single page that shows the request path and the data stores is worth more than a long document nobody updates.
Pay special attention to anything that exists only on the server: config files edited in place, scripts in a home directory, a cron job that emails a report every Monday. These are the things that vanish when a server is rebuilt. Copy them into version control, even if you do not yet understand them.
Finally, find out how a deployment happens today. Is it a CI pipeline, a script someone runs, or a git pull over SSH? Do one deployment of an unchanged build yourself, with the previous owner if they are still reachable, so you know the process works before you need it in a hurry.
Week 2: build a safety net before changing anything
You cannot safely change a system you cannot restore or observe. Three things come first.
- Backups you have restored. Confirm what is backed up, where copies go and when the last one ran. Then restore the latest backup into a scratch environment and check the data looks right. Inherited backups fail more often than you would expect.
- Basic monitoring. At minimum an external uptime check on the main URLs, disk space and certificate expiry alerts, and error tracking in the application. Know who gets the alert.
- Characterisation tests. If there are few or no tests, write a handful that record what the system does now, not what it should do. Hit the main API endpoints or pages and assert on status codes and key fields. They will tell you when a change alters behaviour, which is what you need before refactoring.
Characterisation tests do not need to be elegant. A short script that logs in, loads the five most used screens and checks a known record is a good start. Run it before and after every deployment.
Weeks 3 to 4: talk to people and ship small changes
The code will not tell you which parts the business depends on. Spend time with the people who use the system and the people who support it. Ask what breaks, what they work around, what is slow and which features nobody uses. Support tickets, error logs and the git history all help.
# Files changed most often in the last year: likely hotspots
git log --since='12 months ago' --format=format: --name-only \
| grep -v '^
{{ pageBg }}
Infigini IT Services · Dehradun, India
Software, cloud and AI systems, built to last.
Infigini designs, builds and operates custom software for universities, healthcare providers and enterprises. Our work ranges from ERP platforms and AI knowledge assistants to the cloud infrastructure they run on.
{{ marquee }}
Services
Nine disciplines, one engineering team.
The same team handles architecture, build and production, so nothing is lost passing work between departments.
Our products
We also build products of our own.
Two proprietary platforms we own and operate, plus open-source libraries published on GitHub and npm. The patterns we recommend to clients come from running them.
Engineering stack
The technologies we use, organised by layer.
About Infigini
IT systems that organisations depend on every day.
Infigini IT Services builds software that simplifies infrastructure management and supports new ideas. We work with developers and organisations to build, deploy and scale their systems, with a focus on security, scalability and ease of use.
Our work covers campus ERPs used by thousands of students, AI assistants on Azure, appointment systems for clinics and hospitals, and the cloud servers they run on. We look after these systems from the first requirement through years of production.
Mission
To give organisations scalable IT systems that simplify infrastructure management, so that businesses of any size can work more efficiently and grow faster.
Vision
To become a global provider of next-generation IT solutions that integrate advanced technology into everyday operations.
Our values
{{ v.n }}
{{ v.t }}
{{ v.d }}
Industries
The sectors we work in.
Services
Services built around your operations.
One engineering team covers architecture, build and production operations. Choose a single discipline, or bring us in for the whole system.
Specialised services
Looking for something specific?
← All services
Service {{ svc.n }}
{{ svc.title }}
{{ svc.long }}
What's included
—{{ it }}
Loading…
Sound familiar?
{{ land.problemsTitle }}
What's included
{{ land.includesTitle }}
{{ x.n }}
{{ x.t }}
{{ x.d }}
Ways to work with us
{{ land.plansTitle }}
How it works
{{ land.stepsTitle }}
{{ st.n }}
{{ st.t }}
{{ st.d }}
Why Infigini
{{ land.whyTitle }}
Technologies we use
{{ t }}
FAQ
Questions we get asked.
Industries
Industries we build for.
Most of our work is for organisations whose systems carry real operational weight: campuses with thousands of students, clinics booking patients all day, and enterprises whose HR and finance processes cannot stop. These pages cover what we build for each sector.
Projects · {{ projectCount }}
Our work, from 2020 to today.
This list covers our platforms, client systems and open-source libraries. Client names are withheld at their request.
← All projects
{{ proj.cat }} · {{ proj.year }}
{{ proj.title }}
{{ proj.summary }}
Client{{ proj.client }}
Year{{ proj.year }}
Category{{ proj.cat }}
Visit live ↗
Products
Platforms we run. Libraries we publish.
TechLogHub and EasySiteControl are proprietary platforms that Infigini owns and operates. Our open-source libraries are on GitHub and npm for anyone to use, and we use them in client projects too.
Proprietary platforms
Proprietary · Live{{ p.year }}
{{ p.title }}
{{ p.summary }}
{{ p.stackLine }}
Open-source libraries · GitHub & npm
{{ l.title }}
{{ l.year }} · {{ l.stackLine }}
{{ l.body }}
How we work
Five stages, from first conversation to production.
Each stage ends with a deliverable you keep. You get software you can use every two weeks, so nothing important arrives as a surprise at the end.
{{ s.n }}
{{ s.t }}
{{ s.d }}
You receive{{ s.out }}
Journal · {{ postCount }} articles
Notes from the engineering team.
Practical write-ups on cloud and DevOps, AI systems, ERP platforms and the frontend and backend work behind them, plus guides for teams planning a software project.
← Journal
{{ post.cat }} · · {{ post.read }} read
{{ post.title }}
{{ post.dek }}
{{ post.byline }}
Loading article…
{{ b.x }}
{{ b.x }}
{{ b.x }}
FAQ
Common questions.
These cover scope, timelines, ownership and what happens after launch. If your question isn't here, write to us.
{{ f.a }}
Contact
Tell us what you are building.
A few sentences are enough to start. We reply within one business day.
Office11 Kanwali Road, Dehradun,
Uttarakhand 248001, India
What happens next
{{ s.n }}{{ s.t }}{{ s.d }}
Thank you. We have your message.
An engineer will reply within one business day.
Legal
{{ legalTitle }}
Last updated 1 October 2026
