The Only Person Who Knew: Handing Over IT When a Hong Kong Firm's Sole IT Manager Resigns

Short answer: the risk is not the vacancy. It is that an undocumented IT estate walks out of the building inside one person's head. In a one-month notice period, capture access first, then inventory, then the things only they know — in that order, because the first two stop being obtainable the moment their account is disabled.

A managing partner at a 50-person Hong Kong surveying practice described it to us in one sentence: "He handed in his notice on Monday, and by Wednesday I realised nobody else knows the password to anything."

That firm is entirely typical. Somewhere between thirty and eighty people, professional services, a sole IT person who has been there five or eight years, and an estate that has grown around that person rather than around any documented design. There is a server in a cupboard nobody else has opened. There is a domain registrar account in his personal email. There is a reason the accounting system has a workaround, and he is the only one who remembers what it is. There is a hardware vendor who answers his mobile and not the company's main line.

None of that was negligence. It is what happens when one competent person runs IT for a firm that has grown faster than its documentation, and it describes a very large share of professional-services firms in Hong Kong.

What follows is what to do with the four weeks you have.

Why this is so common in Hong Kong firms of this size

Three things compound in this particular segment.

The size band is awkward. Below roughly thirty people, a firm usually outsources IT or gets by on consumer-grade tools. Above a hundred, it has an IT team with at least two people in it. Between the two, one person is affordable, sufficient and — everyone assumes — fine. Nobody in that band has budgeted for redundancy, because until the resignation letter arrives there is nothing visibly wrong.

Hong Kong's professional-services firms run a wide estate on a thin team. A 50-person surveying, accounting or consulting practice will typically have a domain, a Microsoft 365 or Google Workspace tenant, a file server or NAS, VPN access for site staff, a practice-management or job-costing system, a document management system with retention obligations, several industry-specific applications with their own licence servers, a handful of vendor portals, and a PDPO exposure across all of it. That is not a small estate. It is simply one that has never been written down.

Notice periods are short and the market is liquid. One month is standard for a non-executive role in Hong Kong. An experienced infrastructure generalist who reads English and Cantonese does not spend long between jobs. So the window is fixed, it is short, and it will not be extended by goodwill once they have signed elsewhere.

The result is a predictable crisis that nobody in the firm has ever rehearsed.

What "the only person who knew" actually means

It is worth being concrete, because the abstract version of this problem — "we need better documentation" — leads to a document that satisfies nobody.

The knowledge that walks out is of four kinds, and they behave very differently.

• Credentials. Admin accounts, the registrar login, the firewall's enable password, the backup console, the NAS root account, the vendor portals, and the accounts that are registered in his personal name or personal email. These are binary: you either have them on his last day or you begin a recovery process that can take weeks and sometimes requires notarised company documents.
• Inventory. What exists, where, under what licence, on what warranty, renewing on what date, paid by which credit card. This is recoverable without him, but slowly and with gaps.
• Dependency. What breaks if you switch off the machine in the cupboard. Which report depends on which scheduled task. Why the VPN has a static route that looks wrong. This is the layer that produces the unpleasant surprises in month two.
• Tacit knowledge. Why a workaround exists, which vendor actually answers, what was tried in 2023 and failed, which user must never be locked out of which system for reasons that are political rather than technical. This is the only layer that genuinely cannot be reconstructed, and it is the one most people leave until last.

Order your four weeks against that list, not against a generic checklist. And note that the ordering is not about importance — tacit knowledge is arguably the most valuable — but about expiry. Credentials and inventory stop being obtainable when the account is disabled. Tacit knowledge decays more slowly and can, at a pinch, be partially recovered later through a paid consultancy arrangement, if you have the relationship to ask.

Week one: access and identity

Do this first, before anything else, and do not let it be deprioritised by whatever is on fire operationally.

Enumerate every account with administrative privilege, across the identity tenant, the firewall, the switches, the NAS, the hypervisor, the backup system, the endpoint management console, the antivirus tenant and every SaaS application the firm pays for. Not "the ones he uses" — all of them, including service accounts and break-glass accounts.

Establish a second administrator now, not later. Create it, test it independently by logging in from a different machine, and store the credential in a company-controlled password manager that the managing partner or finance director also has access to. The test matters: an admin account that exists but has never been signed into is not a control, it is a hope.

Find everything in his personal name. This is the single most-skipped step and the one that most often becomes a genuine crisis. Domain registrar accounts, SSL certificate accounts, mobile carrier accounts, vendor support portals, a corporate card registered to his email, app-store developer accounts, and any two-factor authentication seeded to his personal phone. Each one needs to be transferred to a company-owned identity — a shared mailbox or a role account — while he is still willing to help. After his last day, several of these require the vendor's account-recovery process, and some of those processes are genuinely difficult.

Change what needs changing on his last day, and know in advance which changes have blast radius. Rotating a service account password without knowing what uses it is a good way to take the firm offline on the Monday after he leaves.

Write down the renewal calendar. Domain expiry, SSL expiry, licence anniversaries, support contract end dates, circuit contract end dates. A lapsed domain renewal four months after a departure is a common and entirely avoidable failure.

Week two: inventory and dependency

With access secured, build the picture of what you actually own.

Walk the estate physically as well as logically. Someone should open the comms cupboard with him, photograph what is in it, and write down what each thing does — including the unlabelled box that has been powering something important since 2019. Do the same for any equipment at a second office or a site portacabin.

Record, for every device and system: what it is, where it is, what it does, who depends on it, what it costs, when the support or warranty ends, and what happens if it stops. That last column is the one that turns an asset list into something useful.

Then do the same for the non-physical estate: subscriptions, licences, circuits, mobile plans, cloud tenants, and any third party with standing access to your systems. Vendors with remote access are a frequent surprise — the practice-management supplier who has had a VPN account since the 2021 implementation, for example, which is both an operational dependency and a PDPO question worth asking.

Finally: test the backups. Not "check that the backup job reports success" — actually restore something, to a different location, and open it. The single most common thing a departing solo IT manager leaves behind is a backup regime that has been reporting green for years and has never been restored from. You want to discover that while he is still employed.

Week three: the tacit layer

This is the week most handovers skip, and the reason so many handovers fail despite producing a thick document.

A document written alone is a document written optimistically. Left to write it in isolation, a departing engineer will record the architecture as it was designed, not as it has drifted; will omit the workaround because it is embarrassing; and will forget the things that are so obvious to him that they do not register as knowledge at all.

The alternative is to walk the estate with him and record it. Sit beside him, pick a system, and have him narrate: what this is, why it is set up this way, what breaks it, what you do when it breaks, who you call. Record the session — audio is fine, screen capture is better. Then have somebody else follow the narration and try to perform one routine task from it. The gaps appear immediately.

Prioritise, in this order: the things that would stop the firm working today; the things with a compliance or client-confidentiality dimension; the annual events nobody will see happen until they fail, such as a year-end process or a licence renewal; and last, the nice-to-know.

Ask directly for the uncomfortable list, too. Which system are you most worried about? What have you been meaning to fix? What is held together by something you would not put in writing? Most departing engineers will answer that honestly if it is asked as a professional courtesy rather than as an audit.

Week four: verify by doing, not by reading

A handover is not complete because a document exists. It is complete when somebody other than the departing person has performed the work.

In the final week, have the replacement — internal, interim, or the incoming provider — actually execute the routine operations while he is still there to correct them:

• Run a restore. End to end, to a usable state, from the real backup system.
• Run a joiner. Create an account, assign licences, configure the device, grant the application access, and confirm the new user can do their job.
• Run a leaver. Disable, revoke, reassign the mailbox, collect the device, and confirm nothing was missed. This is also a PDPO-relevant control, and it is the natural point at which handover work and offboarding discipline meet — that piece covers revoking an ordinary user's access; what you are doing here is acquiring an administrator's undocumented knowledge, which is the harder half.
• Run a change. Push a patch, reboot something, follow the documented rollback.
• Trigger an escalation. Call a vendor using the account details you have recorded, and confirm that the vendor accepts your authority to open a case without him.

Anything that cannot be performed from the documentation is a gap, and you still have a few days to close it.

The decision you have to make before the notice ends

There are really only two paths, and deferring the choice is itself a choice — it defaults you into the first one badly executed.

Replace the person. Hire another solo IT manager. This is the familiar option and it preserves the shape of the organisation. It also reproduces the exact position you are in now, with a fresh person who will accumulate their own undocumented estate over the next five years, and it leaves you covering the gap between his last day and their start date with nobody.

Replace the model. Move to a managed service, where documentation, monitoring, patching and the help desk are a system rather than a person's memory, and where any individual engineer is replaceable by design.

Honestly, both are defensible. The size of the estate, the firm's appetite for having a named person in the office, and whether the departing person was genuinely doing infrastructure work or mostly doing help desk should all inform it — our comparison of managed IT versus an in-house team for Hong Kong SMEs goes through that arithmetic properly. What is not defensible is deciding by inertia: starting a recruitment process, not filling it in four weeks, and covering the gap with a partner's PA and a break-fix number found in an old invoice.

Comparison: three ways firms handle a solo IT departure

Hire a direct replacement

• Gives you: continuity of model, a named person in the office, full control of priorities.
• Costs you: a hiring cycle you probably cannot complete inside the notice period, an uncovered gap, and the same single-point-of-failure position rebuilt from scratch.
• Best when: the role is genuinely broad and strategic, the firm is growing toward a second IT hire anyway, and there is somebody senior who can supervise the handover technically.

Bring in an interim contractor for the gap

• Gives you: hands quickly, and someone present to receive the handover before it expires.
• Costs you: a day rate, and the knowledge transfer happens twice — once to the contractor, once to whoever follows them — with loss at each hop.
• Best when: a permanent decision genuinely cannot be made in four weeks and you need to stop the clock.

Move to a managed service with a structured takeover

• Gives you: documentation you own as a deliverable rather than a favour, monitoring and patching that do not depend on anyone's memory, a help desk with a rota, and escalation depth behind whoever attends.
• Costs you: a per-user monthly fee, and a transition project that takes longer than four weeks to complete properly.
• Best when: the estate is standard rather than exotic, the departing person was spending most of their time on support rather than engineering, and the firm would rather buy a system than a person.

What a structured takeover actually looks like

If you choose the third path, the thing to test in any provider's proposal is whether the transition has a defined shape or is simply an onboarding form.

Brocent's own IT transition and onboarding service is a three-month structured takeover, and it is worth describing because the shape is the point rather than the branding:

• Weeks 1–2, survey and audit. Site visits, IT asset inventory, device audit, network topology, data classification and a backup/restore policy review, plus an explicit identification of the top three infrastructure weaknesses. That last item matters in this scenario: the departing person's estate almost always has three things they knew were wrong and never had time to fix.
• Weeks 2–4, knowledge transfer. Engineers shadow the outgoing person or study the documentation, a CMDB is built on the management platform with all assets, configurations and licences catalogued, and standard operating procedures are defined for every recurring task.
• Weeks 3–6, shadow and re-shadow. The incoming engineers run the support process under observation until they meet a benchmark without supervision, while the three identified weaknesses are addressed and security hardening is done.
• Month 3 onwards, go-live. Full transition, an SLA-backed help desk with a 15-minute P1 first response, 24/7 monitoring, monthly reporting, and a documented escalation matrix — followed by a formal 30-day post-go-live review specifically to catch the knowledge gaps that only surface once you are operating.

The deliverables are the part to insist on in writing: a full asset inventory with warranty and licence records, a CMDB, and a technical runbook covering architecture, vendor contacts, the escalation matrix, licence renewals, backup and DR procedures, and known historical issues. That runbook is the artefact that makes the next departure — provider-side or yours — a scheduling problem rather than a crisis.

One thing to notice about the timeline: a three-month takeover is longer than a one-month notice period. That is not a contradiction, it is the actual reason to start the conversation in week one rather than week four. The parts that must happen while the departing person is available — the knowledge transfer and the credential capture — are early in the sequence by design.

Why documentation you own is the whole point

The deeper lesson of a solo-IT departure is not "we should have documented more". It is that documentation which lives with a person is not documentation at all, and the same failure repeats with a provider if you let it.

The test is simple and worth applying to any provider you are considering: if we terminate you, what do we get, and is that a contractual entitlement or a courtesy?

Brocent's answer is that customer-owned documentation and credentials is an included item in every Managed IT plan tier — asset records, credentials, runbooks and site notes belong to the customer as a matter of standing policy, not as a negotiated concession. Whatever provider you use, get the equivalent stated in the contract. A provider who will not put it in writing is building exactly the dependency you are currently paying to escape.

And there is a compliance dimension worth noting without overstating it. Under the PDPO, a data user remains accountable for personal data it holds, including data processed by an agent. The credential hygiene described above — no shared personal accounts, no admin passwords in personal password managers, a clean revocation on the last day, a documented list of third parties with standing access — is good IT practice first and a compliance by-product second. It is not the reason to do the handover properly, but it is a reason your auditors will eventually ask about.

Where to start if this is happening to you now

If the resignation letter is already on the desk: start with week one this afternoon. Enumerate admin accounts, create and test a second administrator, and list everything registered in his personal name. Those three tasks expire soonest.

If you are reading this without a resignation on your desk, the useful exercise is shorter. Ask your IT person to hand you, this week, a list of every administrative credential, every account in their personal name, and the three things about your estate that worry them. If that list cannot be produced in a week, you already know what the handover would look like.

Either way, if you want the estate documented, monitored and supported by a system rather than by a person's memory, that is what a per-user managed plan is for — and if the departure is imminent and you would like the transition sequence mapped against your specific notice period, get in touch. Brocent has run this takeover in Hong Kong since 2016 and has been doing structured transitions since the company was founded in Beijing in 2007.

Frequently asked questions

How long does an IT handover take?

The capture phase — credentials, inventory, dependency and tacit knowledge — fits into a one-month notice period if it starts in week one and is sequenced by expiry rather than by importance. A full transition to a managed service is longer: Brocent's structured takeover runs three months, with knowledge transfer deliberately placed in weeks 2 to 4 so that it happens while the outgoing person is still available. The two overlap rather than run in sequence.

What if they have already left?

You are in recovery rather than handover, which is slower but not hopeless. Prioritise regaining administrative control: vendor account-recovery processes, which often require company registration documents and a director's authorisation; a full discovery scan to rebuild the inventory; and a restore test to find out whether your backups are real. Budget for a period of reduced change capability — you should not be making risky changes to a system you do not yet understand. Where the former employee is willing, a short paid consultancy arrangement for the tacit layer is usually money well spent.

Who owns our documentation?

You should, always, and it should say so in the contract. With Brocent, customer-owned documentation and credentials is an included item in every Managed IT plan tier rather than something negotiated. If a current or prospective provider treats documentation as their property, you are buying the same single-point-of-failure you are trying to escape, with an invoice attached.

What if credentials are in a personal password manager?

Deal with it while they are still employed and it is a transfer exercise; leave it and it becomes an account-recovery exercise with each vendor separately. Ask for an export of work-related entries, verify each one by logging in independently, then store them in a company-controlled vault with at least two people holding access. Going forward, the rule is that company credentials live in a company vault — personal password managers are for personal accounts, and this is a policy question for the managing partner rather than a technical preference.

Can a provider take over without a handover?

Yes, and it happens regularly — but it costs more and takes longer, because the audit phase has to reconstruct what a handover would have simply told you. Expect a heavier discovery effort, a period where the provider is deliberately conservative about changes, and a higher chance of surprises in the first quarter. If there is any overlap available with the departing person, even a few hours of recorded walkthrough, it materially reduces both.

Should we hire a replacement first?

Not necessarily, and the sequencing trap is real: starting a recruitment process does not stop the notice period running. Decide first whether you are replacing the person or replacing the model, because that determines what you do with the four weeks. If you are genuinely unsure, an interim arrangement that receives the handover properly is better than an empty chair, because the handover window does not reopen.

What is the single most-missed item?

Accounts registered in the departing person's personal name or personal email — domain registrars above all, followed by SSL certificates, vendor support portals and two-factor authentication seeded to a personal phone. They are missed because they are invisible from inside your own systems: nothing in your tenant tells you that your domain renewal notice goes to someone's Gmail. Ask the question explicitly, in those words, in week one.

Does this count as offboarding?

It includes offboarding but is considerably larger than it. Offboarding an ordinary employee is about revoking what they could reach. Offboarding your administrator is about acquiring what only they knew, and then revoking what they could reach — and the second step is safe to perform only after the first is genuinely complete. Doing them in the wrong order is how firms lock themselves out of their own systems.