The asymmetry between those two paths is the actual job. Inside the cluster, the old address and the new one can answer at the same time: the ExternalName object keeps `auth-svc.default.svc.cluster.local` resolving while the real pods run in the `authentication` namespace [7]. Outside the cluster, that same overlap is forbidden, because the OPA policy blocks identical ingress rules from being live in two namespaces at once [6]. Of the two routes that must survive the move, one supports a soak and one is a discrete switch [11].
What the forwarding address buys is coordination, and the arithmetic is stark. Under a rename plan, every consumer that hard-codes the old DNS name has to ship a change, and those consumers number in the dozens, sit with different teams, and run on different release cycles, some not redeployed in months [1][4]. Under the ExternalName plan, the count of consumer teams that must ship anything is zero [12]. That matters more than it sounds, because the deploy pipeline could only target one namespace and the author declined to rewrite shared pipeline logic every other team depended on [5].
The supplied excerpt is honest about the first path and silent on the second. It gives the object and the mechanism for in-cluster DNS, then stops at the verification step, without describing how the ingress leg was cut over [13]. The verification step is the part worth stealing anyway: once the forwarder was live, the author watched metrics through the crossover to confirm that traffic to the old address was landing on the new deployment rather than failing quietly, before scaling anything down [9].
Teams tend to assume a forwarder is temporary and that callers will update the address on their own schedule [7]. The same cluster argues otherwise: the deployment landed in `default` in the first place because it happened early, before anyone had opinions about namespace hygiene, and then other services came to depend on it [10]. A working stub creates no failure to force the fix, which is exactly why it needs a named owner and a removal date at the moment it ships rather than a mention in the migration doc.
The version of this you can apply to your own cluster is two questions per inbound path. First, does the old address keep resolving after the move? Second, can old and new be live at the same moment without violating a policy or a pipeline rule? Both yes means a forwarding stub and a soak you can measure. Yes and no, which is where the ingress path sits [6][11], means a timed cutover with a rehearsed rollback and someone watching the login graph. No and yes means you are back to chasing consumers, and the migration schedule now belongs to whichever team ships least often [4]. No and no means the honest plan has a maintenance window in it, and the argument to have is about which minute, not whether.
Worth noting what forced this at all: the service needed namespace-scoped ingress rules and policies that `default` structurally could not give it [8]. That is the trigger to look for in your own inventory, rather than tidiness.
