コミュニティをあるプラットフォームから別のプラットフォームに移行するのは、気が遠くなるような作業になることがあります。Discourse への移行を検討されている場合は、スムーズに進めるためのいくつかのヒントをご紹介します。
早期のコミュニケーション
コミュニティを別のプラットフォームに移行する際に最も大きな障壁となるのは、変化への恐れです。特に自分が貢献していると感じるコミュニティについては、予期せぬ変化は誰も好まないものです。移行の数週間（または数ヶ月）前にメンバーに事前に説明することで、これを緩和できます。経験上、事前に情報を得て精神的に準備ができている場合、メンバーは移行により前向きに反応します。彼らの気持ちを表明させ、プロセスに参加させましょう。決定は下されたことを明確に伝えつつ、彼らの声を聞く機会も提供してください。
彼らが目にするであろうポジティブな変化を強調するのも良いアプローチです。妥協点がある場合は、それについても話し合い、その理由を説明しましょう。https://try.discourse.org にアクセスしてソフトウェアを試すよう提案すると、慣れが移行をスムーズにするのに役立つかもしれません。
移行の数週間（または数ヶ月）前にコミュニティメンバーに事前に説明し、彼らの気持ちを表明させ、プロセスに参加させましょう。彼らが目にするであろうポジティブな変化を強調するのが良いアプローチです。
既存の慣行の見直し
プラットフォーム移行時の落とし穴の一つは、以前のものを完全に再現しようとする試みです。機会を捉えて自社のニーズを再評価することをお勧めします。情報アーキテクチャを見直しましょう。すべてのサブフォーラムが必要でしょうか、それともタグを使うことでパフォーマンスを向上できるでしょうか？古いモデレーション手順は、今でも最も効果的な方法でしょうか？フラグや信頼レベルを使って一部をクラウドソーシングし、モデレーションチームがより先駆的なタスクに集中できるようにするかもしれません。
以前のものを完全に再現しようとするのは避けましょう。機会を捉えてコミュニティのニーズを再評価してください。
ベータテスト
移行プロセスの早い段階でモデレーターチーム（および重要なステークホルダーやスーパーユーザー）をオンボーディングすることは、ローンチ前にテストを行いフィードバックを集める素晴らしい方法です。これにより、彼らは将来的にコミュニティ全体をサポートする準備ができ、移行を積極的に推進する手助けもしてくれます。
技術的な観点から見ても、モデレーターやスーパーユーザーにベータテストを行ってもらうことで、ローンチ前に問題を発見できる可能性が格段に高まります。CM や管理チームだけでベータテストを行うと、彼らの日常業務のみがテストされることになります。
モデレーターやスーパーユーザーにベータテストを行ってもらうことで、ローンチ前に問題を発見できる可能性が格段に高まります。
移行データの厳格な QA
Discourse への移行を支援する際、よく目にするのは、QA プロセスを急いでしまうことです。これはプロセスの中で最も重要な部分の一つです。すべてのデータが正しい場所にあることを確認する必要があります。なぜなら、後から修正を試みるのは極めて困難であり、しばしば破壊的であり、ユーザーにとって非常に不快感を与えるからです。
移行後に検証すべきデータのチェックリストを作成しましょう。カテゴリとサブカテゴリは期待通りに整理されていますか？非公開エリアは隠れたままですか？画像や添付ファイルは正しく移行されましたか？コードの書式設定は正しく保たれていますか？ここでは、移行前のチェックリストの優れた例 をご紹介します。
QA はプロセスの中で最も重要な部分の一つです。急いで終わらせないでください。移行後に検証すべきデータのチェックリストを作成しましょう。
参入障壁の先回り
Discourse におけるユーザーアイデンティティの概念（およびアカウントをリンクさせる主要な方法）は、メールアドレスを中心に据えています。現代では人々が複数のメールアドレスを持っていることが多いため、ユーザーに最初にフォーラムに登録した際に使ったメールアドレスが何かを思い出させるのが良いでしょう。移行後にログインに問題が生じ、どのアドレスを使ったか忘れている、あるいはそのアドレスにアクセスできなくなった場合、その最初の困難が全体の体験を台無しにしてしまう可能性があります。
ユーザーに、最初にフォーラムに登録した際に使ったメールアドレスが何かを考えてもらうよう促しましょう。
ローンチ
金曜日にローンチしないでください！プレッシャーがかからないタイミングで切り替えを行いましょう。問題の解消、質問への回答、サポート、そして旗を振るために、あなたが利用可能である必要があります。可能であれば週の早い時期に行うことをお勧めします。落ち着くまでに数日かかることもあります。
人々が頻繁に利用する場所へのリンクを付けたトピックをグローバルにピン留めすると役立つことが多いです。CTA を明確にし、長々とした説明は避けましょう。このバナーはマーケティングのためではなく、案内のためのものであるべきです。
すべてのフィードバックを一つの場所に集約するために、専用のトピックを立ち上げることも検討してください。最初の数日の不満についてパニックにならないでください。メンバーが落ち着き、周囲に慣れるのを待ちましょう。「使い方」に関する質問や建設的なフィードバックには応答しますが、議論に巻き込まれたり、防衛的な言葉を使ったりしないでください。
バグ修正のための適切な期間を設定し、それを守るようにしてください。この時点で期待値の管理が不可欠ですので、実現しないかもしれないことを約束しないでください。
金曜日にローンチしないでください！プレッシャーがかからないタイミングで切り替えを行いましょう。
リダイレクトの検討
ほとんどの Discourse 移行スクリプトは 301 リダイレクトのリストを生成しますが、エンジニアと二重確認することをお勧めします。その後、Webmaster Tools を使ってローンチから数週間後に 404 エラーやその他の予期せぬ問題がないか監視できます。
ローンチから数週間後に 404 エラーやその他の問題がないか監視しましょう。