Methods for mitigating viewstate tree changes when deploying to a high traffic site

I am helping to build a relatively tall traffic web application that uses ASP.NET WebForms. Although our use of viewstate is relatively small, we currently require it.

When deploying a change to the master master page, we often cause the currently connected users to receive an error message the next time they issue a POST request. The reason for this is that the viewstate tree that exists in its POST request no longer matches the expected message. Since we are web applications, many of our pages do POST.

Of course the complete error is:

Failed to load viewstate. The management tree into which the viewstate is loaded must match the management tree that was used to save the view state at the time of the previous request. For example, when adding controls dynamically, controls added during feedback must match the type and position of controls added during the original request.

Naturally, this is very frustrating for our users. At the moment we are trying:

• Minimizing changes to the master page (at least changes related to server controls).
• Deploy during periods of low traffic

I thought about how to do some load balancer-tied tricks to try and force re-enroll users in the newly deployed version while keeping the current users in the old version - but this seems extremely complex and maintains multiple codebases in production isn't really where I want to go.

I appreciate that technology is not really our friend here, but was just wondering if anyone has any advice or techniques they use to mitigate this issue.