先代契約のSaaS解約前にやるべきデータエクスポート手順

先代の代からずっと使っている会計SaaS、顧客管理SaaS、あるいは請求書発行のクラウドサービス。「そろそろ料金プランが会社の規模に合わなくなってきた」「もっと使いやすい別のサービスに乗り換えたい」と思っても、二代目・三代目の経営者が最初にぶつかる壁は、たいてい契約書の解約条項ではなく「今のサービスの中にあるデータを、どうやって外に出すか」という技術的な手順です。

結論を先に言います。SaaSを解約する前に必ずやるべきことは、契約書・利用規約でデータ返還と削除の条件を確認し、CSVやPDFなど汎用形式で全データをエクスポートし、そのバックアップを最低でも次のサービスへの移行が完了するまで安全な場所に保管しておく、という3ステップです。この順番を間違えると、解約ボタンを押した瞬間に十年分の顧客データや取引履歴が復元不能になるリスクがあります。

この記事は、こんな状況にある人のために書いています。先代が契約した会計SaaSや顧客管理システムを何年も見直さずに使い続けてきて、そろそろ乗り換えを検討しているものの、ITの担当者が社内にいない。解約ボタンはどこにあるか分かるが、その前に何を確認すべきかが分からない。ベンダーの営業担当と先代との人間関係もあるので、強引に聞き出すのも気が引ける。そんな二代目・三代目社長に向けた、実務レベルのチェックリストです。

なぜ「解約前のデータエクスポート」が承継社長の盲点になるのか

株式や不動産の承継であれば、税理士や司法書士という専門家が必ず間に入ります。相続税の計算も、登記の変更も、誰に相談すればいいかが明確です。しかし会計SaaSや顧客管理システムの契約となると、相談先が誰なのか分からないという声を非常によく聞きます。先代が契約したベンダーの担当者は、良くも悪くも「会社のことをよく知っている人」という位置づけで、対等な取引相手というよりも半ば身内のような扱いになっていることが少なくありません。

その結果、契約内容そのものを見直す機会がないままに何年も自動更新が続き、いざ乗り換えを検討する段になって、契約書がどこにあるかも分からない、データがどういう形式で入っているのかも分からない、という状態になっているケースが多いのです。士業には相談先があるのに、システムには相談先がいない。この非対称性が、承継後のシステム判断を先送りにさせる最大の要因になっています。

解約前にやるべきことの全体像

まず全体の流れを整理します。

この7手順のうち、最初の2つが特に見落とされがちです。多くの経営者は「エクスポートすればいいんでしょう」と技術的な作業だけを考えがちですが、実際にはその前段にある契約条件の確認が抜けていると、エクスポートする時間そのものが確保できないまま契約が終了してしまうことがあります。

ステップ1: 契約書・利用規約の「データ返還」条項を確認する

まず手元にある契約書、あるいはベンダーのウェブサイトに掲載されている利用規約を確認してください。中小企業のSaaS利用契約では、解約時のデータの取り扱いについて明文化されていないことも珍しくありませんが、規定がある場合は次のような項目が書かれているはずです。

• 解約後、何日間データが保存されるか（保存期間）
• 保存期間中にデータをダウンロードする手段が用意されているか
• データの提供形式（CSV、PDF、専用フォーマットなど）
• データ提供が有償か無償か
• 保存期間終了後のデータ削除の扱い

経済産業省とIPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」は、ユーザー企業とITベンダーの間で発生しがちな契約トラブルを防ぐために作られた指針で、契約終了時のデータ返還や保存期間の取り決めについても言及されています。SaaSやパッケージソフトの活用を想定した追補版も公開されているため、自社の契約書に同種の条項があるかどうかを照らし合わせる際の参考になります（IPA「情報システム・モデル取引・契約書」）。

法律事務所の解説でも、契約終了後にすぐデータを廃棄するのではなく、一定期間はベンダー側にデータを保管してもらい、その期間内に利用者側がデータを移行できるようにする規定を設けることが望ましいとされています。データの提供方法としては、サービス事業者のサーバーから利用者が直接ダウンロードする方法と、記録媒体で受け取る方法の2種類が一般的で、どちらの費用を誰が負担するかも契約上の論点になります（BUSINESS LAWYERS「事業継続のためにチェックすべきクラウドサービス（SaaS）利用契約の4つのポイント」）。

つまり、解約を申し出る前に「保存期間は何日あるのか」「ダウンロードの手段は自分で行えるのか、それとも申請が必要なのか」の2点を必ず確認する必要があります。契約書に記載がない、あるいは古い契約で条項自体が存在しない場合は、解約を申し出る際にベンダーのサポート窓口へ直接問い合わせて、書面かメールで回答をもらっておくことをお勧めします。口頭でのやり取りだけでは、後になって「言った言わない」の水掛け論になりかねません。

ステップ2: 実際の保存期間はサービスごとにまったく違う

「解約したらすぐにデータが消える」と思い込んでいる経営者も多いのですが、実際の運用はサービスごとに大きく異なります。一例として、グループウェアで知られるサイボウズは、通常は解約日の翌日から30日後にデータを削除する運用ですが、利用者からの申請があれば保存期間を解約終了月から6か月後の末日まで延長できる仕組みを案内しています（サイボウズ「解約後のデータ保存期限延長について」）。

一方で、通信インフラ系のクラウドサービスでは「解約時にはデータが削除されて復元できない状態となる」という運用を明記しているケースもあります。つまり「解約=即削除」のサービスと「解約後も一定期間は残る」サービスの両方が実在しており、これはサービスごとの個別ルールであって、業界標準のようなものは存在しません。

契約前に詳細を確認し、必要に応じてバックアップを取得することが重要である。

これは複数のクラウドサービス事業者の契約条件を比較した調査でも指摘されている点です（assured.jp「クラウドサービス事業者による契約終了後のデータ取り扱い実態調査レポート」）。先代の代から使っているサービスであればあるほど、「昔からあるから大丈夫だろう」という思い込みが強くなりがちですが、保存期間の運用は事業者によって全く異なるという前提に立ち、必ず個別に確認してから動くべきです。

ステップ3: エクスポートすべきデータの棚卸しをする

多くのSaaSでは管理画面の中に「エクスポート」や「データダウンロード」というメニューが用意されています。ただし、経営者自身がそのメニューの存在を知らない、あるいは古参社員だけが使い方を知っていて他の誰にも共有されていない、というケースが実際に多く見られます。解約を検討する前に、まず次のようなデータが自社の契約サービスにどれだけ蓄積されているかを棚卸ししてください。

• 顧客・取引先のマスタデータ（名称、住所、担当者名、連絡先）
• 取引履歴・受発注データ・見積書・請求書
• 会計データ（仕訳、勘定科目、決算関連の帳簿）
• 従業員情報・勤怠データ・給与計算の履歴
• 添付ファイル（契約書PDF、図面、画像など）
• メールや商談履歴などのコミュニケーションログ

会計ソフトの分野では、CSV形式でのデータ入出力が業界標準的な手段として広く使われています。例えばクラウド会計ソフトでは、既存のソフトから出力した仕訳データをCSV形式でダウンロードし、移行先ソフトのフォーマットに合わせて編集してから取り込む、という手順が一般的です（マネーフォワード クラウド会計「他社ソフトデータの移行」）。CSVはテキストベースでサイズが小さく、ほぼすべての表計算ソフトやデータベースソフトで開くことができるため、特定のベンダーに依存しない汎用フォーマットとして最も無難な選択肢です。

ここで大切なのは、「エクスポートできる項目」と「実際に業務で使っている項目」が一致しているかを必ず確認することです。管理画面のエクスポート機能が主要な項目しか出力してくれず、カスタムフィールドや添付ファイルが漏れる、というのはよくある落とし穴です。

データポータビリティという考え方を知っておく

ここで一度、データポータビリティという概念を整理しておきます。データポータビリティとは、あるサービスに預けたデータを、利用者自身の意思でいつでも取り出し、別のサービスや自社のシステムへ持ち出せる状態を指す言葉です。単に「エクスポート機能がある」というだけでなく、「取り出したデータが実際に別の場所で使える形式になっているか」までを含めて評価される概念です。

例えば、CSVで出力できても、文字コードが特殊で他のソフトで文字化けする、あるいは項目名が独自の略語のままで意味が分からない、という状態では、データポータビリティが実質的に確保されているとは言えません。逆に、標準的な文字コードと分かりやすい項目名でエクスポートでき、他のサービスでもそのまま読み込める状態であれば、データポータビリティが高いと言えます。

承継のタイミングでベンダーとの関係を見直す際、この「データポータビリティがどの程度確保されているか」を確認しておくことは、今後どのサービスと付き合っていくかを判断する上での重要な軸になります。ポータビリティが低い、つまりデータを取り出す手段がほとんど用意されていないサービスは、乗り換えのたびに大きな手間とリスクを伴うことになり、結果として「抜けられない」状態を長期化させてしまいます。

ステップ4: エクスポートしたデータを検証する

データをダウンロードしたら、そこで安心してすぐに解約手続きに進んではいけません。ダウンロードしたファイルを実際に開いて、次の点を確認してください。

1. レコード数が管理画面で表示されている件数と一致しているか
2. 直近のデータ（今月分の取引や請求書など)が含まれているか
3. 文字化けや文字欠けが発生していないか
4. 添付ファイルやリンク先のファイルも別途取得できているか
5. 削除済み・アーカイブ済みのデータも必要であれば含まれているか

特に4番目と5番目は見落とされがちです。エクスポート機能は「現在アクティブなデータ」のみを対象にしていることが多く、過去にアーカイブした取引先や、削除フラグが立っているだけでまだ実体としては残っているデータは対象外になっている場合があります。長年の取引で「もう動いていない取引先だが記録として残しておきたい」というデータがある会社ほど、この確認は重要になります。

ステップ5: バックアップは複数の場所に、複数の形式で残す

エクスポートしたデータは、1つのUSBメモリやパソコンのローカルフォルダだけに保存するのは避けてください。理想的には次の3系統で保管することをお勧めします。

• クラウドストレージ（社内で契約しているファイル共有サービスなど）
• 外部記憶媒体（外付けHDDやNASなど、ネットから切り離しても読める手段）
• 紙またはPDFでの主要データの控え(会計データや契約関連は特に)

これは「システムが壊れたときのための保険」という発想と同じです。承継後の経営でよく起きる問題の一つに、システムの全体像を誰も把握していないまま突然のトラブルに直面するというパターンがあります。日頃から社内で使っているシステムとその契約状況、データの保管場所を一覧にした管理台帳のような形で残しておくと、こうした解約・移行の場面で慌てずに対応できます。

ステップ6: 移行先での取り込みテストを、解約前に必ず行う

エクスポートとバックアップが完了したら、次に行うべきは「移行先のシステムで、実際にそのデータが正しく取り込めるか」のテストです。ここを飛ばして本番データを一気に移行し、そのまま旧サービスを解約してしまうと、フォーマットの不一致や項目のズレが解約後に発覚したときに、確認のしようがなくなります。

具体的には、次のような手順を踏むことをお勧めします。

• まず少量のサンプルデータ（数件〜数十件）だけを移行先に取り込んでみる
• 取り込んだデータの表示や集計が、元のシステムと一致するか比較する
• 問題がなければ、段階的に全データの移行を進める
• 全データの移行が完了し、業務で実際に使える状態になったことを確認する
• 一定期間、旧システムと新システムを並行稼働させて差異がないか確認する

この並行稼働の期間は、会社の規模や業務の複雑さによって異なりますが、少なくとも1回の決算や請求サイクルを旧システムのデータと突き合わせて確認できるまでは、旧サービスを解約しないほうが安全です。

ステップ7: すべて確認できてから、解約を申し出る

ここまでの手順を終えて初めて、解約の申し出をします。解約を申し出るタイミングでも、次の点を確認しておくと安心です。

• 解約の申し出から実際にサービスが停止するまでの期間(即時か、当月末か、翌月末かなど)
• 解約後もデータへアクセスできる猶予期間があるか
• 猶予期間中に追加でダウンロードが必要になった場合の連絡先
• 解約に伴う違約金や、契約期間の縛りが残っていないか

先代の代からの付き合いがあるベンダーだと、担当者との人間関係を気にして「言い出しにくい」という声もよく聞きます。しかし、解約の申し出自体は契約上の権利であり、感情の問題と手続きの問題は分けて考えるべきです。角を立てずに進めるコツは、「不満があるから辞める」という言い方ではなく、「事業の成長に合わせて体制を見直している」という前向きな理由で伝えることです。長年世話になった担当者への感謝を伝えつつ、事務的な手続きは淡々と進める、という姿勢が結果的に関係を保ちながら移行を完了させる近道になります。

見落としやすい5つの落とし穴

ここまでの手順をきちんと踏んでも、実際の現場では次のような落とし穴にはまりやすいので、あらかじめ意識しておいてください。

落とし穴1: エクスポート機能そのものが用意されていない、または限定的 古いオンプレミス型のシステムから移行してきたレガシーシステム的なSaaSの場合、そもそも汎用形式でのエクスポート機能が用意されていないことがあります。この場合はベンダーに直接データ提供を依頼するか、契約上のデータ返還義務を根拠に交渉する必要があります。ベンダーが「うちでしか対応できない」という姿勢を見せた場合の確認事項は、先代の代からの開発会社に「うちでしか直せません」と言われたときに確認する契約書の項目にまとめています。他社への乗り換え前に確認しておくべき点はデータをエクスポートできるか、古参ベンダーからの乗り換え前に確認すべきことも参考になります。

落とし穴2: 担当者の異動・退職でエクスポート方法が分からなくなっている 社内でそのSaaSの操作方法を知っているのが、既に退職した社員や高齢のベテラン社員一人だけ、という状態は中小企業では非常によくあります。解約を検討し始めたら、まず「誰がこのシステムの操作方法を知っているか」を確認してください。

落とし穴3: 無料プランやサポート終了間際で機能制限がかかっている 契約プランのダウングレードや、サービス自体のEOL（サポート終了）が近づいている場合、エクスポート機能に制限がかかっていたり、サポートが縮小されていたりすることがあります。解約や乗り換えを検討する段階になった時点で、既に手遅れに近い状況になっていないかを早めに確認する必要があります。

落とし穴4: 複数のSaaSにデータが分散していて、どこに何があるか分からない 会計、顧客管理、勤怠、請求書発行など、それぞれ別のベンダーのSaaSを使っている場合、一つのサービスを解約しようとした際に、実は別のサービスと連携していてデータの一部がそちらにも保存されている、というケースがあります。事前の棚卸しの段階で、連携している他のサービスの有無も確認してください。

落とし穴5: 「念のため」でエクスポートを後回しにして期限が過ぎる 最も多い失敗は、忙しさを理由にエクスポート作業を後回しにして、ベンダーが案内していた保存期間を過ぎてしまうことです。解約の意思が固まった時点で、社内カレンダーにエクスポート期限を明記し、複数人でリマインドし合う体制を作ることをお勧めします。

ケースで考える: 先代契約の会計SaaSを乗り換えるとき

もう少し具体的な場面で考えてみます。例えば、先代の代から15年近く同じ会計SaaSを使い続けている製造業の会社があるとします。二代目社長が代替わり後に決算業務を見て驚くのは、経理担当のベテラン社員が独自のExcelマクロを組んで会計SaaSの出力データを加工しており、そのマクロの仕組みを本人しか把握していない、という状況です。

このようなケースでは、会計SaaS本体のデータエクスポートだけでなく、その後工程で使われているExcelマクロやテンプレートも含めて「業務の一式」として棚卸しする必要があります。SaaS側のCSVエクスポートがうまくいっても、後工程のマクロが新しいフォーマットに対応していなければ、結局は経理担当者の手作業が増えてしまい、乗り換えの効果が薄れてしまいます。

同様に、顧客管理SaaSを乗り換える場合も、営業担当者が個別にスプレッドシートで管理している商談メモや、名刺管理アプリと連携している設定など、SaaS本体の外側にある「隠れた業務データ」が意外と多く存在します。解約前のデータエクスポートを検討する際は、SaaS本体だけでなく、その周辺で使われているファイルや連携設定まで含めて確認範囲を広げておくことをお勧めします。

一社にすべて任せず、複数のベンダーと付き合う視点

先代の代からの付き合いで、会計・顧客管理・請求書発行など複数の業務システムを、実質的に一社のベンダーにすべて任せてきたという会社も少なくありません。担当者とのやり取りが一本化されて楽だった一方で、いざ一部のシステムだけを乗り換えようとすると、他のシステムとの連携が切れてしまう、あるいは「セットでしか契約できない」と言われてしまう、というケースがあります。

こうした状況を避けるための考え方がマルチベンダーです。複数の業務領域を、それぞれ得意なベンダーに分散して依頼する体制にしておけば、一つのサービスを見直す際に他の業務全体が影響を受けるリスクを下げられます。もちろん、複数ベンダーとの契約管理には相応の手間がかかりますが、今回のようにデータエクスポートを検討する場面では、依存先が一社に集中していないことが結果的に交渉力にもつながります。

先代の代からの契約を見直すタイミングは、まさにこの「依存関係の棚卸し」を行う好機でもあります。今回のSaaS解約を機に、他にどんなシステムが同じベンダーやその関連会社に紐づいているかを確認し、今後の契約更新のタイミングで少しずつ依存度を分散させていくことも検討してみてください。

社内に技術担当者がいない場合の進め方

多くの承継先企業では、情報システムの専門知識を持つ社員が社内にいません。この場合、データエクスポートの作業を誰にどう任せるかが課題になります。実務上は、次の3つの選択肢が考えられます。

• 経理や総務など、日頃からそのSaaSを操作している社員に作業を依頼する
• ベンダーのサポート窓口に、エクスポート作業自体の代行を依頼する（有償の場合が多い）
• 外部のIT専門家やシステム開発会社に、移行作業全体のサポートを依頼する

小規模な会社であれば1つ目の方法で十分対応できることが多いですが、データ量が多い、あるいは複数のSaaSが絡み合っている場合は、無理に自社だけで抱え込まず、外部の専門家に一時的にサポートを依頼することも検討してください。ここで大切なのは、「移行を丸ごと外部に任せる」のではなく、「データの内容と業務上の意味を理解しているのは自社の社員である」という前提を保つことです。エクスポートやシステム選定の実作業は外部に委託しても構いませんが、どのデータが重要で、どう使われているかという業務知識は、経営者自身が最低限把握しておく必要があります。これは何を内製で判断し、何を外部委託に任せるかという線引きそのものであり、承継後のシステム管理全体を考える上でも重要な視点です。

契約更新のタイミングを逃さないための社内ルール化

今回のような解約前のデータエクスポート作業は、本来であれば毎回の契約更新のたびに「このサービスは継続すべきか」を検討し、必要であればいつでもデータを取り出せる体制を保っておくことが理想です。しかし実際には、自動更新の契約になっていて、更新のタイミング自体を意識する機会がないまま何年も放置されているケースが大半です。

今回のデータエクスポートの経験を、今後のために社内ルールとして残しておくことをお勧めします。具体的には、契約しているSaaSやシステムの契約更新月、解約時の保存期間、データエクスポートの手順を一覧にしておくことで、次に同じような見直しが必要になったときに、また一から手順を調べ直す必要がなくなります。こうした一覧は、システムの契約状況を管理する台帳として社内で共有しておくと、経営者が変わっても引き継ぎやすくなります。年々上がっていく保守料をどう見直すかについては、先代の代から年々上がっていく保守費の契約を見直すタイミングも参考にしてください。

解約の申し出は誰の名前で行うべきか

意外と見落とされがちなのが、「解約の申し出は社長自身が行うべきか、それとも先代や既存の担当者が行うべきか」という問題です。特に先代がまだ会長職などで会社に関わっている場合、契約自体が先代の個人名や旧代表者名義になっていることがあります。この状態のままベンダーに解約を申し出ると、本人確認や権限の確認で余計な時間がかかることがあります。

解約や契約変更を進める前に、まず契約者名義が現在の代表者に更新されているかを確認してください。名義変更がまだであれば、解約の手続きと同時に済ませようとせず、先に名義変更だけを済ませておくとスムーズです。契約者名義の更新は、多くのベンダーで代表者変更の証明書類（登記簿謄本の写しなど）の提出を求められることが一般的なので、事業承継のタイミングで既に法務局への登記変更を済ませているのであれば、その謄本をそのまま使えることが多いです。

また、先代が長年やり取りしてきた担当者との関係を維持したまま解約を進めたい場合は、社長自身が電話やメールで直接連絡するよりも、まずは事務的な窓口経由で「代表者が変わったことのご報告」と「今後の契約に関するご相談」を分けて伝えるという進め方もあります。感情的なやり取りを事務手続きから切り離すことで、担当者側にも心の準備ができ、結果として円滑に話が進みやすくなります。

移行作業のスケジュール感をつかんでおく

最後に、実際にどれくらいの期間を見ておけばよいかについても触れておきます。データ量や業務の複雑さによって大きく変わりますが、目安として次のようなスケジュール感を持っておくと計画が立てやすくなります。

• 契約書・利用規約の確認、ベンダーへの問い合わせ: 1〜2週間
• データの棚卸しとエクスポート対象の洗い出し: 1〜2週間
• 実際のエクスポート作業と検証: 1〜3週間（データ量による）
• 移行先での取り込みテストと本番移行: 2〜4週間
• 並行稼働による最終確認: 1回の業務サイクル分（月次であれば1か月、決算関連であれば決算期をまたぐ場合もある）

これらを合計すると、解約の意思を固めてから実際に旧サービスを解約するまで、短くても1か月半、複雑なケースでは半年近くかかることも珍しくありません。「乗り換えたいと思ったらすぐ解約する」のではなく、逆算してスケジュールを組むことが、データの消失や業務の停止を防ぐ最大のポイントです。特に決算期をまたぐ会計系のSaaSについては、決算処理が完了し、税理士への引き継ぎも済んだタイミングを見計らって移行を進めることをお勧めします。

このスケジュール感を社内で共有しておくことで、「なぜまだ解約していないのか」という周囲からの疑問にも、根拠を持って答えられるようになります。承継後の経営判断は、スピードだけでなく、こうした地道な手順を踏む慎重さも同時に求められる場面が多いということを、心に留めておいてください。

まとめ: データエクスポートは「解約の後始末」ではなく「移行の第一歩」

先代の代から続くSaaSやシステムとの関係を見直すことは、承継後の経営者にとって避けられない仕事の一つです。しかし、それは決して「古いものを切り捨てる」というだけの作業ではありません。長年蓄積してきた顧客データや取引の記録を、次のステージへ確実に引き継ぐための「移行」の作業でもあります。

契約書・利用規約でのデータ返還条件の確認、実際の保存期間の問い合わせ、汎用形式でのエクスポートと検証、複数箇所へのバックアップ、移行先での取り込みテスト、そして解約の申し出。この一連の流れを踏むことで、長年の取引実績を失うことなく、新しい体制へ移行できます。

株式や登記の承継には専門家という相談先がありますが、システムの承継にはまだその相談先が定着していません。だからこそ、経営者自身がこうした手順を知り、社内の誰かに依存しない形でチェックリストとして持っておくことが、承継後の経営を守る備えになります。M&Aで承継した会社が攻めのIT投資に踏み出す前に確認すべき順番は、M&Aで承継した会社が、攻めのIT投資に踏み出す前に確認すべき順番も参考になります。

よくある質問

Q1. 解約を申し出た後、データのダウンロードはいつまでに済ませればいいですか？ A. サービスによって「解約後30日」「解約終了月から6か月後の末日まで」など保存期間の運用が大きく異なります。契約書や利用規約に記載がない場合は、解約を申し出る前に必ずベンダーへ問い合わせて、書面かメールで保存期間の回答をもらってください。口頭確認だけで進めるのはリスクが高い方法です。

Q2. エクスポート機能が用意されていないSaaSの場合、どうすればいいですか？ A. まず契約書・利用規約にデータ返還に関する条項がないか確認してください。条項がある場合は、それを根拠にベンダーへデータ提供を依頼できます。条項が存在しない古い契約の場合は、サポート窓口へ直接依頼し、対応可否と費用負担について書面で確認することをお勧めします。

Q3. CSVでエクスポートしたデータが、移行先のソフトでうまく取り込めません。 A. 文字コードの不一致や項目名の違いが原因になっていることが多いです。移行先のソフトが用意しているサンプルフォーマットやテンプレートに合わせて、エクスポートしたCSVの項目を編集してから取り込むのが一般的な手順です。まずは少量のサンプルデータで取り込みテストを行い、問題点を洗い出してから本番データを移行してください。

Q4. 先代の代からの担当者との関係が気になり、解約を切り出しにくいのですが。 A. 解約の申し出自体は契約上の正当な権利であり、感情的な問題とは分けて考えるべきです。「不満があるから辞める」ではなく「事業の成長・体制見直しに合わせた判断」として伝えると、角を立てずに進めやすくなります。長年の対応への感謝を伝えつつ、事務的な手続きは別途淡々と進める、という姿勢が関係を保つコツです。