Your only IT person just quit. Here's the calm version of what to do

Your only IT person just resigned and you're staring at systems nobody else understands. Here's the calm, practical order of operations to follow now.

Your only IT person just quit. Here's the calm version of what to do

Maybe the resignation landed this morning. Maybe they gave two weeks, maybe they gave two days. Either way, the person who knew how everything worked is leaving, and you’re realizing how much lived only in their head. The passwords. The vendor contacts. The reason that one server can’t be rebooted on a Tuesday. It’s a genuinely stressful spot to be in, so the first thing worth saying is that this is recoverable, and you have more time than the panic is telling you.

The goal for the next couple of weeks is simple. Capture what you can while the knowledge is still in the building, protect yourself against the few things that can actually hurt you, and keep the lights on. You don’t have to solve everything at once. You just have to handle things in the right order.

First, keep it human

Before anything technical, take a breath about the relationship. However the departure is happening, the smoothest transitions are the ones where the person leaving still wants to help. A defensive, rushed exit interview makes people hold back. A calm one where you genuinely thank them tends to surface far more useful information.

If they are willing, ask for time to walk through how things are set up rather than just a password list. The story behind a system, why it was built a certain way, what tends to break, is often worth more than the credentials themselves. People remember more when they are talking through it than when they are filling out a form.

Capture access before the last day

The single most important thing to lock down is access, because that is the hardest piece to recover once someone is gone. While your departing person is still reachable, work through these:

  • The password vault or manager. If everything lives in one place, get the master access and confirm someone else can open it. If passwords are scattered across sticky notes and browsers, ask for a written list now.
  • Domain and email administration. Who controls your Microsoft 365 or Google Workspace? You want to confirm there is an administrator account you control, not just one tied to the person leaving.
  • Your domain name registrar. The account where your website domain is registered is easy to forget and painful to recover. Make sure you can log in.
  • Critical vendor logins. Your internet provider, your phone system, your line-of-business software, your backup service. Get the account details and the support contacts.
  • Any administrator accounts in their name. Note them down so they can be disabled or transferred once they leave, not deleted blindly, which can break things.

Write all of this somewhere safe and shared, not in one person’s inbox. This list alone prevents most of the genuine emergencies that follow a departure.

Protect yourself, calmly

There are a small number of security steps worth doing in the first days, and they are not about distrust. They are simply good practice any time access changes hands.

On their last day, disable rather than delete their accounts, and change shared passwords they knew. Confirm that multi-factor authentication is in place on email and any system that holds sensitive data, so a single leaked password is not enough to get in. Check that your backups are actually running and that someone other than the person leaving can confirm it. A backup nobody can verify is just a hope.

If that feels like a lot to judge on your own, that’s normal. This is exactly the kind of moment where a second set of experienced eyes pays for itself.

Decide what you actually want to replace

Here is the part worth slowing down for. The instinct after losing your IT person is to immediately hire another one. Sometimes that is right. Often it is worth pausing to ask what the role really was.

If that person spent most of their time on routine maintenance, password resets, patching, monitoring, and the occasional fire, much of that work can be handled by a managed provider more reliably than a single hire ever could, because it is a team rather than one person who also takes vacations and gets sick. If the role was more strategic, someone who understood your business deeply and made decisions, you may want to keep an internal person and surround them with outside support rather than replace the whole thing.

That second model, where your in-house knowledge is backed by an outside team, is what co-managed IT is built for, and it is worth understanding before you rush to rehire. Our switching and co-managed IT hub lays out how the pieces fit, and the deeper comparison of fully managed versus co-managed IT helps if you are not sure which shape fits your situation. There is no single right answer here, only the one that fits how your business actually runs.

A checklist so nothing slips

The transition itself is mostly about not forgetting things during a stressful stretch. A written runbook of every account, vendor, and system, with who now owns each one, is the artifact that turns a scramble into a process. If it helps to have a structured starting point rather than a blank page, our MSP transition and offboarding checklist is built for exactly this handoff and gives you the categories to work through.

Where to start

If you’re reading this in the first day or two after a resignation, the most useful thing you can do is talk it through with someone who’s handled this many times. We can help you capture access before it walks out the door, keep your business running while you decide, and figure out whether you need another hire or a different model entirely. No pressure, just a calm hand while things settle. We’re local to Alaska and Hawaii, we’re real people, and steady support during a stressful week is exactly the kind of moment we’re here for.

Book a Discovery Call