Your Linux administrator’s handed in their notice. Somewhere between wishing them well and working out who’ll look after the servers, a question tends to surface: how much of this is written down?
Sometimes, quite a lot. Sometimes, the answer involves a notebook, a collection of scripts and the phrase “just give me a ring if anything happens”. A kind offer, but a slightly ambitious support arrangement.
A Linux administrator handover needs to leave your organisation with control of its systems, a clear picture of how they work and someone responsible for looking after them. Passwords matter. So do the things those passwords won’t tell you.
Start with what the business needs to keep working
Before getting lost in server names, write down what the systems actually do. Which ones handle orders, run an application, hold research data or support customers? Who notices if they stop? Are there particular times when an interruption would be especially disruptive?
Then add the technical detail you have: where each system lives, its Linux distribution and version, and what else it depends on. An application might need a separate database, shared storage or a data feed that arrives overnight. The server can be perfectly healthy while the service people need is unavailable.
You don’t need to know all the terminology to make a useful start. “This is where tomorrow’s orders come from” tells an incoming engineer that it’s important.
Make sure the keys belong to the organisation
Being able to log in today isn’t quite the same as knowing you’ll be able to log in after someone leaves.
Check administrative accounts and SSH keys, but look beyond the servers too. You’ll need the appropriate hosting or cloud accounts, server console access, domain and certificate accounts, and access to your backups. Recovery details and multi-factor authentication need attention, especially if they’re tied to someone’s personal email address or phone.
Arrange an authorised transfer to accounts the organisation controls, and test access before the handover ends. Coordinate the removal of old access and changes to shared credentials so you don’t lock out the people taking over.
Keep credentials out of ordinary emails and contact forms. If we were taking over management, we’d agree a secure way to arrange it.
“We’ve got backups” deserves a follow-up question
What, exactly, is backed up? Where are the copies? Who can restore them? And when did anyone last check that they could?
Configuration backups and business data backups serve different purposes. Having a record of how a server’s configured doesn’t mean you’ve also got the files, databases and application data it holds.
For example, Tiger’s ongoing Linux support includes configuration backups. Data backups need a separate arrangement. Whoever’s taking over should understand what’s covered, what’s missing and what recovery would involve.
If you’re changing backup providers as part of the handover, keep the existing arrangement in place until you’ve agreed and checked its replacement. Discovering a gap during a restore is an experience best avoided.
Ask about the jobs that quietly happen in the background
The obvious systems usually make it onto the handover list. The small, recurring jobs are easier to miss.
Ask the departing administrator to talk through what happens overnight, at month end and when something needs renewing. Which alerts need action? Which certificates expire soon? What’s waiting for a fix? Is there a script that occasionally needs a nudge, and does anyone else know why?
Capture the answers where the next person can find them. Include current problems, work in progress, supplier contacts and the location of existing documentation. A conversation with the incoming engineer can uncover details that a blank handover template won’t.
This isn’t an exercise in producing a beautiful document. It’s about giving someone enough context to make sensible decisions when you’re relying on them.
Decide who’s looking after what
If your developers will keep managing the application and a specialist partner will manage Linux, agree that split explicitly. Each part needs an owner, and both teams need a way to investigate problems together.
Be equally clear about the transition. Who’s monitoring the systems while access and management tools are being set up? Who should people call if something goes wrong? What support hours have you agreed?
A date in a diary doesn’t, by itself, make a handover complete. The people taking over need access, context and an agreed scope of responsibility.
If the administrator’s already left, start with the information and authorised access your organisation holds. Your hosting provider or server console may offer a recovery route, but that needs assessing. Resist the temptation to make speculative changes to a critical system while you’re still finding out what it does.
You don’t have to untangle it all before talking to us
We can help you work out what’s needed before or after your Linux administrator leaves. Tell us what the systems do, who’s relying on them and what your deadline looks like. If documentation’s thin, say so. You don’t need to turn yourself into a Linux expert before making the call.
For ongoing support of systems we didn’t build, we use a chargeable Pre-Contract Check to assess the environment and identify essential work. We’ll agree the scope, access and next steps with you. The time needed depends on what we’re taking on; we’ll discuss your situation rather than assume every handover fits the same timetable.
You can also read our Linux support FAQs for more about joining Tiger and how support works.
Whether you need to talk through the business impact or get into the configuration detail, we’re comfortable with either conversation. Talk to us about your Linux handover, and we’ll help you work out a sensible way forward.
