在我 12 多年的职业生涯中，我还没有克服这个障碍，而且我怀疑答案并不容易，甚至是不可能的，所以我在这里向大家询问他们的经验。
假设您遇到了严重问题，只有从一个平台转移到另一个平台才能解决 - 要么是因为在选择多年前选择的平台时犯了错误，要么是因为系统的发展超出了最初的设计目的。您肯定知道，随着时间的推移，积累的垃圾将不可避免地意味着几乎不可能测试所有的东西，这肯定会导致技术支持地狱 - 我们都知道这会导致客户流失。并不是说客户还没有抱怨已经存在的严重问题！
到目前为止，我发现的最佳方式是制定一个转换计划，在几个客户机上测试，在十几个客户机上测试，在一百个客户机上测试，最后为所有人完成转换，并祈祷你已经解决了前一百二十个客户机上的所有问题，并且动物副产品不会以最壮观的方式冲击通风系统。
但是，这并不意味着它不会发生。
假设您要从 Exchange 迁移到 Exim（或者甚至只是从 Sendmail 迁移到 Exim）。您该如何处理？
答案1
这是一个棘手的问题，具体情况不同，关键问题是：
- 有一个后备计划无论你做什么，都要制定一个如何快速恢复旧系统的计划。如果你做不到这一点，那么就需要进行更多的测试。
- 测试最常用的功能。查看日志或衡量哪些功能最常用且更为关键。更彻底地测试该功能。
- 让包括您自己在内的多个用户在新服务器上“活跃”数天。时间长度应取决于变化的剧烈程度。（例如，“您应该是第一个测试者”）
- 如果可能的话，将新服务与旧服务并行运行。如果可以在中间放置代理并转发某些请求或用户，这可能会有所帮助。
- 在负载平衡的集群中运行。这与上一条语句类似。如果您可以在负载平衡的配置中运行这两项服务，请尝试一下。随着事情的顺利进行，您可以逐渐摆脱旧服务。
- 将旧服务器保留几周或更长时间。当我不确定是否需要使用旧服务器时，我会保留它们几个月。关闭它们或断开网络电缆，以确保服务器上没有隐藏的依赖关系。
- 确保新服务能够处理负载。逐步部署并监控系统性能，同时逐步将更多流量转移到新系统。
- 做事时，确保故障可见且立即出现。你希望故障尽早发生并易于识别。
充分利用 DNS。将两个服务设置为响应相同的 DNS 名称，但让 DNS 指向其中一个或另一个（或以循环方式同时指向两者）。使用 Linux 和 Windows 上的本地主机文件覆盖 DNS，并能够在推出之前和之后验证设置。这也使得推出后更容易进行故障排除。只需将本地主机文件更改为旧服务器，看看问题机器上是否仍然有问题。将 TTL 设置为较低以允许快速回退。可以使用 Cisco 的 GSS 等负载平衡器来实现这一点。我可以使用 iptables 将特定的负载平衡主机从池中取出。
对于 Apache，使用反向代理是逐步迁移站点的好方法。对于其他站点，使用 DNS、代理或 iptables 框为您提供有关如何控制转换的选项。