前の記事では、SalesforceとZohoでAPI名の考え方がどう違うかを整理しました。今回はその続きとして、実際にSalesforceからZoho CRMへデータを移行するときに、この仕様の違いが原因でつまずきやすいポイントをまとめます。具体的なAPI名には触れず、考え方として押さえておきたいことを中心に書きます。

まず、移行元と移行先の項目を突き合わせる

移行で最初にやるべきなのは、移行元の項目と移行先の項目を一つずつ対応づける作業です。地味ですが、ここを丁寧にやるかどうかで、あとの手戻りの量が大きく変わります。

このとき、名前が似ているからといって同じ項目だと決めつけないことが大事です。前の記事でも触れたとおり、名前と型は別の情報です。名前がそっくりでも、片方はテキスト、もう片方は数式、ということが普通にあります。名前だけで対応づけると、いざ移行したときに値が入らない、という事態を招きます。

対応表を作るときは、名前だけでなく、型と役割もセットで並べて確認するのがおすすめです。少し手間はかかりますが、この一手間が移行全体の精度を左右します。

計算される項目には、そのままでは値が入らない

移行で最もはまりやすいのが、計算系の項目です。

移行元のデータには、金額や単価など、計算された結果の数値がしっかり入っています。ところが移行先で同じ役割の項目が数式や集計として作られていると、その項目は自分で計算して値を出す仕組みになっているため、こちらから数値を流し込んでも反映されません。取り込んでも、移行先が独自に計算した値に置き換わってしまいます。

これに気づかず移行を進めると、元のデータとは違う数字が入ってしまい、あとで数字が合わないと騒ぎになります。対策としては、移行先のどの項目が計算系なのかを事前に洗い出しておくことです。そのうえで、元の数値をそのまま残したいのであれば、計算系ではなく通常の数値項目として作り直す判断が必要になります。計算に任せてよいのか、元の値を保持したいのか、項目ごとに方針を決めておくと迷いません。

参照関係は、移行の順番が命

CRMのデータは、単独で完結しているわけではありません。顧客と案件、案件と商品といったように、あるデータが別のデータを参照している構造になっています。この参照関係の移行が、順番を間違えると総崩れになります。

参照先のデータがまだ移行先に存在しないうちに、参照する側を先に移行してしまうと、紐付けができず、そこが空のまま取り込まれてしまいます。しかも、あとから参照先を移行しても、先に入れたデータの紐付けが自動で埋まることはありません。

そのため、どのデータがどのデータに依存しているかを整理し、依存されている側から先に移行する順番を組む必要があります。参照が入り組んでいる場合は、いったん参照なしで本体を入れておき、参照先がそろってから、あらためて参照だけを後追いで埋める、という二段構えの進め方が有効です。

参照の紐付けには、共通の目印を用意しておく

参照関係を移行先で正しく再現するには、移行先のデータ同士を突き合わせるための共通の目印が要ります。

移行元のデータには、それぞれを一意に識別する固有の値があります。この値を、移行先の各データにも保持させておくと、参照する側と参照される側を、その値をキーにして正確に紐付けられます。逆に、この目印を用意していないと、名前で照合するしかなくなり、同名のデータがあると誤って紐付いたり、表記が少しでも違うと紐付かなかったりします。

移行の初期段階で、移行元の識別値を移行先にも持たせる項目を用意しておくこと。これが、後追いの紐付けをスムーズにする土台になります。

ユーザーや担当者の移行はひと工夫要る

担当者や作成者、所有者といった、人を指す項目も注意が要ります。

移行元のデータでは、これらの項目に、人を識別するための内部的な値が入っています。この値は移行元の中だけで通用するもので、移行先はその値を知りません。そのまま流し込んでも、誰のことか分からず紐付きません。

対策としては、その内部的な値を、移行先でも通用する情報に変換してから移行することです。移行先が人を照合する方法にあわせて、氏名やメールアドレスなど、突き合わせ可能な値に置き換えておく必要があります。どの情報で照合するのが確実かは、移行先の項目の作り方によって変わるので、そこを事前に確認してから変換方針を決めると失敗しません。

選択肢のずれと、日付や時刻の形式にも注意

細かいところですが、取りこぼしやすい点を二つ挙げておきます。

一つは選択肢のずれです。選択式の項目では、移行元にあった選択肢が移行先にまだ登録されていないと、その値の行が取り込めないことがあります。移行時に未登録の値を自動で追加する設定を使うか、あらかじめ選択肢をそろえておくかの、どちらかの手当てが必要です。表記のわずかな違いでも別の値として扱われるので、表記の統一も忘れずに。

もう一つは日付や時刻の形式です。移行元と移行先で、日付や時刻の書き方の作法が違うことがあります。形式が合っていないと、その項目だけエラーになったり、うまく取り込めなかったりします。時刻については、地域による時差の扱いも関わってくるので、そのまま入れると時間がずれることもあります。移行先が受け付ける形式を確認して、必要なら変換してから取り込むのが確実です。

いきなり全件ではなく、まず一件

最後に、進め方の話です。

どれだけ入念に準備しても、実際に取り込んでみないと分からないことは必ず出てきます。だからこそ、いきなり全件を移行するのではなく、まず一件だけ取り込んで、想定どおりに入るかを確認する。この一手間を挟むだけで、大きな事故を防げます。

一件で、値が正しく入っているか、参照が紐付いているか、計算系の項目がおかしくなっていないかを確かめる。問題がなければ全件に進む。遠回りに見えて、これが結局いちばん速い進め方だと、移行を重ねるほど実感しています。

API名の仕様の違いは、知らないと移行の落とし穴になりますが、あらかじめ押さえておけば、むしろ計画的に進めるための地図になります。移行を控えている方の参考になればうれしいです。