Somewhere in your cluster there's probably a deployment sitting in the default namespace that everyone knows shouldn't be there. Nobody put it there maliciously, it just happened, early on, before anyone had opinions about namespace hygiene, and now half your other services quietly depend on it. Moving it is now a tricky problem.
That was the exact situation with a service I'll call auth-svc : an authentication service that dozens of other services called constantly, sitting in default for years, and about to become a genuine problem the moment it needed namespace-scoped things, its own ingress rules, its own policies, that default structurally couldn't give it. Moving it wasn't optional forever. But it also couldn't go down, not even for a few seconds. This wasn't a vague "other services might complain" risk: auth-svc handled authentication for that entire region's cluster, so if it went down, nobody in that region could log in.
Before getting into why this is actually hard, it's worth being precise about what "moving it" means. There are two completely separate paths into auth-svc , and both have to keep working throughout the move, or fixing one just creates an outage in the other. Everything inside the cluster reaches it the ordinary way: other services resolve auth-svc. local through Kubernetes' own internal DNS and get routed to a pod, the standard Service mechanism. Everything outside the cluster reaches it through an ingress instead, a completely separate mechanism that has nothing to do with that DNS name.
Whatever the fix turned out to be, it had to solve for both paths, not just the one that's easier to reason about. The obvious plan, move the deployment, update the references, done, falls apart the moment you look at who's actually calling this thing. As mentioned, dozens of other services reference auth-svc by its cluster-internal DNS name, owned by different teams, on different release cycles. There's no atomic moment where you flip a switch and every one of them simultaneously starts using a new name. Some team's service hasn't been redeployed in months. You shouldn't be coordinating that.