I have heard advice in the past to use SqlServer / StateServer early on in a project, so when you scale you don't fall into the trap of a developer using non-serializable objects InProc and it breaking when moving to SqlServer / StateServer later.
For the moment we have no need to use InProc of SqlServer session state, as we're just launching, but we'll probably need to scale reasonably quickly.
Does anyone have any reccomendations in enforcing serializable objects when using InProc? Perhaps creating a wrapper?
The important thing to remember that using SqlServer / StateServer is not just about scaling out (web farms). Even on one server you can run into problems when just using InProc sessions. Basically when using InProc any sessions that are "live" when the app pool recycles are lost. To put this in context, you may be running a purchase funnel and are storing something in the session that is critical to the process (why that may be bad practise is another conversation). Anyway, if that session information is corrupt / lost then the user won't be able to continue. So the app pool recycles and loses any currently live sessions - so any customers currently in your purchase funnel drop out and are potentially lost.
For that reason alone I'd always recommend running SqlServer sessions at a minimum (even locally). Better architecture generally negates any performance issues. If you do run into performance issues you could potentially look at 3rd party StateServer implementations that I'd should be faster.
If after reading the drawbacks of running InProc on a live server you're still happy to be doing that (they're your reasons, so that's fine) the only thing I could recommend is to change your dev server (or test) to run using SqlState and leave Live running InProc. That way you see any problems in the environment that isn't using InProc and can fix them in a none live environment. Then if you decide to switch Live over, you'll know that it won't need any extra dev effort and everything should be OK.