What happens when nobody maintains your business website?
A website can keep returning a 200 response long after parts of it have quietly stopped working. Maintenance is the work that notices.
3 min read
Managed Services / Nov 2026
What to check before taking over an existing website
A takeover is a transfer of responsibility, not a change of name in the footer. The difficult work is finding out what you have inherited.
A takeover is a transfer of responsibility, not a change of name in the footer. The difficult work is finding out what you have inherited.
Taking over an existing website is often more useful than rebuilding it. The site may be doing its job, the content may be established and a replacement may introduce risk without solving a real problem. But responsibility cannot be accepted responsibly until the environment is understood.
A takeover review is not a full security audit or a code review of every line. It is a practical assessment of what exists, what depends on it and what would be needed to support it.
Access and ownership
Start with the accounts. Who controls the domain, DNS, hosting, database, email and any third-party services? Are the credentials held by the business, an agency or a former developer? Is there a recovery route if a personal email address is the only way to reset an administrator account?
- Domain registrar, DNS provider and renewal dates.
- Hosting account, control panel and server access.
- Application administrator accounts and database credentials.
- Third-party services: email, payments, analytics, APIs and licenses.
- Ownership of the code and any relevant licences.
The code and its dependencies
Establish what the site is built with, which versions it runs and whether those versions are still supported. Look for custom code, abandoned plugins, copied libraries and modifications that are not recorded anywhere. A site that works today can still be unsupportable if its runtime is about to be removed by the host.
Hosting, DNS and email
Hosting is part of the application, not a separate utility. The web server, PHP version, database, disk capacity, scheduled tasks and email configuration all affect what the site can do. DNS changes can break email or send traffic somewhere unexpected if the records are not understood.
Backups and recovery
A backup schedule is not the same as a recovery capability. Check what is included, how long copies are retained, where they are stored, who can access them and whether a restore has ever been attempted. For a database-driven site, files and database need to be consistent with each other.
Security and change history
Review the visible security posture: supported software versions, administrator access, file permissions, exposed configuration and the presence of unexplained files. A change history is useful too. If nobody can say what was deployed and when, the first incident will be harder to diagnose.
What is actually running
Finally, compare the documentation with reality. A site may have staging environments, cron jobs, integrations or scheduled exports that nobody mentions. The handover should end with a written baseline: what runs, where it runs, who has access, what is monitored and what remains unknown.
- A written inventory of systems, accounts and dependencies.
- A known-good backup and a tested restore route.
- A deployment process that can be repeated.
- A monitoring and alerting baseline.
- A clear boundary of what the takeover does and does not cover.
A takeover is successful when the new owner can explain the system, not merely log in to it.