こんな記事をQiitaに書いて良いのかという疑問がありつつも。。
概要
Qiita::Teamは記事をjson形式でエクスポート出来る機能があります。
その機能で落としてきたファイルを読み込んでesa.ioのAPIを叩いて登録します。
詳細
カテゴリ
本当はカテゴリマッピングとかやりたいところですが、それなりにドキュメント量があると無理ゲーなので/qiitaというトップカテゴリを作って、その下に時系列カテゴリで切って雑にぶち込んでます。移行と言っていますが、引き続き使われる記事は無しとして、ほぼアーカイブとして移行する考え方です。こういうところにこそ機械学習を使って良い感じの自動分類をやりたいですね。。
ユーザー
ユーザーマッピングは少ない労力で出来るじゃん！とも考えたのですが、長い間使ってると人の入れ替わりとかもあり、厳密にマッピングする意味が無さそうだったので、投稿ユーザーはesabotに集約して最低限の検索ビリティを確保（titleにqiitaのid文字列を入れる）するに留めています。
タグ
タグは完全にカオスだったので、全部捨ててやり直したい衝動にかられましたが、前述の通り人の入れ替わりを考慮するとタグ候補が見える事はコンテキストの把握につながるよなーと考えて、取り敢えず全部インポートする事にしました。
画像やファイル
こちらの記事を参考にしてファイルは別で取得してアーカイブしておく事にしました。そもそも社内の運用ルールとして、ファイルはQiita::Teamではなくファイルサーバー管理（記事内部からファイルパスへリンクする）する方針だったので、ここはあまり慎重に考えずサクッとやった感じです。
ポエム
「なんで移行したのか？」という事ですが、上に書いたトピックにも関連しますがタグ管理が結構限界きてるなーというのが理由です。ある程度カテゴライズしてカチっとまとめつつ、wikiみたいな感じでスナップショットというかある時点での情報を切り出して体系的にまとめる、というのがQiita::Teamだと思うように実現できなかったので移行しました。一言で表すと「フローの取り扱いは良いが、ストックの取り扱いがイマイチ」というような感じです。とは言えこの部分は永遠に悩める部分なので他社さんの方法も教えてほしいところです。
コード
気になるところ
コメントPOSTは本文のidを引数に取るので本当はブロッキングしなきゃならないのだけど、どうせsleepするから大丈夫だろうという雑実装です。