My expectation is that DNN 7 will still be actively maintained for at least 3 more years so there would be plenty of time for people to migrate, although I think the vast majority of next sites will be new sites.

Since it's basically a different product, it might also worth branding it under a different name. So you're on DNN platform or on the new Cool Name platform. For people that used DNN in the past, I think it will help reset their perception and give it another try. And for new users, it will sound cooler and it will be clearer that they're 2 different platforms.

I personally think that creating spa module types for dnn 7.5 & mvc is just going to be a waste of time.. Why bother when the modules are not going to be 100% compatible with dnn next anyway?

Module creators are not going to learn how to create dnn 7.5 spa modules, use then for a few months & then have to troubleshoot/relearn to make their modules compatible with the new dnn.. I think they will just continue to build modules like they currently do for dnn 7.0 & then worry about spa modules for dnn next. It will also save dnn a ton of time worrying about backwords compatibily for the few modules that were only created in dnn 7.5. It would be smarter for dnn to just concentrate on dnn next spa modules & to be able to do this well.

I also think that dnn needs to learn from microsoft vnext on this occasion - it is now time to break things & start completly from scratch (you can still maintain you dnn 7 branch for a few years so people can upgrade slowly over a period of time). Dnn can then use what they have learnt & do evrything they have dreamt about but couldn't do becase of backwards compatibility reasons. I don't think that you will never have the opportunity to break everything & start again like you do now - so do it while you can!

If it was me running the show I would:
-start completly again from scratch.. including a completly new api & admin areas...
-maybe think about a complete rebrand at the same time (so your not stuck with the legacy dnn haters)
-completly seperate the admin area of dnn so NOTHING touches the skins code - either a completly seperate backend like wordpress or eveything in popups (real ajax popups - NOT iframes) look at how http://www.bettercms.com/ does it.
-have a simple rule - "if it is skinable then it should be templatable" (eg.. login & registration pages should be part of the skin & should be templatable)
-be 100% responsive design from day one (including the admin area)

As a module developer that has been working with DNN for 10 years we have mixed views. The switch to MVC is going to take an investment of time for modules which don't support this framework.
Potential this could lead to some modules only working with older versions of DNN. I'm sure this might be a positive to DNNCorp in some cases since it removes some of the lower end modules that they viewed as devaluing the DNN commercial offering. As Shaun http://www.dnnsoftware.com/community-... pointed out the switch to MVC would in affect hit the reset button on all the skins and modules currently avaiable in the DNNStore.

The world have moved on and more is happening in the client browser window. MVC/WebAPI maybe fits better with the current modern style of development if you were creating a brand new module today.
Umbraco seems to have made the switch to MVC/AngularJS in a positive way.

When we first created Cart Viper the only option was to use WebForms. We have be active in using more AngularJS in our product which you can do in a more controlled and retro fit manner.
The switch to MVC presents more problems since we'd need to change the UI to match the new module framework. With this pressing change coming over the horizon, details seem to be thin on the ground from DNNCorp about what module developers need to start doing today to be ready for the DNN Next.
Are there any documents available to module developers so that we can start to ramp up for the changes coming?