Migration

I’ve sat through more than one migration where something stopped working and the trace eventually led back to a service account nobody knew was there. In one case it was a Windows scheduled task running as domain admin that hadn’t been touched in years and didn’t have an owner anyone could name. The pattern keeps showing up because migration is the only exercise that forces enumeration of what an application actually depends on, and the dependencies tend to include credentials with more access than anyone remembered granting. Scoping the account down to the permissions it actually needed took longer than anyone wanted to spend on it, but it left the customer with permissions they could justify and revoke if they needed to. ...

I avoided the new Outlook for over a year before eventually giving in, and the feature that kept me on the old version wasn’t anything complicated. In a previous role where my calendar was packed with recurring internal meetings and customer calls, I had a rule in classic Outlook that automatically colour-coded any meeting I created as purple, so I could see at a glance which ones I could move and which were fixed. When I switched, that rule was gone. ...

Most migrations don’t start because someone planned one, they start because half the organisation is already using something unsanctioned and you’re formalising it before it turns into a compliance problem. I’ve seen that across different types of tech, and the failure mode is always the same: the pilot gets all the investment and the rollout gets whatever’s left, which is usually not much. The hard part of a migration is usually the stretch between a successful pilot and a real rollout. ...