LINEWORKSの運用業務を行なっております。
APIを利用したユーザーのテナント移行時における連絡先の挙動確認のメモになります。
APIに関しては、Excelマクロに仕込んで検証しています。

※調査は、2021年の７月〜９月にかけて実施しており、それ以降のバージョンでは改善されている可能性もあります。

そもそもの経緯

APIを利用したテナント移行において、メンバーが登録した連絡先のデータが、テナント移行後も問題なく利用できるかの確認を行なっていた。
公開範囲に自身と自身以外のメンバーを設定している場合、テナント移行後に対象の連絡先を参照できない事象を確認した。（前提として、自身以外に公開範囲に設定できるユーザーは、同じテナントに所属するユーザーのみ）

アドレス帳のAPIを利用してテナント移行前後のデータを確認

LINEWORKSのAPIを利用して、テナント移行前後のアドレス帳のデータを取得します。

「顧客/取引先の連絡先リストの照会」で、個々のアドレス帳の連絡先に採番されたresourceId(連絡先のリソースID)を取得します。
「顧客/取引先の連絡先の照会」で、取得したresourceIdを元に連絡先ごとの詳細情報を取得します。

テストデータ（プロパティ一部抜粋）

※リソースデータは仮値（実際はちょい長文字列）です。配列となる「sharedMembers」はプロパティは、別途分けて記載しています。

resourceId	open	masterUserId
1	false	test1@testlineworks.com
2	false	test1@testlineworks.com

resourceId	sharedMembers[].id	sharedMembers[].type
1	test1@testlineworks.com	USER
2	test1@testlineworks.com	USER
2	test2@testlineworks.com	USER
2	soshiki@testlineworks.com	ORGUNT

プロパティ	タイプ	説明
resourceId	String	連絡先のリソースID
open	Boolean	公開範囲(true：すべてのメンバー/false：メンバー指定)
masterUserId	String	連絡先の管理者ユーザー ID
sharedMembers[]	List	公開範囲がfalseの場合の共有メンバーリスト
sharedMembers[].id	String	連絡先を共有するユーザー ID又は組織ID
sharedMembers[].type	String	USER：メンバー/ORGUNT：組織

ざっくり↑のようなテストデータを用意しました。
resourceId1は、自分のみが参照できるアドレス帳の連絡先で、
resourceId2は、自分とtest2@testlineworks.comと組織（soshiki@testlineworks.com組織アドレスとします)が参照できる連絡先として登録しています。
※sharedMembersの設定値を参照

テナント移行

test1@testlineworks.comとtest2@testlineworks.comの両ユーザーを同じ別テナントにAPI（サテライトオフィスのLINEWORKS連携)を用いて移動させます。ついでにユーザーIDも変更されるものとします。
なお、組織IDsoshiki@testlineworks.comは変わらないものとします。
具体的には以下の通りです。

変更前ユーザーID	変更後ユーザーID
test1@testlineworks.com	test1@testlineworks2.com
test2@testlineworks.com	test1@testlineworks2.com

結果

移行後のテナントAでAPIを用いて連絡先を取得

resourceId	open	masterUserId
2	false

resourceId	sharedMembers[].id	sharedMembers[].type
2	test1@testlineworks2.com	USER
2	test2@testlineworks2.com	USER
2	soshiki@testlineworks.com	ORGUNT

⇨自身以外を公開範囲に含めていた連絡先は、テナント移行しない。
⇨だが、ユーザーIDは移行先のユーザーIDに置き換えられる。
⇨連絡先の管理者ユーザーID(masterUserId)が外れる。
　masterUserIdはAPIドキュメントだと必須項目となっているので、一部データがおかしくなっている？
⇨soshiki@testlineworks.comに所属しているメンバーは、引き続き連絡先を参照する事が可能。
⇨テナント移行したtest1@testlineworks2.com及びtest2@testlineworks2.comはテナント移行しているため、参照不可。

移行後のテナントBでAPIを用いて連絡先を取得

resourceId	open	masterUserId
1	false	test1@testlineworks2.com

resourceId	sharedMembers[].id	sharedMembers[].type
1	test1@testlineworks2.com	USER

⇨自身のみを公開範囲に含めていた連絡先は、連絡先含めてテナント移行される。
⇨masterUserIdやsharedMembers[].idも移行先のユーザーIDに置き換えられる。
⇨移行後のテナントで登録した連絡先を参照する事が可能。
⇨resourceNo2の方は移行前のテナントに連絡先として残ったままとなっているため、参照不可。

　APIを利用したテナント移行に伴うアドレス帳の懸念点

公開範囲をメンバー指定で、自分と自分以外の誰かを設定していた場合、移行先テナントの連絡先に移行前テナントで登録していた連絡先が移行しない。
一部データがおかしな状態で、移行前テナントに残存する事になる。
sharedMembersに設定されている移行前テナントのユーザーは引き続き参照が可能。

　解決策

テナント移行前の処理

移行対象者がmasterUserId且つ、公開範囲がメンバー指定で、対象者以外も指定されている連絡先をAPIで抽出しておく。
（指定されているメンバーも同じ移行先テナントに移行する前提で）①で取得した情報を利用して、連絡先登録用の情報を作り込む。（登録APIの利用を想定）この時、masterUserIdやsharedMembersには、移行後のユーザーIDを設定しておく。

※仮に指定されているメンバーが異なる移行先テナントや移行前テナントに留まる場合は、sharedMembersの対象から該当のユーザーIDを削除しておく。

テナント移行後の処理

[テナント移行前の処理]で準備した登録用の情報を用いて、登録APIを実行する。（ことで移行先にも同様の連絡先情報を作成する。）
多分問題ないけど目視でも1件くらい確認しておく。それか取得用APIを用いてデータを取得して想定通り登録されているか確認する。

所感

本当は、各ユーザーに手動でお願いしたいところなんだけど、連絡先を１００や２００登録していて、且つ公開範囲に自分以外のユーザーも指定している連絡先ばかりの場合、なかなかお願いしにくい。
公開範囲に他のユーザーIDを指定するアクションはAPIか、各ユーザーの画面上でしか行えない。CSVやExcelの取り込みなどでは対応できない。
基本同じテナントにいるユーザーとしか連絡先を共有できないので、連絡先を他のユーザーに公開している場合、テナント移行時は、一時的にでもテナントが別々になってしまうのが事象の問題点なんだろうなと……思っています。
いっそのこと公開範囲は全てとするか、自分以外は設定しないでくれって周知しておいた方が幸せになれそう。