When your only system administrator (sysadmin) leaves, secure access first, get a written audit of the environment second, and choose who runs it third. The four realistic choices are a replacement hire, a contractor, a managed operations provider that runs the environment in place, or a migration to something simpler. In most cases, new people can still operate or migrate an undocumented environment, as long as the company can recover administrative access.
A sysadmin is the person who builds and runs servers, cloud accounts, backups and monitoring. Key-person risk is the exposure a company carries when one person holds knowledge or access that nobody else has. A runbook is a written procedure for a known failure or a routine task. This article is for an executive or engineering manager who now owns a production environment and did not build it.
What should you do in the first week after your only sysadmin leaves?
The first week after a sysadmin leaves is about control and safety, and none of it requires understanding how the environment works. Three decisions come first, in this order.
- Confirm that the company controls every account. List the domain registrar, the Domain Name System (DNS) provider, the hosting or cloud account, server logins, backups and monitoring. Every account should belong to a company identity, with at least two current people able to sign in. Rotate the credentials the departed person held as ordinary offboarding, whatever the terms of the departure.
- Pause non-essential changes. Hold upgrades, clean-ups and cost cuts until someone has a written picture of what depends on what. An urgent security fix is the exception, and it should be applied by someone who can also roll it back.
- Name who answers production alerts. Decide who is reachable if the site or application fails tonight, and what that person is allowed to do.
If the sysadmin is still working out a notice period, spend that time on handover: a recorded walkthrough, a list of every account and scheduled job, and the known fragile parts. For the third decision, the knowledge base explains how to set up on-call for a team that has never had one.
Why should you get a written audit before anyone changes the environment?
A written audit comes before any change because an undocumented environment hides dependencies that only show themselves when something is moved or removed. An audit here means a written read of what is running, where it runs, what depends on what, and where the risk sits. It is a document, and producing it should change nothing in production.
A useful audit of an inherited environment answers these questions:
- What servers, services, databases and scheduled jobs exist, and what does each one do?
- Who and what has access, and which of those accounts are no longer needed?
- Do backups exist, where are they stored, and has a restore ever been tested?
- How far behind are operating system and software patches?
- What is monitored, who receives the alerts, and which alerts are noise?
- Which risks come first, and is the recommendation to document, stabilize or migrate?
Small undocumented details matter. In one example scenario, a ten-year-old web application moved to a managed platform, and an undocumented override in a server file caused a hiccup during cutover, the moment traffic switches to the new environment.
For technical depth, the knowledge base covers detecting configuration drift, meaning changes made to production that nobody declared, and a takeover audit of a cPanel server. cPanel is a common hosting control panel.
Who can take over your servers after a sysadmin leaves? Four options compared
Four kinds of successor can run an inherited environment, and they differ on coverage, continuity and the risk each one leaves behind.
| Option | What it gives you | Choose it when | Avoid it when | Main risk |
|---|---|---|---|---|
| Replacement hire | Product context and daytime ownership | The role was a full-time job of steady work | You expect one person to cover every night | The same key-person dependency, rebuilt |
| Contractor or freelancer | Fast, bounded expertise | The job is an audit, documentation or one defined repair | You need ongoing coverage or continuity | Knowledge leaves again when the contract ends |
| Managed operations provider, in place | A team, a written scope and a defined coverage window | The gap is coverage, continuity and routine, and the architecture is sound | The footprint is tiny, or the real problem is application defects | A scope that stops short of what you assumed |
| Migration to something simpler | A documented environment on a supported platform | The current setup is fragile, unsupported or far more complex than the workload needs | Nobody has audited the environment yet | Surprises on cutover day |
The four options combine, for example a written audit followed by interim coverage while you recruit.
When should you hire a replacement sysadmin?
Hire a replacement sysadmin when the departed person was doing a full-time job of steady infrastructure work, or when the infrastructure is the product you sell. A colleague learns the application in a way an outside party rarely does.
Two conditions make the hire work the second time. Documentation is part of the job description. After-hours coverage is decided separately, because one person cannot carry production alerts every night and through every vacation.
Recruiting takes time, and interim coverage from a contractor or a provider can bridge the vacancy. A contractor also fits a bounded job such as the audit itself, but a single freelancer is another single person, so the deliverables should be documents the company owns. If a competent successor is already hired, a one-off audit and documentation project may be all the outside help you need. The article on whether to hire a DevOps engineer or outsource operations compares the two paths on coverage, continuity and cost. DevOps is short for development and operations.
When should a managed operations provider run the environment in place?
A managed operations provider fits when the gap is coverage, continuity and operational routine, and the work does not fill a full-time role. Managed operations means a provider runs the infrastructure layer under a written scope: monitoring, patching, backups and incident response. The contract that states the provider’s commitments is a service level agreement (SLA).
Running the environment in place means the provider operates it where it is today. Your hosting or cloud account stays yours, and no migration is needed to start. Ask any provider to confirm these terms:
- The engagement starts with an audit, and nothing changes in production before the audit is delivered.
- The provider works through access that you grant and can revoke, never through the departed person’s old credentials.
- The scope names the coverage window: business hours, extended hours or 24/7.
- Runbooks and an architecture diagram are deliverables that you keep if the contract ends.
- The scope says where it stops. Defects in your application code normally stay with your developers.
On Amazon Web Services (AWS), a provider can operate an existing AWS account through a dedicated access role, with root credentials kept by the company. The article on who can manage AWS infrastructure for your company describes that handover, and the knowledge base lists the signs that an AWS environment has outgrown its team.
A managed operations provider is the wrong choice in three situations:
- The whole footprint is one server and a storage bucket, so a contract is overhead.
- Two or more engineers still own operations and do it well, so the fix is documentation.
- Most incidents come from application defects, which need engineering time and not a new operator.
When is migrating to something simpler the right decision?
Migrating is the right decision when the audit shows that the current setup is the problem. Typical reasons are software that no longer receives security updates, a single server with no recovery path, or a design far more complex than the workload needs.
Migration is a poor first move. Moving an environment nobody understands carries the unknowns into cutover day, when traffic switches to the new environment. The audit comes first, and it sometimes concludes that no move is needed.
In one example scenario, a legal-technology software company of about 35 people depended on a lone sysadmin and one developer for its production knowledge, and nothing was written down. The audit found the architecture “fine for the workload” and proposed no rebuild. The company stayed on AWS, and ten runbooks were written in the first four weeks of that engagement.
What drives the cost of each option?
The four options have different cost drivers, so compare them over the same period and for the same hours of coverage.
- Replacement hire. Salary and benefits, recruiting effort, the ramp-up period in an undocumented environment, tooling, and the cost of the vacancy while the role is empty.
- Contractor. Contract work is usually billed by time. Discovery in an undocumented environment is hard to estimate, so ask for a fixed price for the audit and a separate quote for any repair.
- Managed operations provider. The number and class of environments, architecture complexity, the coverage window, the response targets in the SLA, the number of monitored assets, and any stabilization work the audit identifies.
- Migration. The number of sites or workloads, data size, dependency complexity, tolerance for downtime at cutover, data-residency needs, and the length of the support window after launch.
The cost of waiting can be measured too. List the tasks only the departed person could perform, then estimate what one day of downtime costs in lost orders, contract penalties and staff time. The article on how managed cloud hosting is priced explains the common pricing structures.
How do you reduce key-person risk in production infrastructure?
Key-person risk in production infrastructure falls when knowledge and access are shared and written down, whoever runs the environment. Five controls do most of the work:
- Every account belongs to the company, and at least two people or parties hold working access.
- A current architecture diagram shows what runs where and what depends on what.
- Runbooks exist for the common failures and the routine tasks, and they are updated after each incident.
- Restores are tested on a schedule, and the result is recorded.
- Documentation is a named deliverable in the job description or the provider contract.
The knowledge base shows how to write a runbook entry for a recurring alert.
What should you decide in the first 30 days? A checklist
Answer these seven questions in writing during the first 30 days after the departure.
- Does the company control every account, and have the departed person’s credentials been rotated?
- Who answers a production alert tonight, and what may that person do?
- Who will write the audit, and by what date?
- Has a backup been restored successfully since the departure?
- Was the role a full-time job of steady work, or a few hours a week plus emergencies?
- When are your customers active, and which hours need coverage?
- Whoever runs the environment next, which documents will the company own at the end?
Steady full-time work points to a replacement hire with documentation in the job description. Thin coverage and a sound architecture point to a provider operating the environment in place. A fragile or unsupported platform points to a planned migration after the audit.
Where Stack Harbor fits
Stack Harbor is a Canadian managed cloud operations provider (MSP) for production environments, headquartered in Montréal. It serves small and mid-sized businesses and agencies of roughly 5 to 200 people that run production systems without a 24/7 operations team of their own. Its clients include software-as-a-service (SaaS) companies, agencies and publishers.
Stack Harbor’s solutions page states that “Most engagements are takeovers”, and the first phase is an assessment of what is running and where the risk sits. Stack Harbor writes that assessment as part of the initial consult, and its site says: “You get the assessment whether you engage us or not.”
Ongoing operations are sold as Managed Cloud Ops, which runs in four phases: audit, stabilize, operate and improve. Stack Harbor operates environments on AWS, Azure, Google Cloud, OVH, DigitalOcean, dedicated servers and cPanel/WHM. It also operates its own Canadian infrastructure in two data centres in Montréal. It does not require a migration. What it can do depends on the access you grant, network reachability and the condition of the environment.
For an existing AWS account, the AWS operations offer works through a dedicated role in AWS Identity and Access Management (IAM), and the root account stays with the client. When the audit points to a move, Migration Services starts with discovery, a small paid scoping engagement that produces a written migration plan and a fixed-fee quote. Asked whether it can migrate hosting after the person who set it up has gone, the migration page answers: “That is the most common starting point.”
Coverage under the Management, Monitoring & Support service is scoped as business hours, extended hours or 24/7. A trained on-call rotation works to runbooks designed by senior engineers, and senior engineers own Severity 1 incidents, meaning production is down.
Every engagement ships with a written runbook and an architecture diagram, which are deliverables that you keep. Stack Harbor does not publish prices. It delivers a fixed scope and quote after the assessment, as the page on how Stack Harbor scopes and prices explains. That page also lists the cases where a retainer is the wrong purchase.
