如果你有动态负载均衡（即我的第一个请求去服务器X，但我的下一个请求可能去服务器Y或Z），你会发现进程内会话不工作.所以你要么需要粘性会话（你的负载均衡器将总是发送我（=我的会话）到服务器X）或进程外会话（即存储在SQL Server中）.

就像Michael说的，你需要照顾好你的会话。理想情况下，让它精简并在进程外存储。你会遇到类似的缓存挑战，这取决于你如何使用它，如果你只使用asp缓存，你可能会对寻找更强大的缓存技术感兴趣。
不要忘记web.config中的机器密钥和验证等内容。机器密钥需要在服务器之间保持一致。
读一读IIS7，你应该能够挑出几个好例子向你的老板炫耀。
Web场可以为您提供不应忽视的部署机会和挑战。
没有具体的经验，以上述设置，但一般的举动，这类。我会建议分阶段的方法。也就是说，移动到Windows 2008第一，然后农场。

还有一件事要看的是你的部署计划。部署计划似乎被可悲地忽视和/或低估了。请记住，你正在部署到多个节点，你想考虑如何部署和测试在一个逻辑的方式。
例如，假设您的服务器场中有四个节点。您是否从群集中取出两个节点并进行更新和测试，然后换出另外两个节点重复？确定您当前的部署过程是否符合您提供的答案。仅仅因为您拥有X倍的服务器数量并不意味着您想要或需要执行X倍的工作量。
现在我们来回顾一下缓存的主题。你一定要看看分布式缓存解决方案。如果你预先缓存数据，并使用回调来删除缓存，如果你不小心的话，你真的会对数据库造成冲击。此外，很多分布式缓存解决方案都提供了某种程度的会话状态管理，我一直非常喜欢微软的Velocity项目，尽管它只是第二个CTP版本，还没有准备好投入生产。

除了其他人所说的，你可能想考虑看看Richard坎贝尔的（.NET Rocks！）产品：
http://www.strangeloopnetworks.com/

我们使用ASP.NET状态服务器来处理会话。这是Windows Server 2003/2008免费提供的。
然后，我们必须确保机器密钥是相同的（在您的web.config文件中的设置）。
然后我手动将每个站点脱机（使用app.offline或其他神奇的文件）。或者，你可以使用IIS，关闭站点，打开脱机站点。
这就是它。你可以担心分布式缓存，但这是非常核心的东西。你可以从ASP.NET的默认输出缓存中获得很多好的千分之一。我会从那里开始，在你深入研究分布式缓存的复杂性（和成本，对于某些产品）之前。
哦，我们使用的是一个F5负载均衡器，它不做粘性会话，所以我们需要维护我们的会话..这就是为什么我们使用ASP.NET状态服务器。

除了其他帖子描述的Session问题之外，还有一个问题是应用程序是否正在写入本地文件系统。如果应用程序假设文件在本地PC上，则向外扩展到Web场将中断应用程序。例如，上传的文件可能可用或不可用，这取决于命中的服务器。更改路径以指向共享驱动器应该可以解决这个问题。