kintoneドメイン移行、アプリ・スペース移行の注意点
こんにちは。かりんこラボの坂本です。
kintone運用が始まってしまってから、全く別のkintone環境（別ドメイン）に住み替える、ということはなかなかないとは思いますが、最近この経験をしたので、備忘録も兼ね、下記2つの作業を実施する際に注意が必要なポイントなどを書いてみます。
現在のkintoneドメインから別のkintoneドメインへの引っ越し
同一kintoneドメイン内での旧アプリから新アプリへのデータ移行・コピー
【kintoneヘルプ】アプリを別のkintoneに移行するのページには手順が記載されていますが、すんなりとはいかない部分もありますので、検討されている方の参考になれば嬉しいです。
なお、今回の記事は、ヘルプの手順どおりアプリテンプレート＆レコードのデータを書き出し、アプリテンプレートから復元＆レコードデータ読み込みで実施した場合を前提に記載しています。
また、連携サービスやプラグインについても設定変更が必要になるはずですが、それぞれ対応方法が異なると思いますので、今回はその部分については触れません。
スペースの移行
アプリ単体ではなく、スペース毎まるっと引っ越し、またはコピーしたい場合です。
この場合は旧環境で「スペースをテンプレート化」して、新環境で復元する手順になります。
スペースのテンプレート化の手順は以下のヘルプの通りです。
スペースのテンプレート化の注意点は、テンプレートに含まれないデータがあるということです。ちなみに、アプリテンプレートについても含まれない設定があるので注意が必要です。詳細はヘルプを参照。
これらの含まれない設定・データはテンプレートから復元したあとに手動で設定が必要となります。
▼スレッドのコメントはテンプレートに含まれない ＆ 取得できるAPIもない
スペーステンプレートに含まれないデータ・設定については、手動でなんとか対応する必要がありますが、一番厄介なのは、スレッドのコメントです。今までのスレッドのコメントを含め、別環境に完全再現したいと思っている場合は、それはできません。
スレッドのコメントはテンプレートには含まれませんし、CSVファイルでのダウンロードやAPIで取得できる方法がありません。（2022/09時点）
そのため、コメント内容はブラウザの印刷機能でPDF化（添付ファイルは別途ダウンロード）する、またはWebページとしてダウンロードする等の対応が必要です。
もちろん、新しい環境にそのデータから復元はできないので、移行後スペースにそれらの手動で取得したデータを貼り付けて、参照はできるようにしておくくらいでしょうか。
▼スペースのテンプレートが作成できない場合がある
以下の場合、スペースのテンプレート作成ができないので、工夫が必要です。
【kintoneヘルプ】スペースをテンプレートする場合の注意
スレッドが10個を超える場合
→スレッドを消すしかない。スペース内アプリが20個を超える場合
→一旦スペース外アプリに移動し、アプリなしのスペーステンプレートを作成。アプリは別にアプリテンプレートを別に作成。それぞれを新環境で復元した後に、アプリをスペースに移動する。スペース内アプリのルックアップフィールドまたは関連レコード一覧フィールドが、スペースに所属しないアプリのフィールドを参照している場合
→スペースに所属しないアプリを暫定でスペース内に持ってきてテンプレートを作る、またはスペース内アプリを修正してスペース外アプリとの関連を解除する。
2021年11月のアップデートで、アプリのスペース内外への移動ができるようになったので、スレッドの個数制限以外は、格段に対応がしやすくなりました。
アプリのデータ移行ができないもの
下記の２つともレコードのデータ書き出しやAPIでデータを取得する方法がありません。（2022/09時点）
▼変更履歴
新しい環境・アプリは新規に生まれたものなので、変更履歴はそこから始まります。
以前の変更履歴が移行できないのは仕方がない話ではありますが、変更履歴はどのタイミングでデータが変わったか確認するために、重要になることがあります。
証跡として変更履歴が重要な意味を持つ場合は、古い環境を残すしかありません。
▼プロセス管理のステータスの履歴
こちらも証跡として重要になるものです。
こちらについても、証跡を残しておく必要がある場合は、古い環境を残すか、1レコードずつ印刷して残す（ステータスの履歴を印刷するにチェック）対応になります。
アプリのデータ移行時に工夫が必要なこと
▼添付ファイル
添付ファイルは、「レコードのデータを書き出し」では書き出すことができません。
「cli-kintone」を使って、ダウンロード・アップロードをする必要があります。
（「ファイルダウンロード」と「ファイルアップロード」のREST APIがありますが、cli-kintoneがおすすめです。）
添付ファイルがあるアプリは、CSVインポートだけでは手に負えないため、どのみちcli-kintoneを使用しないといけないのであれば、添付ファイルだけでなく、データもcli-kintoneを使用して一度に移行する方が良いと思います。
▼ルックアップフィールド
ルックアップフィールドがある場合、関連付けしているアプリに先にデータが投入されている必要があります。（ルックアップしているデータがないと読み込み時にエラーになります）
お互いにルックアップしあっているアプリなどは、１回で投入することはできません。
そのため、まずは、ルックアップフィールドは読み込み対象外とし、それ以外のフィールドのみでデータ投入。どちらのアプリもデータが投入された後に、再度ルックアップフィールドを更新する、という手順になります。
また、ルックアップの設定で「コピー元のフィールド」に指定したフィールドは、関連付けしているアプリの方で「値の重複を禁止する」にチェックが入っていなければいけません。（値に重複があると取得する値を判定できないため）
入っていないと、ファイルから読み込みするときの画面に「コピー元のフィールドに値の重複の禁止を設定していないルックアップフィールドは、表示されません。」のメッセージが表示され、ルックアップフィールドを更新することができません。
関連付けしているアプリのフィールドを「重複禁止」にできれば良いのですが、どうしてもできない場合は、そのルックアップフィールドだけ後で手作業で更新するしかありません。
▼レコード番号・アプリID ・スペースID・スレッドID / レコードのリンクやその他リンク
レコード番号は、新しいアプリのレコード番号にそのままは移行できません。
レコード番号は自動で割り振られるものなので、必ずしも、データ移行前のレコード番号と移行後のレコード番号が同じになるとは限りません。また、アプリIDやスペースIDなども移行前と後では違うものになるはずです。
これらが、移行前後で違うものになることで問題なのは、移行データの中にレコードのリンク（レコードのURL）やスペースやスレッド等へのリンクが含まれている場合です。
レコードのリンクやスペースへのリンクは、アプリIDやスペースID等が含まれているので、これらを新しい番号に書き換える必要があります。（kintoneドメインが別ドメインになる場合は、サブドメイン名も修正が必要）
たとえばレコードのリンクについては、以下のようにアプリIDとレコード番号がリンクの一部分として使用されています。
https://サブドメイン名.cybozu.com/k/アプリID/show#record=レコード番号
データ移行前にアプリを作成するはずなので、移行データに含まれるアプリIDは事前に書き換えておくことができますが、レコード番号については、データを投入しないことには何番になるのかわからないため、事前に新レコード番号に書き換えるのが難しいケースが出てきます。
そのため、まずはレコードを投入（新レコード番号が割り振られる）し、その後、再度リンク部分を新レコード番号に修正するというように、2回に分けて更新が必要になります。
▼ユーザー選択、組織選択、グループ選択、作成者、更新者フィールド
作成者、更新者、ユーザー選択フィールドに、すでにkintoneを使用しなくなったユーザー（削除もしくは停止中）が含まれている場合、ファイル読み込みでエラーになってしまいます。組織選択、グループ選択フィールドについても同様です。
元通りにデータ復元したい場合は、一旦その削除・使用停止してしまったユーザーや組織等を復活（kintone使用中状態）させてからデータ読み込みする必要があります。
ユーザーについては、単純に削除されたユーザー数分のアカウントを増やすと課金されてしまいますので、注意が必要です。
▼プロセス管理の現在のステータスおよび作業者
プロセス管理のステータスと作業者はレコードのデータとしては書き出しできますが、データの読み込みでは更新することができません。
ただし、kintoneのREST APIで「レコードのステータス更新」がありますので、更新プログラムを作成できれば、元データを使って新しいアプリのステータスを更新することが可能です。
もし、プログラムを書くのは無理ということでしたら、手動でステータスを更新しないといけません。
▼コメント
レコードのコメントは、データとして書き出しができません。
こちらについては、「レコードコメントの一括取得」のREST APIを使ってデータを取得することが可能です。また、更新については、「レコードコメント投稿」のREST APIがありますので、プログラムを作成できれば、データ取得とある程度の復元が可能です。
コメントをREST APIで投稿して復元する場合のポイントとしては、日時は復元時の日時になり、かつ投稿者も復元した人またはAdministratorになるので、100%同じ復元はできません。そのため、復元するコメント内に元データの投稿者や日時を含めておくなどの工夫が必要になります。
▼定期レポート
レコードは復元できますが、定期レポートは復元されません。
復元はできませんが、定期レポートはCSV形式でダウンロードすることは可能ですので、忘れずにダウンロードしておきましょう。
まとめ
ヘルプの手順どおりに実施すれば、簡単にドメイン移行・アプリのデータ移行ができそうな印象がありますが、条件によってはかなり面倒な作業になります。
レコードが多かったり、アクセス権の設定が複雑だったり、プロセス管理、コメントなどkintoneを活用しているほど、大変になると思います。
場当たり的なやり方では、頻繁につまずくことになりますので、移行対象・移行順番などを決めた手順を作成し、移行を進めることをおすすめします。
kintone全般の知識・総合力が試されるような状況になりますが、kintoneヘルプやkintone関係の皆さんが発信されている情報が助けになります。ぜひ積極的に活用していってみてください。