概要

Zuora導入プロジェクトで「どのデータをどのツール・手順で移行するか」を体系的に理解する記事です。

• 移行対象はAccount・Subscription・Payment Method・Invoice履歴（Product CatalogはZuora側で新規作成）
• Zuoraの移行ツールは「メタデータ（設定）」と「トランザクションデータ（実データ）」で系統が分かれる
• Cutover Dateと差分移行（Delta）の概念を押さえれば移行設計の全体像が見えます

Data Migrationとは

Zuora Data Migrationとは、既存システム（CRM・ERPなど）に蓄積された顧客・契約・支払いデータをZuoraテナントへ移し替えるプロセスです。

SaaS企業がZuoraを新規導入する際、過去のAccountやSubscriptionがZuoraに存在しない状態では請求が動き出せません。既存の請求システムからデータを移行することで、Zuoraによる請求サイクルをゼロから稼働させられます。

データエクスポートの方法

レガシーシステムからのデータエクスポートは手動でも、ETLツールを使った自動化でも行えます。アカウント数の多少に関わらず、どちらの方法も有効です。

方法	向いているケース
手動エクスポート	件数が少ない・一時的な作業
ETLツール自動化	件数が多い・定期的な差分移行

移行対象データの種類

移行対象はAccount・Subscription・Payment Method・Invoiceの4種類です。Product CatalogはZuora側で新規作成するため、レガシーシステムからの移行対象ではありません。

カテゴリ	オブジェクト	移行対象？
マスターデータ	Account	✅
マスターデータ	Payment Method	✅
トランザクション	Subscription	✅
トランザクション	Invoice履歴	✅
トランザクション	Payment履歴	✅
設定データ	Product Catalog	❌（Zuora側で新規定義）
その他	Reports	❌（移行対象外）

Open Invoice残高を移行する理由

移行しないアカウント

Zuoraが提供するデータ移行サービスの分類

Zuoraのセルフサービス移行ツールは、大きく「①メタデータの移行（設定・構成）」と「②トランザクションデータの移行（顧客・契約・請求などの実データ）」の2系統に分かれます。移行したいものがどちらに属するかを最初に見極めることが、ツール選定の出発点です。

①メタデータの移行（Metadata Deployments）

Settings・Custom Fields・Notificationsなど「設定・構成」をテナント間でコピーする仕組みです。ソース環境とターゲット環境が違っても動作する（環境非依存）という特徴があります。

ツール	内容
Deployment Manager	ソーステナントとターゲットテナントの差分を比較・検証しながら、選んだ構成要素だけを転送できるセルフサービスUI
Configuration Templates	構成の一部をJSON形式のテンプレートとして書き出し、GitやCI/CDパイプラインで再利用可能にする仕組み。Golden tenant（お手本となるテナント）の設定を切り出して複数環境へ繰り返しデプロイする用途に向く
Metadata API	開発者・管理者がプログラム経由でソースからターゲットへ構成を移行するためのAPI群

②トランザクションデータの移行（Transactional Data Tools）

Account・Subscription・Invoice・Paymentなど「実データ」に対してImport・Update・Create・Exportを行うためのツール群です。

ツール	位置づけ	特徴
Data Loader	現行の主力ツール（Developer Toolsの後継）	セルフサービスUI・動的テンプレート・インライン編集に対応し、取り込み前にテナント設定と照合するリアルタイムバリデーションを持つ。ビジネスユーザーでも扱える設計
Mass Updater	Finance系データの一括非同期更新に特化	Invoice・Payment・為替レートのインポートなど、まとめて非同期で更新する用途で実運用実績がある
Developer Tools	レガシーツール（順次廃止予定）	Account & Contacts API Loader・Product Catalog API Loader・Subscription API Loaderなど、用途別の複数のマイクロアプリの集合体。CSVでのImport/Update/Delete/Exportに対応するが、Zuoraは今後Data Loaderへの移行を推奨している

knowledgecenter.zuora.comknowledgecenter.zuora.com/Zuora_Platform/Data_Management/Zuora_DevOps/Data_Mig...

移行プロセスとフェーズ設計

データ移行は「Define → Prepare → Execute → Go-Live」の4フェーズで進めます。Cutover Dateがこの全体を貫く基準日になります。

フェーズ構成

各フェーズで何をするか

「どのフェーズで何をするか」をフェーズごとに整理します。

① Define（定義） — まだデータには触らない

❌ このフェーズではデータそのものは一切触りません。段取りを決める段階です。

• キックオフセッションの実施
• 顧客をZuoraのデータ移行チームへ正式に紹介
• マッピングセッションの日程調整（旧システム⇔Zuoraのフィールド対応表を作る"場"の予約）
• 移行スコープの大枠合意

② Prepare（準備） — データを"移行できる形"へ加工する

✅ ここから実際にデータを触り始めます。

• Product Catalogの作成（Zuora側で商品・料金プランを先に定義。Subscription移行の受け皿を用意する）
• Data Mapping（旧システムのどのフィールドがZuoraのどのフィールドに対応するかを確定）
• Data Cleaning（重複排除・欠損値補完・フォーマット統一などのクレンジング）
• データオーナーの指定（変換作業の責任者を決める）
• Cutover Dateの決定（どこまでの履歴を対象にするかの基準日を確定）

③ Execute（実行） — 加工済みデータを実際に流し込む

✅ Prepareで整えたデータを実際にZuoraへ投入します。

• 一括移行（Bulk Migration）— Data Loader等でSandbox/本番に投入
• 移行結果の検証
• 差分移行（Delta Migration）— 一括移行後に旧システムで発生した新規データを追加投入

④ Go-Live（本番稼働） — 切り替えの瞬間

✅ 以降は本番データとして扱われます。

• 旧システムへの新規入力を停止
• 直前の最終差分移行（Delta）を実施
• **Cutover（切り替え作業）**の実行
• Zuora本番環境での請求サイクル開始
• 必要に応じてCatch-up Bill Run（旧システムで請求していた期間分の追いつき請求）を実行

Defineフェーズ（キックオフ）の成果

データオーナーの指定

Cutover Dateの役割

Cutover Dateは「どこまでの履歴データを移行対象にするか」を決める基準日です。Prepareフェーズで決定し、実際にその日を迎えて切り替える作業（Cutover）はGo-Liveフェーズで行います。

条件	移行対象
Cutover Dateが契約の開始日〜終了日の間にある	✅ 対象
Cutover Date時点でアクティブ・一時停止中・開始待ちの契約	✅ 対象
Cutover Date以前に終了済みの契約	❌ 対象外

Catch-up Bill Run

移行後、旧システムで請求されていた期間分をZuoraで「追いつき」請求するためにCatch-up Bill Runを実行します。Go-Liveフェーズのカットオーバー作業の一部です。

差分移行（Delta Migration）

一括移行後からGo-Liveまでの間にも旧システムでデータが生まれます。この「ギャップ期間」のデータを差分移行として追加インポートします。

高度な概念と移行の制限事項

基本の4フェーズ・3ツールに加えて、実務では以下のような発展的な論点・制限事項も押さえておく必要があります。

環境ごとのテスト・移行サイクル

本番移行の前に、Sandbox環境で移行手順そのものをリハーサルします。Application Lifecycle Management（ALM）の考え方に沿って、Unit Testing・Integration Testing・UATの各段階で「実データに近いテストデータ」を投入し、移行スクリプトやマッピングの精度を検証してから本番に臨みます。

よくある制限事項

制限事項	内容
Deployment Managerはメタデータ専用	AccountやSubscriptionのようなレコードデータは移行できない。User Role・カスタムオブジェクトのレコード・パスワードも非対応
本番稼働後の再移行は不可	稼働後に同じデータを再投入すると二重登録・請求不整合を引き起こす
UOM・通貨・日付フォーマットの不一致	旧システムとZuoraでフォーマットが違う場合、インポートが全件エラーになりやすい
Product Catalogは移行対象外	Subscriptionを移行する前に、Zuora側でProduct Catalogを先に用意しておく必要がある
Amendment履歴（旧Subscribe and Amendモデル）	旧モデルの契約変更履歴をそのままOrder履歴として移行することはできない。[[BI4]]のOrders Harmonizationも参照

Zuora導入プロジェクト全体の流れ（Implementation Guide 101 / ZIM）

Data Migrationは301固有のトピックで、101/201の公式試験には対応するセクションがありません。ここでは、旧・Implementation Guide 101学習記事の内容をこの記事に統合し、Zuora導入プロジェクト全体（Inception〜Succeed）の中でデータ移行がどこに位置するかを整理します。

全体の流れ：Inception → Design → ARA → Build → ARA → Deploy → Succeed

Zuora Implementation Methodology（ZIM）は6つの主要フェーズで構成されます。プロジェクト立ち上げ（営業からのハンドオフ・J2Uによるキックオフ前イネーブルメント）は[[BI1]]で扱っている内容と重なる部分が多いため、ここではその後のInception（プロジェクトの立ち上げ・ビジョン合意）以降の流れに絞って整理します。

Inceptionフェーズ（Inception/Vision）の学習目標

公式のImplementation Guide 101コースでは、Inception/Visionフェーズについて次の8つの学習目標が示されています。

#	学習目標
1	Inception/Visionフェーズの定義
2	フェーズ内の主要アクティビティ一覧
3	Sales-to-Implementation（営業から実装チームへの）引き継ぎプロセスの目的
4	キックオフ前後の重点確認事項
5	キックオフ会議のアジェンダ・成果物一覧
6	Zuora導入に必要な顧客側の役割
7	プログラム/運用ガバナンスのガイドライン
8	アジャイル/ウォーターフォール手法の使い分け、推奨されるES（Expert Services）チーミングモデル

Solution Design Document（SDD）とDMS

SDDは1つの分厚い文書ではなく、目的の異なる3つのパーツで構成されます。

要素	一言で言うと
CRP（Conference Room Pilot）	本番前の"通しリハーサル"。実際の画面を動かしながら顧客と一緒に確認する
DMS（Data Migration Strategy）	旧システムのデータをどう引っ越すかの計画。本記事の「移行プロセスとフェーズ設計」がこのDMS作成活動に対応
RTM（Requirements Traceability Matrix）	要件と実装内容の"対応表"。要件が漏れなく実現されているかのチェックリスト

Architecture & Readiness Assessment（ARA）

ARAは、プロジェクトが今どれくらい健康な状態で進んでいるかをスコアカード形式で可視化する仕組みです。チェックポイントは「設計時（Architecture Review Board）」と「稼働直前（Go-Live Review）」の2つだけです。Post Go-Live Review（稼働後のレビュー）はARAの正式なチェックポイントとしては扱われません。

Buildフェーズのゴールと実装チームの役割分担

Buildフェーズのゴールは、①設定変更を環境間で移行すること、②構成内容をドキュメント化することの2つです。「ソリューション設計そのものを作る」「データ移行戦略を定義する」はDesignフェーズの成果物であり、Buildフェーズのゴールとしては誤りです。

役割	何を見ているか
Implementation Lead	プロジェクト全体の進行。必要な場面ではSolution Architectの橋渡し役として設計やワークショップにも参加する
Solution Architect	技術的な設計の中身。データマッピングやデータ移行の実務、設計ワークショップの主導など技術的な実行を担う
Partner Prime	パートナーとの連携体制。Zuora側のリソースも顧客チームと連携させ実装を支える

Zuora Revenue（収益認識の専用モジュール）を導入する場合は、Billingとは別に移行が必要な設定が3つあります。

用語	内容
Performance Obligations（POBs）	収益を認識する最小単位となる「履行義務」
RC Grouping	複数のRate Plan Chargeを1つの履行義務としてまとめるグルーピング設定
Contract Modifications	契約変更が既存の収益認識に与える影響のルール

テスト・デプロイ・Succeedフェーズ

SIT（System Integration Testing）の前提は「開発完了」「単体テスト完了」「基本的なエンドツーエンド機能確認の完了」の3つです。UATの完了やエンドユーザーのトレーニングはSITの前提条件には含まれません。

SITは主に技術チームがシステム間連携を検証するのに対し、UATは顧客のエンドユーザー自身が業務目線で検証を行う点が異なります。

Deployフェーズのカットオーバー作業は、本番環境の準備・レガシーデータの投入・上流/下流システムとの連携・カスタマイズの本番反映が典型です。移行データやテスト実行から生成されたBill Runを将来の請求対象から除外したい場合は、本記事のCatch-up Bill Runと同じ考え方（catch-up bill runの実行）が使われます。ここでは「テスト実行の除外」という角度で扱っている点に注意してください。Train-the-Trainerセッション（エンドユーザー教育）はカットオーバー作業そのものではなくイネーブルメント側の活動です。

Succeedフェーズのゴールは、本番稼働後に発生する課題やイネーブルメント不足を解消すること、そして顧客関係のオーナーシップをCustomer Success ManagerやAccountチームへ正式に引き継ぐことです。プロジェクトのクロージャーより、稼働後の安定化と関係の引き継ぎが優先されます。

ベストプラクティスと制限事項

#	プラクティス	理由
1	小規模データで先にテスト	エラーパターンを本番前に潰せる
2	低トラフィック時間帯に実行	再実行頻度を下げ、本番影響を最小化
3	本番稼働前に一度だけ実施	二重実行はデータ不整合・重複請求の原因になる
4	日付フォーマットを事前確認	フォーマット不一致でインポートが全件エラーになる
5	Product Catalogを先に整備	Subscription移行時に商品定義が存在しないとエラー
6	データオーナーを指定	変換・マッピングの責任者を明確にする

knowledgecenter.zuora.comknowledgecenter.zuora.com/Zuora_Platform/Data_Management/Zuora_DevOps/Data_Mig...