Some will argue that this isn’t good, as I can't look at my change and know whether it’s UC or NUC. That's right. You can't. In fact, I can take the exact same change at two different points in time and it will be UC at one point but NUC at another. You cannot just look at the change. You have to look at the whole picture.
Sometimes we find this out the hard way. You have to look at the whole picture. So how does this definition of UC help? Well, basically, it begs the question by focusing you on the heart of the matter. You need to understand if a change you are making can go ahead without continuing support for the previous version - then you know whether it is UC or NUC. If it is NUC, then you need to first identify if there's an UC (sounds the same as "a NUC!") way of doing the same thing. You'll be surprised at the ingenuity when someone understands the impact of their change.
NUC to UC Transformation
If you cannot find an UC way, you then need to break it down into a series of steps that make the "NUCness" easier to swallow. First, identify all of the customer-affecting elements (in the broader sense) and how they affect each customer. Then identify the best way to prepare the customer to accept the change most easily. Maybe it's adding a data field to the schema ahead of time. Maybe it's retro-fitting a feature into the current customer release first. Maybe it's throwing a party for them on the day the system is going to be out of service! You want to isolate the incompatibility from the rest of the change as much as possible, and make it less visible to the customer.