Platform/product either doesn’t support your current toolset or environment and you have to provide additional resources to get past this hurdle. In some cases it’s not even possible and causes delays in the early adoption process. Here’s it’s important to provide feedback to the vendor about the problems/issues and is generally received extremely well.
Unresolved issues with stability can be a big show stopper, especially when it’s reproducable and is aligned completely with core requirements. Again, feedback to the vendor is essential. Where other third party vendors are involved it’s even more important if this is within a toolset that your business is dependant on.
If the platform is part of a chain of processes, not being able to interoperate with those prior or next in the chain (leads back to compatibility in most cases) generally causes a lot of grief. It could even be that prior support for another product/platform/protocol has been removed in a new release, which more often than not causes the adoption process to stop completely.
These are just some of the areas that’s can to poke their heads up when you decide to move forward onto an early release.
These are the pure technical areas that can cause you sleepless nights so there’s naturally a level of “risk management” involved with the adoption of these new releases. Now, this doesn’t just have to be the only aspects that can hit you but are probably the most often seen problems.
Of course there’s also rewards for being on the cutting edge, some of the areas that I’ve seen positive reactions to the adoption of technology are:
– Positive innovator perception
– Improved technical readiness
– Pilot/PoC opportunities
So how are you approaching adoption of .Net x.x or project codename “Unspecified” on any platform or product that you’re working with?