Network segmentation & domain migration

what do you mean with "new DD"  and retiring "existing DD"? An actual new DD or just new ddboost device definitions using another interface on the same DD?

Up until now whenever network changes were involved involving DD's and Networker storage nodes (which might occur mainly when dealing with various customer locations), they simply were reconfigured and then used in the same way again as before. If and when using DNS, it should be transparent for any clients and the infra as a whole? Should be possible within 8hrs. So why not simply re-IP the backup infra and you'd be done?

However it is a bad thing really if any application depends on backup infra being available always within 8hrs? An application idelly should be able to handle at least 3 days on its own. And yes, I know that excess storage is possibly the first thing to go, due to intended cost reductions. But the problem for capacity and avaialbility is simply shifted somewhere else. In my humble opinion unnecessary dependency on backup infra being created (or rather enforced) which could have simply been prevented.

But that is only about the DD and maybe a NW storage node involved, not the whole backup infra as that might entail to more effort. So that all depends on how things are configured in the CMO and how they are intended to be configured in the FMO?

For the backup server you also might have to consider licensing as the name and IP address as shown by for example nsrwatch on the nw server is what the license is linked to (if you are using an unserved license and not a license server that is).

Also a NW server cannot be renamed anymore if the FQDN is supposed to change as it would be put into a dedicated network. Renaming a nw server is no longer supported from the introduction of nw9 onwards, when it shifted to the policy based engine. The NW server name mentioned in way too many settings apparently for Dell to even consider supporting the renaming of a nw server. Way too many things that are likely to go wrong or no longer work, making dealing with "just" re-licensing a piece of cake.

So depending on the approach, doing things in one big bang, using DNS to handle different IP's. Taking special care of licensing, depending on the nw server config, but a recent NW version will keep on running in eval mode for 90 days if memory serves me right? So plenty of time to deal with that...

I however don't get how the vproxy deploy and vm backups config fir into the IP change? Are those already in place, and if so, wouldn't then only the vproxy IP('s) change possibly? Depending on the setup, we have vproxies with two nics, one talking to the VC and the other for backup traffic towards the DD's. The NW server needs to be able to talk to the 1st interface of the vproxy, so the NW server mgt interface is also routed to the VC mgt subnet and talks over its mgt interface to the vproxies, while the vproxies actually send backup data over their backup interface to the DD's. We also performed vproxy re-IP' ing together with a DD and NW SN re-IP on the same site.