将您的社区从一个平台迁移到另一个平台可能是一项艰巨的任务。如果您计划切换到 Discourse，以下是一些建议，以帮助整个过程尽可能顺利。
早期沟通
将社区迁移到另一个平台时，最大的障碍是对变化的恐惧。没有人喜欢意外，尤其是当他们觉得自己投入了感情的社区时。您可以通过在数周（或数月）前向成员简报即将到来的过渡来缓解这种情绪。根据我们的经验，如果成员提前知晓并在心理上做好准备，他们的反应会好得多。让他们表达感受，并让他们成为这一旅程的一部分。坚定地管理期望，让他们知道决定已经做出，但同时给予他们发声的机会。
强调他们将看到的一些积极变化是一个不错的方法。如果存在妥协，也要讨论并解释您的理由。建议他们访问 https://try.discourse.org 亲自体验软件可能很有帮助——熟悉度有助于使过渡更加顺畅。
在数周（或数月）前向社区成员简报即将到来的过渡。让他们表达感受并参与旅程。强调他们将看到的一些积极变化是一个不错的方法。
重新评估现有做法
迁移平台时潜在的陷阱之一是试图完全复制之前的设置。我们建议您利用这个机会重新评估您的需求。审视您的信息架构。您真的需要所有这些子论坛吗？或者通过使用标签能否提高性能？您旧的 moderating 程序是否仍然是最有效的方式？也许您可以利用旗帜（flags）和信任等级（trust levels）将其中一些工作众包出去，以便您的 moderating 团队可以专注于更主动的任务。
避免试图完全复制之前的设置。利用这个机会重新评估您的社区需求。
测试版测试
在迁移过程的早期让 moderating 团队（以及潜在的关键利益相关者或超级用户）加入，是在发布前进行测试和收集反馈的绝佳方式。这为他们日后支持更广泛的社区做好了准备，也意味着他们将能够积极倡导即将到来的变化。
在技术层面，让 moderating 和超级用户参与测试版测试，将大大增加您在发布前发现任何问题的可能性。仅让您的社区经理（CM）或管理团队进行测试版测试，意味着只有他们的日常工作流程会被测试。
让 moderating 和超级用户参与测试版测试，将大大增加您在发布前发现任何问题的可能性。
谨慎地进行迁移数据的 QA
我们在帮助客户迁移到 Discourse 时经常注意到，他们往往匆忙完成 QA 流程。这是过程中最重要的部分之一。您需要确保所有数据都位于正确的位置，因为事后修复极其困难，往往具有破坏性，并且可能会让用户非常反感。
在迁移后制作一份待验证的数据清单。类别和子类别是否按预期组织？私密区域是否仍然隐藏？图片和附件是否成功迁移？代码格式是否仍然正确？您可以使用这份 出色的发布前迁移清单。
QA 是过程中最重要的部分之一。不要匆忙完成。在迁移后制作一份待验证的数据清单。
预判潜在的进入障碍
Discourse 中用户身份的概念（以及我们链接账户的主要方式）围绕电子邮件地址展开。如今人们往往有多个电子邮件地址，因此提醒用户思考他们最初用于注册论坛的电子邮件地址是个好主意。如果他们等到您完成迁移后才发现问题，因为忘记了使用的地址或无法再访问该地址而无法登录，那么这种初期的困难可能会破坏整个体验。
提醒用户思考他们最初用于注册论坛的电子邮件地址。
发布
不要在周五发布！确保在压力较小的时候切换开关。您需要随时待命以应对任何问题、回答问题、提供帮助并推广新平台。我们建议如果可能的话，在周初进行。事物可能需要几天时间才能稳定下来。
通常，全局置顶一个包含人们最常访问位置的链接的主题会很有帮助。让您的行动号召（CTA）清晰明了，不要过于冗长。这个横幅不应是关于营销，而应是关于引导。
考虑创建一个专门的主题，将所有反馈集中在一个地方。对于头几天的投诉不要惊慌。让成员安顿下来并熟悉环境。回答“如何使用”类的问题和建设性反馈，但不要陷入争论或使用防御性语言。
为修复错误提供合理的时间框架，并确保遵守。此时管理期望至关重要，因此不要承诺可能无法实现的事情。
不要在周五发布！确保在压力较小的时候切换开关。
考虑重定向
大多数 Discourse 迁移脚本会生成 301 重定向列表，但最好与您的工程师再次确认。然后，您可以在发布后使用 Webmaster Tools 监控几周，以检查 404 错误和其他意外问题。
在发布后监控几周，以检查 404 错误和其他问题。