LASSIC Media らしくメディア
Teradata移行はなぜ手間がかかるのか？移行先との3つの違い
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- Teradata移行は、データに加えてSQLや取り込みの処理まで移行先に合わせ直す作業です。
- 比較や計算のルールが違うと、エラーを出さずに集計の件数や金額だけが変わることがあります。
- 最初は小さなデータマートから移し、新旧の集計結果を照らし合わせる手順を固めることが大切です。
※ 本記事は2026年11月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
Teradataの機器の更新時期が近づいているが、クラウドへ移すと何がどれだけ変わるのか見当がつかない。見積もりを取ったら、データを移すだけの話ではなかった——。オンプレミス（自社の設備）でデータウェアハウス（分析用に社内のデータを集めたデータベース）を長く運用してきた会社では、こうした戸惑いが起こりがちです。Teradata移行とは、Teradataに置いてきたデータと、その上で動く集計や取り込みの処理を、クラウドへ移すことを指します。
クラウドへ移すと、保存と計算の資源を必要に応じて増減でき、機器の更新に追われることもなくなります。ただし万能ではなく、Teradata固有の書き方やルールに頼った処理は、移行先でそのまま同じ結果になるとは限りません。本記事では、情報システムの担当者に向けて、移行に手間がかかる理由、移行先の選択肢と移行の道具、進め方、そして外部に頼むときに確認したい点を整理します。
目次
Teradata移行とは
Teradata（テラデータ）は、大量のデータを多数の処理装置で並列に計算するデータウェアハウスの製品です。Microsoftの移行ガイドは、従来のTeradataは自社の設備に専用のハードウェアで置かれることが多く、構成を増強するには追加の機器と、時間のかかる再構成やデータの入れ直しが要ると説明しています。*1
- データ：テーブルと、残しておく過去のデータ
- SQL：集計や帳票のための問い合わせ、ストアドプロシージャ（データベースの中に置く処理のまとまり）
- 取り込みの処理：業務システムからデータを集めて加工し、格納する夜間のバッチ（ETL）
- 使う側の仕組み：BIツール（集計結果をグラフや表で見る道具）や帳票の接続先
移行先には、Teradata自身のクラウド版と、ほかの会社のクラウドデータウェアハウスの2通りがあります。TeradataはAWS・Microsoft Azure・Google Cloudの上で使う形や、オンプレミスとクラウドを組み合わせる形を用意しています。*6 同じ製品のまま置き場所を移すか、別の製品へ移るかで、作業の中身が変わります。
なぜ移行に手間がかかるのか
別の製品へ移る場合、手間の多くはデータを運ぶ作業よりも、SQLと周辺の処理を移行先に合わせる作業から生まれます。GoogleのBigQuery向けの移行ガイドは、Teradataと移行先とでSQLの書き方や型がどう違うかを項目ごとに並べています。*2
| 違い | Teradataでの例 | 移行で起きること |
|---|---|---|
| Teradata固有のSQL | 集計の結果を絞り込むQUALIFY句など、Teradataが拡張した書き方 | 移行先の書き方に直す。変換の道具が助けになるが、変換後の確認は人が行う |
| 比較と計算のルール | 大文字と小文字を区別しない比較、末尾の空白を無視する比較、小数の丸め | 同じSQLでも、結果の件数や金額が変わることがある |
| 周辺の処理 | BTEQ（命令をまとめて流すスクリプト）、MultiLoad・TPumpによる取り込み | 夜間のバッチや取り込みの仕組みを作り直す |
見落としやすいのは2つめです。BigQueryの移行ガイドは、Teradataでは大文字と小文字だけが違う文字列を同じと判定できる一方、BigQueryは常に区別すると説明しています。末尾の空白も、Teradataは無視することがありますが、BigQueryは文字の一部として扱います。*2 どちらもエラーにはならず、集計の件数だけが変わるため、移行の手間は書き換えよりも確認の側で膨らみがちです。
移行先の選択肢と移行の道具
移行先ごとに、提供元が移行の道具や手順書を用意しています。どれが合うかはデータの量やいま使っているクラウドで変わるため、ここでは事実の違いだけを並べます。
| 移行先 | 提供元が用意しているもの | 主に移せるもの |
|---|---|---|
| Teradataのクラウド版 | AWS・Microsoft Azure・Google Cloudの上で使う形と、オンプレミスとの組み合わせ*6 | 同じ製品のまま置き場所を移す |
| BigQuery（Google Cloud） | BigQuery Data Transfer Serviceと移行エージェントによる転送、SQLの一括変換*3 | テーブルの定義、データ、SQL |
| Amazon Redshift（AWS） | AWS Schema Conversion Tool（AWS SCT）による変換*4 | テーブルの設計、SQLなどの処理、アプリケーションのコード |
| Snowflake | SnowConvert AIによる変換*5 | テーブル、ビュー、ストアドプロシージャ、BTEQ、MultiLoad、TPump |
SnowConvert AIは、自動で直せなかった差をエラーや警告として示します。*5 どの道具も、変換した結果は人が確かめてから使う前提です。Snowflakeの導入支援についてはSnowflake導入支援の選び方で扱っています。
移行の進め方
Microsoftの移行ガイドは、移行を準備・移行・移行後の3段階に分け、最初は小さく単純な範囲から始めることを勧めています。最初の対象には、業務の処理ではなく分析や帳票の用途で、データの形をほぼそのまま移せるデータマート（部門ごとに切り出した分析用のデータ）が向いているとし、量は1〜10TBが一般的としています。*1 これを4つのステップに置き直すと次のとおりです。
- ステップ1：移すテーブル・SQL・スクリプト・取り込みの処理の一覧を作り、移す範囲を決める
- ステップ2：最初に移すデータマートを1つ選ぶ
- ステップ3：テーブルとデータを移し、SQLと取り込みの処理を書き換える
- ステップ4：新旧の環境で同じ集計を流し、件数と金額を照らし合わせる
大切なのはステップ4です。Microsoftのガイドも、移行後の段階でアプリケーションや集計の道具を試験し、処理の速さを測って調整することを挙げています。*1 最初のデータマートで照合の手順を固めておけば、残りの範囲を移すときの型として使えます。データ基盤全体の費用の考え方はデータ基盤構築を外注する費用と進め方にまとめています。
外部に頼むときに確認しておきたい点
Teradataの移行を外部に頼むときは、データを運ぶ作業だけで見積もりを比べないことが大切です。手間の多くはSQLの書き換えと結果の確認にあるため、次の点を依頼の前に確かめておきます。
- 棚卸しの範囲：テーブル、SQL、BTEQのスクリプト、取り込みの処理のうち、どこまで数えてから見積もるか
- 変換の進め方：どの道具で変換し、自動で直せなかった箇所を誰がどう直すか
- 結果の照合：新旧で同じ集計を流し、件数と金額のずれをどの基準で合格とするか
- 切り替えの段取り：新旧を並行して動かす期間と、いまのTeradataを止める時期
- 移行後の運用：クラウドの利用料の監視や、利用者の権限の管理を誰が受け持つか
特に照合の基準は、着手の前に決めておきたい点です。大文字と小文字や末尾の空白の扱いをTeradataに合わせるのか、移行先の扱いに揃えて帳票の側を直すのかで、書き換えの量が変わります。この判断は委託先に任せきりにせず、帳票を使う部署と一緒に決めておきます。
まとめ：Teradata移行で確かめておきたい3つの点
Teradata移行を進めるうえで、確かめておきたい点は3つに整理できます。第一に、テーブルだけでなくSQLや取り込みの処理まで一覧にして、移す範囲を決めること。第二に、比較と計算のルールの違いをどちらに揃えるか先に決めること。第三に、小さなデータマートから移し、新旧の集計結果を照らし合わせる手順を固めることです。この3点を踏まえておけば、「移行は終わったのに、月次の帳票の数字が合わない」という事態を避けやすくなります。移行の進め方や照合の手順に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
Teradataのクラウド版へ移すのと、別の製品へ移すのは何が違いますか
Teradataのクラウド版は、AWS・Microsoft Azure・Google Cloudの上で同じ製品を使う形です。*6 製品が変わらないため、SQLを別の製品の書き方に直す作業は生じません。
移行のあいだも、いまのTeradataを使い続けられますか
一般には、新旧の環境を並行して動かしながら切り替えます。Microsoftの移行ガイドは、移す対象のテーブルをいったんクラウド上の仮想マシンに置いたTeradataへ写し、以降の作業をクラウドの中で進めることで、元のシステムへの影響を抑える方法を紹介しています。*1
移行の期間や費用はどう決まりますか
データの量よりも、書き換えるSQLやスクリプトの数と、結果を照らし合わせる手間で大きく変わります。まず棚卸しで数を把握し、最初のデータマートで手間を測ってから全体を見積もると、ぶれを抑えられます。
Teradataからクラウドへの移行のご相談
Teradataの棚卸しから、SQLと取り込みの処理の書き換え、新旧の結果の照合、切り替え後の運用まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：Microsoft Learn「Design and performance for Teradata migrations」（Azure Synapse Analytics）（https://learn.microsoft.com/en-us/azure/synapse-analytics/migration-guides/teradata/1-design-performance-migration）。出典：従来のTeradataがオンプレミスの専用ハードウェアに置かれること、構成の増強に追加の機器と再構成が要ること、準備・移行・移行後の手順、最初の移行対象とその量（1〜10TB）、仮想マシン上のTeradataを使う移行の記述を参照（2026年11月確認）
- *2 参考：Google Cloud「Teradata SQL translation guide」（BigQuery）（https://cloud.google.com/bigquery/docs/migration/teradata-sql）。出典：TeradataとBigQueryのSQLの違い（QUALIFY句、大文字と小文字・末尾の空白の比較、小数の丸め、BTEQ）の記述を参照（2026年11月確認）
- *3 参考：Google Cloud「Teradata to BigQuery migration: Overview」（https://cloud.google.com/bigquery/docs/migration/teradata-overview）。出典：BigQuery Data Transfer Serviceと移行エージェントによるテーブルの定義とデータの転送、SQLの一括変換、TPTとJDBCによる抽出方法の記述を参照（2026年11月確認）
- *4 参考：AWS「Connecting to a Teradata Data Warehouse with the AWS Schema Conversion Tool」（https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Source.Teradata.html）。出典：AWS SCTでTeradataのスキーマ、コード、アプリケーションのコードをAmazon Redshift向けに変換できることの記述を参照（2026年11月確認）
- *5 参考：Snowflake Documentation「SnowConvert AI – About」（https://docs.snowflake.com/en/migrations/snowconvert-docs/general/about）。出典：変換の対象（テーブル、ビュー、ストアドプロシージャ、関数、BTEQ、MultiLoad、TPump）と、差をエラーや警告として示す仕組みの記述を参照（2026年11月確認）
- *6 参考：Teradata「Deployment Options」（https://www.teradata.com/platform/deployment）。出典：AWS・Microsoft Azure・Google Cloudでの利用、オンプレミスとのハイブリッド構成の記述を参照（2026年11月確認）
