I admit that we have made breaking changes in the RadControls rendering and skinning in the past few years. However, our controls are pretty mature with this regard now, so such changes will occur rarely from now on. Still, we cannot guarantee 100% backwards skinning compatibility in the future, that's why in a situation like yours with so many custom skins to support, I recommend you to be a little pessimistic, just in case. Don't get me wrong, we are not the bad guys, which always try to cause headaches to customers, but for your own peace of mind, I recommend you to:
+ use as many embedded skins as possible, without customizing them
+ make as few customizations as possible, the way that you have proposed - using an embedded skin, but overriding it with additional CSS styles. In this way, if we introduce a breaking change, the customizations may not work, but the embedded skin will, so fixing the customizations will not be that urgent and critical.
+ if you need to make really a LOT of customizations on a particular skin, then overriding the embedded one will not have any benefit, so it will be better to use only a custom one
+ if you need a complete custom skin, then I recommend you to use the "Colorize" or "Shift colors" options of our Style Builder. In this way, in a worst case scenario, you will easily create the custom skin again, based on the new version of the respective embedded skin.
+ reusing customizations and custom skins across sites and pages, if possible
+ it may be beneficial to use simple custom skins, i.e. with not too many background images or complex CSS selectors. In this way migrating CSS code manually will be easier, if you have to do that some time in the future
+ upgrade RadControls on some regular basis, so that you don't turn up with a lot of broken skins after 2-3 years
+ get familiar with the release notes and make some tests before upgrading. Test with beta releases and if it turns out that you have a problem, prepare yourself for the upgrade by reading documentation articles, implementing migration tools (we may provide ones as well), asking us for tips, etc.
the Telerik team