旧サービスから新サービスへ移行する手順とは？ユーザー移行を進める6ステップ 

サービスをリニューアルしても、新しいUIを公開するだけで既存ユーザーが移行してくれるとは限りません。使い慣れた旧サービスが残っていれば従来の環境が選ばれやすく、逆に準備が整わないまま一斉に切り替えれば混乱や問い合わせを招きます。

本記事では、旧サービスを残しながら段階的に移行する6つの手順と、移行状況を測る指標を解説します。

この記事の要点

• 新サービスを標準環境、旧サービスを移行期間中の補助環境と位置づける

• 利用状況や業務への影響をもとに移行順を決める

• 新UIの説明ではなく、ユーザーにとっての具体的なメリットを伝える

• 「新サービス上で従来の業務を完了できたか」を移行完了の基準にする

• ユーザーごとの移行状況を定量的に把握し、案内を出し分ける

サービス移行を始める前に何を決めるべき？

並行稼働を始める前に、新旧サービスの役割・対象ユーザー・移行完了の条件を決めます。これらが曖昧なまま走り出すと、旧サービスをいつまでも終了できなくなります。

新旧サービスの役割と最終状態を定める

まず、移行期間中と移行完了後に旧サービスをどう残すかを決めます。主な選択肢は次のとおりです。

• 一定期間後に完全終了する

• 一部機能だけを残す

• 閲覧専用として残す

• 特定の契約やユーザーだけが利用する

• 新規ユーザーは新サービス、既存ユーザーは一定期間だけ旧サービスを利用する

両者を同格に見せ続けると、使い慣れた旧サービスが選ばれ続けられるため、新サービスを標準環境、旧サービスを補助環境と位置づけます。

ユーザーを移行難易度で分ける

全ユーザーに同じタイミングで移行を求めず、難易度で分けます。

移行しやすいのは、利用頻度が低い・使用機能が少ない・データ量や独自設定が少ない・外部連携が少ない・新UIへの関心が高いユーザーです。
逆に、利用頻度が高い、複数部署で使う、独自設定や外部連携が多い企業には個別の移行計画が必要です。

BtoBでは、ユーザー単位に加えて企業・契約・部署・権限・利用機能などの単位でも移行対象を判定します。

移行の段階とスケジュールを決める

完了条件から逆算してスケジュールを組みます。終了日だけでなく、対象を広げる各段階と、次へ進む条件をセットで決めます。段階の例は次のとおりです。

1. 一部ユーザーによる試験移行

2. 移行対象ユーザーの拡大

3. 新サービスをログイン後の初期表示に変更

4. 旧サービスの新規作成・編集を停止

5. 旧サービスを閲覧専用に変更

6. 旧サービスの提供を終了

各段階では、主要業務を完了できていること・重大なエラーが出ていないことを確認してから次へ進みます。

旧サービスから新サービスへ移行する6つの手順

「旧サービスへの新規流入を止める→小さな対象から試す→新サービスを標準化する→旧サービスを縮小する」の順で進めます。

手順1．新規ユーザーは最初から新サービスへ案内する

既存ユーザーを移行させても、新規ユーザーが旧サービスへ流入し続ければ利用者は減りません。

新規登録・招待・営業デモ・ヘルプ記事を新サービス基準に切り替え、旧サービスの新規契約やアカウント発行も可能な範囲で停止します。新規ユーザーは旧UIへの慣れがないぶん、既存ユーザーより移行させやすい対象です。

手順2．移行しやすいユーザーから試験移行する

前述の「移行しやすいユーザー」から試験移行を始めます。

小さな対象で試すと、

• 移行方法が分かりにくい

• 必要な機能が見つからない

• データが正しく反映されない

• 新旧で操作結果が異なる

• ヘルプだけでは解決できない

といった問題を早期に発見できます。ここで修正してから対象を広げることで、大規模な混乱を避けられます。

手順3．利用場面に合わせて新サービスのメリットを伝える

トップページのバナーだけでは、新サービスを使う理由は伝わりません。ユーザーが旧サービスを実際に使っている場面で、何が改善されるかを案内します。
たとえば検索機能の利用者には「新サービスでは条件を保存できます」、管理画面を開いた人には「現在の設定を引き継いだ状態で使えます」と伝えます。

重要なのは「新しいUIになりました」ではなく、今の作業がどう短縮・簡略化されるかを具体的に示すことです。
案内の主な表示場所は、ログイン直後・トップページ・利用頻度の高い機能・マイページや管理画面・操作完了後の画面・ヘルプやFAQです。

手順4．新旧サービスを行き来できる試用期間を設ける

一定期間は、新サービスを試しながら旧サービスへ戻れるようにします。ただし両者を同条件で自由に選べると旧サービスへ戻り続けるため、新サービスを初期表示にし、旧サービスへの導線は必要な場合に使える位置に置きます。

新サービスでは製品全体を一度に説明せず、まず旧サービスで普段行っていた主要業務を新UIで完了できるところまでガイドします。

戻る際には理由を確認します。

• 目的の機能が見つからない

• 操作方法が分からない

• 機能が提供されていない

• 表示や処理に問題がある

• 社内ルール上の理由

• データや設定が反映されていない

などです。理由を集めることで、UI・機能・案内方法のどこを改善すべきか判断できます。

手順5．旧サービスの役割を段階的に縮小する

移行をお願いするだけでなく、旧サービス側の役割も減らします。「移行の段階とスケジュール」で示した後半（初期表示の変更→新規作成・編集の停止→閲覧専用化→提供終了）が、この縮小プロセスにあたります。新機能や機能改善の提供先も、この過程で新サービスに限定していきます。

いきなり閉鎖するのではなく、「新しい業務は新サービスで始める」状態へ段階的に変えていくのがポイントです。

手順6．終了日とユーザーごとの対応方法を案内する

終了日が決まったら、対象ユーザーへ余裕を持って案内します。

必要な告知期間は、

• 契約条件

• データ量

• 業務への影響

• 個別対応が必要な企業数

によって変わります。

終了案内には、

• 終了日

• 利用できなくなる機能

• 移行方法

• 引き継がれるデータと設定

• ユーザー側で必要な作業

• 問い合わせ先

を含めます。

すでに移行済みのユーザーと旧サービスだけを使うユーザーに同じ案内を出す必要はありません。後述のとおり、移行状況に応じて内容や頻度を調整します。

サービス移行の完了はどの指標で判断する？

ログイン率だけでは移行完了とは言えません。新サービス上で従来の業務を完了し、その後も継続利用できているかを確認します。

認知から定着までを段階別に計測する

移行状況は、認知→利用開始→操作完了→継続利用の順に確認します。

具体的には、

• 移行案内の表示率

• 新サービスへの遷移率

• 初回ログイン率

• 主要機能の初回利用率

• 主要業務の完了率

• 7日後/30日後の継続利用率

• 旧サービスへの戻り率

です。

どの段階で数値が落ちるかを見れば、「案内が伝わっていない」「操作で迷っている」「必要な機能がない」といった原因を切り分けられます。

問い合わせと未移行ユーザーを確認する

移行率だけでなく、移行がユーザーや運営側にかける負担も見ます。

主な指標は、

• 移行に関する問い合わせ件数

• データ移行や設定のエラー件数

• 移行完了企業数

• 旧サービスだけを使うユーザー数

• 個別対応が必要な企業数

です。

移行率が上がっていても問い合わせやエラーが急増していれば、案内方法や切り替え速度の見直しが必要です。

「業務を完了できたか」を中心指標にする

ログインやページ閲覧は途中経過にすぎません。
重要なのは、旧サービスで行っていた主要業務を新サービスだけで完了できる状態になったかです。

請求書作成サービスなら請求書の発行、予約サービスなら予約登録、管理サービスなら必要な設定の保存を完了指標にします。

この指標が、PdMの定義した新サービスの価値と、ユーザーの実際の利用状況を結びつけます。

ユーザーごとに移行案内や支援を出し分けるには？

一律の案内ではなく、利用状況を定量的に把握し、移行段階に応じて内容とタイミングを変えます。

ユーザーごとの移行状況をモニタリングする

ユーザーや企業ごとに、

• 移行案内を表示したか

• 新サービスへ遷移したか

• 初回ログインを完了したか

• 主要機能を利用したか

• 主要業務を完了したか

• 旧サービスへ戻ったか

• 最終利用から何日経過したか

を確認します。

全体の移行率だけでなくユーザー単位・企業単位で現在地を把握することで、次に必要な案内を判断できます。

移行段階に応じて案内を変える

モニタリング結果をもとに出し分けます。

• 新サービス未利用者には、移行するメリットを伝える

• 初回ログイン済みのユーザーには、主要操作のガイドを表示する

• 主要業務を完了したユーザーには、初回向けガイドを停止する

• 旧サービスへ戻ったユーザーには、戻った理由を質問する

• 一定期間利用がないユーザーには、再開のための案内を表示する

同じユーザーに不要な案内を繰り返さないことも大切です。段階が進んだら、次の操作に必要な情報へ切り替えます。

移行状況の計測と出し分けにOnboardingを活用する

こうした移行支援は、本体サービスのUIを全面改修しなくても、既存画面に案内を追加する形で実装できます。

Onboardingでは、ユーザー属性や利用状況に応じて、ポップアップ・操作ガイド・ヒント・アンケートを画面上に表示できます。

新サービスを初めて使うユーザーにはガイドを表示し、操作を完了したユーザーには停止する、といった設計が可能です。

ログインや特定機能の利用状況を確認できるため、「新サービスを開いたか」だけでなく「主要操作を完了できたか」を見ながら施策を改善できます。

旧サービスから新サービスへの移行に関するよくある質問

新旧サービスの並行稼働期間はどのくらい必要ですか？

一律の正解はありません。契約条件・移行データ量・業務への影響・個別支援が必要な企業数をもとに決めます。終了日だけでなく、試験移行・対象拡大・機能縮小の節目も設定します。

新サービスへの切り替えを強制してもよいですか？

原則として、最初から全ユーザーを一斉に強制するのは避けます。主要業務を完了できること・必要なデータが反映されていること・問い合わせ体制が整っていることを確認したうえで、移行難易度の低い層から段階的に広げます。

旧サービスへ戻るボタンは残すべきですか？

試用期間中は残すと、ユーザーが安心して新サービスを試せます。ただし新サービスを初期表示にし、戻る際に理由を確認できる設計が望ましいです。

新サービスにない機能がある場合はどうすべきですか？

利用者数と業務への影響を確認し、代替手段・提供予定・旧サービスでの一時利用の可否を案内します。業務上欠かせない機能なら、対象ユーザーの移行時期を分ける判断も必要です。

新サービスへの移行率が上がらない場合は何を見直すべきですか？

案内の表示状況・メリットの伝え方・データの引き継ぎ・UI上の迷い・未提供機能の有無を順に確認します。旧サービスへ戻った理由も、改善箇所を特定する材料になります。

まとめ｜新サービスを標準にし、旧サービスの役割を段階的に減らす

移行は公開日を決めて一斉に切り替えるのではなく、対象を分けて段階的に進めます。新規ユーザーを新サービスへ統一し、移行しやすいユーザーから試したうえで、案内・試用期間・旧サービスの縮小を順に実施します。進捗はログイン率ではなく、新サービス上で主要業務を完了できたかまで確認します。

ユーザーごとの移行状況を定量的に把握して案内を出し分ければ、PdMやPMも施策の課題を判断しやすくなります。

Onboardingを使った画面上の移行案内や利用状況の計測を検討している場合は、現在の新旧サービスの役割や移行状況を整理するところからご相談ください。

相談はこちら