Migration

The system can keep running long after the reasoning behind it has left. You can’t test it, because the only place it runs is production, so you read the logs and you sit with someone while they do their job with it and build up a picture of what it does from the outside. The customer said it pulls from the billing platform on a schedule, but the logs say it pushes on a trigger, the connection string points at a host that isn’t on the network diagram, and the job everyone calls the nightly sync runs four times a day. At one point the worker does a step that makes no sense, and when you ask why, the answer is that’s just how it’s always done. It takes time and the picture you end up with is nothing like the description, but you get there. ...

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. That gap is the rollout version of the question I came back to in Better Than What It Replaces: is the new thing actually better for the person who has to use it? ...