Don't bundle UC changes with the NUC changes where you can avoid it. Your job is basically to identify a way to transform the NUC change into an UC one, with as little risk and impact as possible. OK, our network is going to be down for 2 hours. If all the NUC stuff, and only the NUC stuff is done in that 2 hours, it's easier to believe the downtime estimate. It's easier to roll back if something goes wrong. It's easier to understand the risks. Then when the network is back up, add the rest of the changes in - the same day or over the next few weeks. Unless there's an urgent concern, it won't matter much. And the customer knows the network will remain up.
Eventually you'll start to use foresight, such as enabling the previous release before it is shipped, with the proper data structures so that conversion to the next release is painless. If you work at identifying (and I would argue implementing) NUC changes near the beginning of your release development cycle, there's a good chance you'll have time to put some hooks into the previous release before it's widely distributed.