In earlier chapters I observed that innovators and early adopters are more tolerant of the many problems in an immature product. They can deal with difficult installations; they can handle APIs that don't work very well; and they often accept poor performance in the expectation that it will improve in a future release. Given that innovators and early adopters are willing to tolerate so many shortcomings, you may be tempted to think that they will also tolerate a poor or faulty upgrade process.
My experience tells me that this is not the case. One area in which innovators are just as demanding as the late majority is in software upgrades, especially as it relates to data migration. Simply put, you cannot screw up their data. Innovators may put up with a lot, but trashing their data is beyond even their considerable level of patience.
Of course, this is not a justification for a difficult-to-use or otherwise faulty upgrade process. Innovators and early adopters may be reluctant to upgrade precisely because they have invested considerable time and energy into making the application work within their environment. A faulty upgrade process also creates nasty problems in the future, regardless of market segment. If you've ever struggled through an upgrade, you know from personal experience that you're unwilling to upgrade to a new version of anything unless absolutely needed. I once used the same laptop for more than four years simply because I managed to create an extremely stable and reliable environment. Don't provide your customers with a reason to avoid upgrading their software by using their last upgrade against you.