That's an excellent point, Matt. Before treating it strictly as a technical handover problem, the company should honestly ask why that person left and whether it could have been prevented.

Good employees who build institutional knowledge are valuable, and replacing them can cost far more than fairly recognizing that value while they're still there. Helping people grow is good for the business, but it also means the business has to make an effort to retain them.

Far too many organizations don't value their employees enough.

A key point in Richard's video is that the person who asked that question specifically said, "Nobody understands how [the Access database] works..."  That means when the Access guy leaves, they will likely have to find a replacement of the Access DB itself.  Leaving it to the existing employees to figure it out is risky, because no matter how well or fast they learn Access, *they don't know what they don't know*.  As a creator of databases for other people, Richard, you probably know that certain things are known only to the creator, not the client -- obscure third-party tools tucked inside the PC, special config settings, dependency files, etc.  It may be tough even for an Access expertise to pry into the Access creation of another Access expertise, let alone people who "know nothing about Access."

When I was the IT manager of my company, I was fully aware of the importance of "what I knew."  Even when I took days off for vacations (let alone leaving the company), I had to have some contingency plans in case my co-workers needed some info only I would know.

If I were the boss, I would insist the soon-to-be ex-Access manager find a replacement for his database before he leaves the company.  He is the one with the technical expertise, so he should be, and frankly is the only one, who knows what and how to replace the existing DB.  Find a consultant to build an equivalent database.  If they can build it with Access, that's fine, of course.  But let the consultant pick an environment they prefer, because it wouldn't make a difference to the non-technical employees whether the DB is on a Microsoft system or some exotic OS.  If the job takes N months, then the soon-to-be ex-Access person should stay in the company until N months later.  If he has to leave before the replacement is done, he should at least remain in contact as a liaison between the consultant and his former employees until the project is finished.

(Continued from my previous post)

When a replacement DB is in place, it will (1) no longer have any dependencies on the ex-Access employee, (2) get full technical support from the consultant who built it, and (3) not require the other employees to learn anything new, thus saving money for the company.  The only additional cost is what was and will be paid to the consultant.  It may even save (big) money for the company if you compare the ex-Access guy's salary to the consultant's cost.  In my experience, a consultant is always cheaper in the long run than an in-house IT manager.  

P.S. I was an in-house IT guy who worked at a time when few people had technical expertise.  In the early 90s when I got my job, my company was still using typewriter, pencil, and paper.  There was not a single computer in sight.  I had to help them convert practically every task, from writing letters to keeping records, to a computerized equivalent.

Oh yeah, I hear you. I've worked with a lot of companies like that, where one front-office person did the books, managed order entry, and basically kept the whole operation running with Lotus 1-2-3 or an old Excel spreadsheet.

A couple of times, I walked into companies where that person had died, retired, or otherwise left. Sometimes they were still available to help with the transition, and sometimes they weren't. That's exactly why it's important not to put all of the company's operational knowledge in one person's head - especially now, with everything tied so closely to technology. You don't want all your eggs in one basket, and then have the guy leave with the basket.

That's also how I feel about AI. Don't become so dependent on it that it's building and maintaining your systems for you, but nobody understands what it's doing. If it suddenly doesn't work, what do you do? It's the same basic problem as having your database person walk out the door with all the knowledge.