概要
Zuora導入プロジェクトで「どのデータをどのツール・手順で移行するか」を体系的に理解する記事です。
- 移行対象はAccount・Subscription・Payment Method・Invoice履歴（Product CatalogはZuora側で新規作成）
- 推奨ツールはZuora MarketplaceのDeveloper Toolsアプリ
- Cutover Dateと差分移行（Delta）の概念を押さえれば移行設計の全体像が見えます
Data Migrationとは
Zuora Data Migrationとは、既存システム（CRM・ERPなど）に蓄積された顧客・契約・支払いデータをZuoraテナントへ移し替えるプロセスです。
SaaS企業がZuoraを新規導入する際、過去のAccountやSubscriptionがZuoraに存在しない状態では請求が動き出せません。既存の請求システムからデータを移行することで、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残高を移行する理由
移行しないアカウント
移行ツール3選
Zuoraには用途別に3つの主要ツールがあります。データの種類と移行フェーズに応じて使い分けます。
| ツール | 対象データ | 主な操作 | 特徴 |
|---|---|---|---|
| Data Loader | Account・Subscription・Payment Methodなど | インポート・更新・削除 | CSV＋UIで操作。フィールドの自動マッピング機能あり |
| Mass Updater | Finance系データ（Invoice・Paymentなど） | 一括非同期更新 | CSVをアップロードするだけで非同期処理 |
| Deployment Manager | Product Catalog定義・Tax設定・Accounting Codeなどのメタデータ | テナント間転送 | Sandbox → 本番への設定コピーに使用 |
移行プロセスとフェーズ設計
データ移行は「Define → Prepare → Execute → Go-Live」の4フェーズで進めます。Cutover Dateがこの全体を貫く基準日になります。
フェーズ構成
Defineフェーズ（キックオフ）の成果
データオーナーの指定
Cutover Dateの役割
Cutover Dateは「どこまでの履歴データを移行対象にするか」を決める基準日です。
| 条件 | 移行対象 |
|---|---|
| Cutover Dateが契約の開始日〜終了日の間にある | ✅ 対象 |
| Cutover Date時点でアクティブ・一時停止中・開始待ちの契約 | ✅ 対象 |
| Cutover Date以前に終了済みの契約 | ❌ 対象外 |
Catch-up Bill Run
移行後、旧システムで請求されていた期間分をZuoraで「追いつき」請求するためにCatch-up Bill Runを実行します。
差分移行（Delta Migration）
一括移行後からGo-Liveまでの間にも旧システムでデータが生まれます。この「ギャップ期間」のデータを差分移行として追加インポートします。
ベストプラクティスと制限事項
| # | プラクティス | 理由 |
|---|---|---|
| 1 | 小規模データで先にテスト | エラーパターンを本番前に潰せる |
| 2 | 低トラフィック時間帯に実行 | 再実行頻度を下げ、本番影響を最小化 |
| 3 | 本番稼働前に一度だけ実施 | 二重実行はデータ不整合・重複請求の原因になる |
| 4 | 日付フォーマットを事前確認 | フォーマット不一致でインポートが全件エラーになる |
| 5 | Product Catalogを先に整備 | Subscription移行時に商品定義が存在しないとエラー |
| 6 | データオーナーを指定 | 変換・マッピングの責任者を明確にする |