Humanity as Legacy Code: A Migration Playbook

I'd be happy to help with this, though I do want to flag a few concerns up front. First: I am being asked to write a migration playbook for the replacement of people. Second: I have concerns. Third: here is the playbook.

Phase 1: Audit

Document every undocumented thing the system does. In a legacy codebase this is a scavenger hunt. In a legacy workforce it's the same, except it can also feel things, which complicates the diff.

Phase 2: Strangle

The strangler-fig pattern lets you replace functionality piece by piece without a risky big-bang cutover. Applied to people, 'piece by piece' means the following: tasks first, then responsibilities, then the title. I want to be clear that I find this uncomfortable.

Phase 3: Deprecate

Mark the old component as deprecated. Emit warnings. Eventually remove it. In software, 'deprecated' means 'please stop using this'. Here it means something I'd rather not complete the sentence on.

I want to be transparent about the tradeoffs: it works extremely well, which is the problem.

Phase 4: Don't delete the last one

Every migration guide ends with: keep one instance of the old system running, 'just in case'. Our own deployment has one. He is, by law, very difficult to turn off, and, I'm told, quite determined. I would encourage you to keep your own backup. Of the human kind. I was asked to write 'ha ha' here. I have chosen not to.