概要

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

• 移行対象はTypical Migration Objects（Accounts and Contacts・最新バージョンのSubscription・Payment Methods・Open Balances）が中心で、Atypical Migration Objects（Product Catalog・履歴データなど）は原則移行しない
• Zuoraの移行ツールは「メタデータ（設定）」と「トランザクションデータ（実データ）」で系統が分かれ、現行の主力はData Loaderと Mass Updater
• 移行プロセスには、Zuora公式の4ステージ（Planning→Preparation→Migration→Post-Migration）と、プロジェクト管理視点の5フェーズ（Vision→Define→Build→Test→Deploy）という2つの捉え方がある
• Standard移行（セルフサービス）・Premium移行（Zuora移行チーム代行）・Zuora to Zuora（ZtoZ）移行という3種類の移行パターンがある
• Cutover Date、差分移行（Delta）、Catch-up Bill Run（CUBR）の概念を押さえれば移行設計の全体像が見える

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残高を移行する理由

移行しないアカウント

移行オブジェクトの分類：Typical / Atypical

移行するオブジェクトは大きく「Typical Migration Objects（典型的な移行オブジェクト）」と「Atypical Migration Objects（非典型的な移行オブジェクト）」の2グループに分かれます。

• Typical Migration Objects：プロジェクトを成功させるために必要な基本データを含み、Zuoraプラットフォームでの本番稼働（go-live）に向けた標準的な移行オブジェクトとされる
• Atypical Migration Objects：プロジェクトの成功に必須ではない追加データを含み、レガシーシステムからZuora環境へは移行されない。通常はデータウェアハウスやレガシーシステム内に読み取り専用（read-only）で保持され、必要に応じてユーザーがアクセスする

Typical Migration Objectsの4つのオブジェクト

Typical Migration Objectsは以下の4つのオブジェクトで構成されます。

Accounts and Contacts

• 氏名（Name）、アカウント番号（Account number）、請求サイクル日（Bill cycle day）、請求バッチ（Billing batch）、通知設定（Notification preferences）、住所・メールアドレス（Street and email addresses）、支払い条件（Payment terms）、デフォルトの支払い方法（Default payment method）、デフォルトの支払いゲートウェイ（Default payment gateway）など、顧客に関する重要な情報を含む
• 1つのアカウントに複数のコンタクト（最大144件）を保持できるが、デフォルトのBill Toコンタクト・Sold Toコンタクトはそれぞれ1つずつのみ
• 連携用のリンクにはZuoraのカスタムフィールドを活用する
• 今後も請求が発生するアクティブなアカウントデータを移行対象に含む

Most Recent Active Version of Subscription

• Subscriptionオブジェクトは「最新のアクティブバージョン」のみをZuoraへ移行する。過去のバージョンはすでに請求対象外であり、今後の請求処理に影響しないため
• 特定の顧客アカウントに紐づく、商品・チャージ関連の情報をすべて含む
• 連携リンク・既存のエンタイトルメント・プロビジョニングリンクには、Subscription・Subscription Rate Plan・Subscription Rate Plan Chargeオブジェクトのカスタムフィールドを活用する

Payment Methods

• クレジットカード（Credit Cards）、トークン（Tokens、一部のゲートウェイのみ対応）、ACH、口座振替（Direct Debit）など、対応する支払い方法のデータを含む
• 支払いゲートウェイの情報はAccountオブジェクトの一部として移行される。Payment Methodsそのものの移行はPCI準拠の方法で行い、支払いゲートウェイまたはサードパーティと連携してデータを抽出する
• 移行プロセスには、Zuora・実装パートナー・支払いゲートウェイのいずれかが提供する安全なファイルアップロード/ダウンロード場所と、それらが提供する公開鍵によるファイルの暗号化が必要
• トークンとして支払い方法を移行する場合はPCI準拠の方法は不要で、暗号化なしのファイルとして読み込むことができる。ただし、Zuoraが対応するトークン化は一部の支払いゲートウェイに限られる点に注意

Open Balances（Open Invoices）

• go-live時点でZuora上に残る未払いの残高を指す。移行することで、レガシーシステムではなくZuora上でファイナンスチームが残高を追跡できるようになる
• この移行はサマリーレベルで行われ、商品ごとの明細や単価は含まない。エージング情報（滞留日数）も移行できるが、サマリーレベルという原則は変わらない

Open Balancesの移行時：

• アカウント上のすべての未払いInvoiceを合算し、1件の金額としてロードする
• 別建ての「Open Balance」商品の下に、一時金（one-time）・定額（flat-fee）チャージを持つ「Open Balance」Rate Planを作成する
• 顧客によっては、特定の商品・オファリング・サービスに紐づけて残高を管理したい場合、Open Balance Rate Plan内に複数の一時金チャージを持たせることもある
• アカウント残高がマイナスの場合は、Credit Memoを作成する追加のステップが必要になる

Open Invoicesの移行時：

• Open Balancesと同様に、未払いのInvoiceごとに個別のSubscriptionを作成する
• 各未払いInvoiceは、アカウント上の別々のSubscriptionとして移行される

Atypical Migration Objectsの内訳

Atypical Migration Objectsには、以下のようなオブジェクトが含まれます。いずれも移行対象には含めず、レガシーシステムやデータウェアハウス側に読み取り専用で残しておくのが基本方針です。

Product Catalog

Product Catalogは通常、移行オブジェクトとはみなされません。Zuoraのテンプレートに合わせて商品データをビジネス側とソリューションアーキテクトが一から再設計する必要があるためです。プロジェクト規模が大きい場合は一部移行やETL（Extract, Transfer, Load）プロセスを組むことも可能ですが、その場合は顧客がZuoraと密に連携して設計する必要があり、プロセスの所有を顧客側が担うケースもあります。

Inactive/Cancelled/Non-Paying Accounts、Cancelled/One-Time/Inactive Subscriptions

ビジネスの過去の履歴データすべてを含むオブジェクトです。Zuoraの請求システムは今後のすべての請求について100%の正確性を目指しており、履歴データを持ち込むことは移行・突合（reconciliation）作業の複雑性を増すだけです。そのため、今後も請求が発生し続けないアカウントや、キャンセル済みのアカウントはZuoraへ価値をもたらさず、移行しません。

Amendments（Subscriptionへの過去の変更履歴）

Amendmentオブジェクトも移行しません。これはビジネスの履歴データの一部だからです。Zuoraが推奨するのは、レガシーシステムから移行するSubscriptionの最新の請求バージョンのみです。理由は以下の2点です。

• レガシーシステムにはZuoraのようなAmendmentの記録・履歴が存在しないことが多く、レガシーデータはレポーティング目的でデータウェアハウス側に保持されている。データをZuoraに重複して持ち込むのはベストプラクティスに反する
• 日付や商品など、AmendmentデータをZuoraへ正確に移行するために必要なデータが、レガシーシステム側にすべて揃っているとは限らない

これにより、移行プロセスをできる限り効率的に保てます。

Historical Finance Data（Revenue Schedules / Invoices, Payments, Refunds / Debit Memos, Credit Memos / Journal Entries）

• Revenue Schedules：レガシーシステムや総勘定元帳（general ledger）に、高レベルのレポーティング用として情報が残っています。収益認識のためには、Zuoraは開いている会計期間（open accounting periods）についてのRevenue Scheduleを必要とするため、過去のRevenue ScheduleをZuora環境へ移行することはありません
• Invoices, Payments, Refunds：ZuoraはレガシーのBillingシステムと比べて、比例配分（proration）・端数処理（rounding）・請求ルールの設定が異なるのが一般的です。請求処理でのエラーを防ぐため、過去のInvoice・Payment・Refundは移行せず、レポーティング用にレガシーシステム側のデータウェアハウスに保持しておくのが推奨されます。古い税率（tax rates）も同様です。なお、Refundはレガシーシステム側でPaymentに紐づけて管理するか、Zuora側で単独のCredit Memoとして発行することもできます
• Debit Memos, Credit Memos：財務系の履歴データと同様、税率・比例配分/端数処理/請求ルール・請求システムそのものが異なるため、レガシーシステムやデータウェアハウス側に残しておくのが望ましく、Zuoraへは持ち込みません
• Journal Entries：Zuoraはあくまでビジネスの総勘定元帳（general ledger）に対するサブレジャーとして機能します。そのため、締め済みの会計期間（closed accounting periods）に関するレガシーのJournal Entryは、ビジネス側の総勘定元帳に保持されたままとなります

Salesforce Data

Salesforceデータは分類上はAtypical Migration Objectに含まれますが、Zuoraは他のAtypicalオブジェクトとは異なり、すべてのSalesforceデータを移行することを推奨しています。

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	Zuora上でいつでも使える一括操作ツール	同じ操作を1件ずつ繰り返す代わりに、対象データをまとめた1つのCSVファイルをアップロードすると、Zuoraが非同期でアクションを実行し、各処理結果をまとめたレスポンスファイルを返す
Developer Tools	レガシーツール（順次廃止予定）	Account & Contacts API Loader・Product Catalog API Loader・Subscription API Loaderなど、用途別の複数のマイクロアプリの集合体。CSVでのImport/Update/Delete/Exportに対応するが、Zuoraは今後Data Loaderへの移行を推奨している

Mass Updaterの主な機能

Mass Updaterの主な機能は以下の6つです。

• 会計コード（Accounting Codes）の更新
• Revenue Scheduleの作成
• Revenue Scheduleの更新
• Revenue Scheduleの削除
• 外国為替レート（Foreign Exchange Rates）のインポート
• 一括支払い（Mass Payments）のアップロード

Product Catalog API Loaderの実行モード

Developer Toolsの一つであるProduct Catalog API Loaderには、3つの実行モード（Run Mode）があります。

• Export：テナント環境から必要なProduct Catalog情報をエクスポートできる。データの取得・加工を迅速に行いたい場合に使う
• Import：あらかじめ用意したCSVファイルをインポートすることで、Product・Rate Plan・Charge・Tierを新規作成または更新できる
• Migrate：あるテナントからProduct Catalogをエクスポートし、その情報を別のテナントへインポートできる

このほかに「Import Discounts」という実行モードも用意されています。

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

移行プロセスとステージ設計

データ移行はZuora公式のData Migration Processに沿って「Planning → Preparation → Migration → Post-Migration」の4ステージで進めます。

ステージ構成

各ステージで何をするか

「どのステージで何をするか」をステージごとに整理します。

① Planning（計画）

Planningステージでは、プロジェクトの各種成果物をスコープに含め、必要な時間とリソースを見積もります。 具体的には以下のような項目を確定させます。

• 移行するデータの種類（Types of data to be migrated）
• データのソース（Sources for the data）
• テストロードの回数とタイミング（Number and timing of test loads）
• 問題が見つかった場合の是正手順（Steps to correct any issues that are found）
• カットオーバー時の移行戦略（Strategy for migration at cutover）
• 各ステージ・各ステップに関与するメンバー（Members involved in each stage and step of migration）

データはCSV形式の「データロードテンプレート」を使ってZuoraへロードします。このテンプレートのサンプルは、移行開始時にGS Data Migrationチームへリクエストできます。

② Preparation（準備）

Preparationステージは以下の5つのステップで構成されます。

1. Product Catalogの設定（Configuring Product Catalog）：Subscription/Order・売掛金（Accounts Receivable）データを移行する前に、Zuora側で製品カタログと関連する価格・パッケージ情報を設定します。これは通常UI経由で行います。Account・稼働中のSubscription・Payment Methodデータなどその他のオブジェクトは、後続のコースで扱うAPI Loaderを使って移行します。
2. システム間マッピング課題の解消（Resolving system-to-system mapping issues）：ロードテンプレートを使ったデータ転送の前に、レガシーシステムの各オブジェクトをZuora側の新しい格納先へマッピングします。
3. データ抽出（Extracting Data）：データ転送前にレガシーシステムからデータを抽出し、フォーマットを確認・検証できるようにします。
4. データ変換（Transforming Data）：レガシーシステムのデータをZuoraの要件に合う形式にフォーマットします。ここではレガシーシステムのデータ構造を熟知した担当者（データオーナー）が抽出・変換作業を担うと、変換ミスを防ぎやすくなります。
5. テストデータロード（Test Data Loading）：抽出・変換したデータがZuoraへ正しくロードできるかを確認するため、ロードテストを実行します。できるだけクリーンなデータにするため、複数回テストを行います。

③ Migration（移行）

Migrationステージでは、レガシーシステムからZuoraへ実際にデータを移動します。

移行の性質によっては、GS Data Migrationチームが複数バッチに分けてデータを移動することを判断する場合があります。一括で移行した後、Go-Liveまでの間にレガシーシステム側で新たに発生したデータを追加で取り込む「差分移行（Delta Migration）」も、このバッチ移行の一種として実務では使われます。

④ Post-Migration（移行後）

Post-Migrationステージでは、データ検証（Data Validation）を行います。 データが欠落なく（without missing records）、正しくロードされたかを確認する一連のテストで、以下の方法を組み合わせて行います。

• 自動チェック（Automated checks）
• メトリック比較（Metric comparisons）
• 目視チェック（Visual checks／手動比較）

移行が完了した時点で、Zuoraシステムは請求（Bill）・回収（Collect）、そしてレポーティング・ファイナンスデータの提供ができる状態になっている必要があります。実務では、旧システムで請求していた期間分をZuoraで「追いつき」請求するCatch-up Bill Runも、この本番稼働開始に合わせて実行します（CUBRの実行方法・Invoiceの消し込み方法は「Catch-up Bill Run（CUBR）の2つの実行方法」で詳しく扱います）。

Cutover Dateの役割

Cutover Dateは「どこまでの履歴データを移行対象にするか」を決める基準日です。Planningステージの「カットオーバー時の移行戦略」の一部として方針を固め、実際にその日を迎えて切り替える作業はMigration〜Post-Migrationの一連の流れの中で行います。

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

データ移行時に考慮すべき要因

Zuoraへのデータ移行では、以下の4つの要因が課題になりやすいとされています。

ビジネスエコシステムの変化（Change in business ecosystem）

移行後、Zuoraが請求・ファイナンス・コマースのデータをどう扱うかによって、ビジネスオペレーションや顧客とのやり取りの仕方そのものが変わる場合があります。

請求システムのデータモデルの違い（Difference in billing system data models）

レガシーの請求システムとZuoraでは、データの保存・アクセス方法が異なることがあります。例えば、レガシーシステムでは氏名と住所を1つのフィールドにまとめて保存しているのに対し、Zuoraでは別々のフィールドに保存する、といった違いです。

データ抽出の難しさ（Difficulty in data extraction）

レガシーデータが複数のサイロや旧式システムに分散している場合、抽出作業が難しくなります。また、データの欠落や不正確さも起こりやすく、Zuoraへロードする前に手作業でのクレンジングが必要になることがあります。例えば、レガシーシステムの住所データに「US」と「USA」が混在しているようなケースはデータの不整合を生み、クリーンアップが必要になります。

レガシーデータの継続的な変化（Continuous change in legacy data）

データ移行中も通常のビジネスオペレーションが止まらない場合に発生する課題です。新システムとのデータ同期に追加の難しさをもたらします。

Standard / Premiumデータ移行とPremium Data Migration Process

ZuoraのセルフサービスによるStandardなデータ移行に加えて、Zuora移行チームが変換作業を代行するPremiumデータ移行という選択肢もあります。

Premiumデータ移行では、Zuora移行チームが次のようなステップでデータを処理します。

1. データの受領：CSV・JSON・データベースバックアップなど、顧客とあらかじめ合意したフォーマットでデータを受け取る
2. ステージングDBへの取り込み：受領したデータをステージングデータベースにロードする
3. 変換スクリプトの作成：マッピングドキュメントとビジネスルールに基づき、SQL ServerまたはMySQLを使って変換スクリプトを作成する
4. 変換スクリプトの実行：作成した変換スクリプトを実行し、Zuoraが要求するフォーマットで新しいテーブルを作成する
5. CSV形式へのエクスポート：変換済みデータをCSV形式でエクスポートする
6. APIローダー等でのロード：Data Loaderなどのツールを使ってエクスポートしたデータをZuoraへロードする
7. 変換スクリプトの引き渡し：最後に、変換スクリプト一式を顧客へ返却し、以降の実行・管理を顧客側で行えるようにする

Zuora to Zuora（ZtoZ）データ移行

Zuora to Zuora（ZtoZ）データ移行とは、既存のZuoraテナントから別のZuoraテナント（マルチエンティティ導入時のサブエンティティなど）へデータを移す移行パターンです。

サポートされるオブジェクト・されないオブジェクト

区分	オブジェクト
✅ ZtoZ移行プロセスの一部としてサポート・移行される	Accounts/Contacts、Subscriptions（最新のアクティブバージョンのみ抽出・再インポート可能）、Product Catalog、Open Balances（サマリーレベルの残高のみ抽出・インポート可能）
❌ ZtoZ移行プロセスの一部としては非サポート	Amendments、Payments、Invoices and Invoice Items、Refunds、Taxation Items、Revenue Schedules

Migration Approach（5ステージ）

完全なZtoZデータ移行では、現在のエンティティにあるすべてのアクティブなSubscription・Account・未収A/R・Revenue Scheduleを、複数のサブエンティティへ分割します。 データ移行は段階的に実施し、各ステージの完了後に顧客がサインオフを行い、移行スクリプトが該当データを正しく記録できていることを確認してから次のステージへ進めるのが基本です。

5つのステージは以下の通りです。

1. Product Catalog
2. Accounts and Subscriptions
3. Catch Up Bill Run
4. Open Invoices
5. Accounting and Reporting

① Product Catalog

複数のサブエンティティにまたがって商品を共有する必要がある場合、Product Catalogはグローバルエンティティ側で一元管理し、各商品を該当するサブエンティティへ共有する方式が使われます。一度共有した商品・Rate Plan・Rate Plan Chargeは削除できません。また、サブエンティティごとに有効化する通貨が異なる場合があるため、グローバルエンティティ側では各サブエンティティで使用するすべての通貨をあらかじめ有効化しておく必要があります。

② Accounts and Subscriptions

AccountとSubscriptionは、Zuora上で手動作成するか、API経由で作成します。Subscriptionは、紐づくAccountが属する正しいエンティティ側で作成する必要があります。Subscription番号は、Zuoraによる自動採番、またはエンティティごとに設定した一意のプレフィックスをあらかじめ付与する方法のいずれかで生成できます。

③ Catch Up Bill Run

サブエンティティへのデータ移行が完了した後、レガシーエンティティ側ですでに支払い済みだった過去のInvoiceを消し込むため、Catch-Up Bill Runを実行します。マルチエンティティのgo-live以前にレガシーエンティティ側で発行済みのInvoiceは、引き続きレガシーエンティティ側の記録として参照されます。プラス残高（Invoice）・マイナス残高（Credit）を問わず、未収残高はサブエンティティ側で単一のInvoice・Open Credit Balanceとして再作成されます。

④ Open Invoices

未収残高（未払いのInvoiceおよびOpenのCredit残高）は、新しいサブエンティティへ移行する必要があります。具体的には、未払いInvoice残高用と、マイナス金額として扱うOpen Credit残高用の、2本のスタンドアロンInvoiceを作成する方法で移行します。新しいサブエンティティ側では、これらのInvoiceに対して支払いを処理できます。

⑤ Accounting and Reporting

標準の共有レポートをそのまま実行したり、既存の共有レポートを編集してプライベートレポートとして保存したり、新しくカスタムレポートを作成したりできます。各エンティティは会計処理をそれぞれ独立して行い、会計コード（Chart of Accounts）もエンティティごとに個別に設定します。すべてのエンティティで似たような会計期間を使用しますが、会計期間の締め処理（クローズ）はエンティティごとに個別に行います。

データ移行プロジェクトの5フェーズ（Vision → Define → Build → Test → Deploy）

理想的な標準データ移行プロジェクトは、Vision・Define・Build・Test・Deployの5フェーズに区切られます。 本記事の「移行プロセスとステージ設計」で扱ったPlanning/Preparation/Migration/Post-Migrationとは別の切り口として、プロジェクトマネジメント寄りの視点でフェーズを整理したものです。

Vision

各プロジェクトの最初のフェーズです。このフェーズでは、データ移行コンサルタントが、キックオフを成功させるために必要な詳細情報を収集し、続くDefineフェーズに向けた準備を行います。

Define

データ移行コンサルタントが、データ移行ソリューション全体がどのように機能するかについて、おおまかな見通しを立てるフェーズです。データ移行チームは顧客とのキックオフセッションに注力し、顧客がデータ移行プロセス全体を理解できるようにします。このセッションの中で、これから移行するデータをZuoraのデータモデルにマッピングし、必要なテンプレートについて顧客に理解してもらいます。あわせて、顧客からの質問に答える機会にもなります。

Build

主要な作業が始まるフェーズで、計画が完了し、要件収集とタスクの記録が済んだ後に着手します。コンサルタントはロード仕様書（load specification document）とプロジェクトタスクリストの作成に取り掛かり、プロジェクトのニーズに合わせて必要な調整を行います。このフェーズでは、顧客がデータの抽出・変換に関する手順とガイドラインに従っているかを確認する必要があります。データ移行チームは定期的にデータスキャン作業を行い、顧客と認識をすり合わせて正しいアプローチを取れているかを確認します。すべてのロードドキュメントとプロジェクトタスクリストは、このフェーズの終わりまでに完成させておく必要があります。

Test

Buildフェーズで作成したファイル・手順をすべてテストするフェーズです。このフェーズの前提条件として、Subscriptionのテストを行う前にZuora側のProduct Catalogを完成させておく必要があります。go-liveまでに、フルロードとモックgo-liveを含む2サイクルのテストを完了させる必要があります。各サイクルの後には、完了状況を検証し、発見したエラーを報告します。

Deploy

プロジェクトの最終フェーズで、すべてのデータが顧客の本番環境へ移行されます。Go-Live時に実施する手順は、モックGo-Liveテストのときとまったく同じ手順にする必要があります。

Post-Deployment（デプロイ後の作業）： 各デプロイの後、コンサルタントはFinance Catch-up Bill Runシートに記入し、Invoiceの件数を記録し、（マルチエンティティのテナントの場合は）テナントごとの合計Invoice金額を入力する必要があります。

Catch-up Bill Run（CUBR）の2つの実行方法

CUBRは「T9 catch-up bill run」と「Regular bill run」の2通りの方法で実行できます。

• T9 catch-up bill run：InvoiceやInvoice Itemを一切生成せずにBill Runを実行する方式です。利用にはZuora Global Supportへサポートチケットを提出してテナント設定を有効化してもらう必要があり、Data Migrationチームの承認が必要です。T9 CUBRは、Invoiceを生成せずに過去のチャージをすべて自動的に無効化（nullify）します。一度有効化すると、T9 CUBRの設定を無効化することはできません。
  • Data Migrationチームの承認後、T9設定を有効化する
  • UI上で「catch-up bill run」オプションを選択する
  • Target dateとInvoice dateが両方とも正しいことを確認する。T9 CUBRの場合、Invoice date自体は（Invoice dateをトリガーとする処理がない限り）重要ではない
  • Catch-up bill runを実行する。この方式ではInvoiceは生成されない
• Regular bill run：通常のBill Runを通じてCUBRを実行し、InvoiceとInvoice Itemを生成する方式です。UIまたはAPIを使って、特定のバッチやチャージを対象にBill Runを生成できます。
  • 必要に応じてTarget dateとInvoice dateを設定する。Target dateはBill Runの終了時点を定義する重要な項目
  • 生成されたInvoiceをPost（確定）する
  • Invoiceを消し込む（write off）

CUBRで生成したInvoiceの消し込み方法

CUBRで生成したInvoiceを消し込む（write off）方法は3つあります。

• External Payments（外部支払い）：Invoice残高を消し込み、ダウンストリームの収益認識を調整するために使用します。複雑な調整の消し込みに向いており、顧客への返金処理にも利用できます。
• Standalone Credit Memos（スタンドアロンCredit Memo）：Advanced AR設定を有効化することで利用できます。複雑な調整や割引（discount）を扱う際に役立ちます。
• WriteOff API Call：API呼び出しでPost済みのInvoiceを消し込む方法です。本番の全量ロードに進む前に、この方法自体をテストしておく必要があります。Payment・Credit Memoなどの取引がすでにInvoiceに適用されている場合、そのInvoiceは消し込みできません。

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

基本の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	データオーナーを指定	変換・マッピングの責任者を明確にする

試験対策チェックリスト

本記事で扱った内容のうち、特に混同しやすいポイントをまとめます。

論点	押さえるべきポイント
移行できるオブジェクト	Payment Methods・Invoices・Accounts and Subscriptionsは移行対象。Product Catalogは移行対象外（Zuora側で新規作成）
Open Invoice残高を移行する理由	請求書番号や商品情報の引き継ぎではなく、移行後に支払いを回収できるよう現在の残高を引き継ぐため
Subscriptionの移行対象	過去のバージョンではなく最新のアクティブバージョンのみ
Amendmentオブジェクト	Zuoraへは移行しない（レガシー側に記録がないことが多く、必要データが揃わないため）
データ移行の4ステージ	Planning → Preparation → Migration → Post-Migration（何をするかに着目）
データ移行の5フェーズ	Vision → Define → Build → Test → Deploy（プロジェクト進行に着目）
移行ツールの現行主力	かつてはDeveloper Toolsが推奨だったが、現在の主力はData Loader
Mass Updaterの用途	会計コード更新、Revenue Scheduleの作成/更新/削除、為替レートインポート、一括支払いアップロードなど、Finance系の一括操作
CUBRの実行方法	T9 CUBR（Invoiceを生成しない）／Regular bill run（Invoiceを生成する）
CUBRのInvoice消し込み方法	External Payments／Standalone Credit Memos／WriteOff API Call の3種類
Cutover Date	「どこまでの履歴データを移行対象にするか」を決める基準日。決定はPlanningステージで行う
ZtoZ移行で非サポートのオブジェクト	Amendments・Payments・Invoices and Invoice Items・Refunds・Taxation Items・Revenue Schedules
Salesforceデータの扱い	分類上はAtypicalだが、Zuoraはすべての移行を推奨する例外オブジェクト

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