LEGACY-MIGRATION-PATTERNSレガシーマイグレーションパターン

マイグレーションパターン

メインフレーム・オフコンのオープン化

東証上場TOP200社中、60社以上に採用されるシステムリフォーム

出光興産様、日産自動車様、日本航空様、ソフトバンク様、京セラ様、TOTO様、村田製作所様、石油資源開発様、ユニチカ様、ニトリ様、TOPPANグループ様、デンソー様、リコージャパン様、日東電工様、東建コーポレーション様、大同生命保険様、トヨタシステムズ様、みずほリサーチ&テクノロジーズ様、岡三情報システム様、関電システムズ様、JALデジタル様、アイテック阪急阪神様、西鉄情報システム様、キリンビジネスシステム様、JFEシステムズ様、コベルコシステム様、東レシステムセンター様、ブリヂストンソフトウェア様、テックインフォメーションシステムズ様、NECグループ様、NTTグループ様、日立システムズ様、TDI様、パーソルクロステクノロジー様、ユニシステム様、ワクコンサルティング様　他多数

メインフレーム・オフコンのお客様事例講演

伊藤忠食品様

日産自動車様

ユニチカ様

出光興産様

マツダ様

ソフトバンクBB 様

お客様	講演テーマ	講演イベント
京セラコミュニケーションシステム株式会社様	システムリフォームで実現したレガシーシステム刷新　～DXの推進に向けて～	日経BP 2025年の崖講演
伊藤忠食品株式会社様	メインフレームOPEN 化の取組	JUASスクエア2024
セントラルフルーツ様	極めて厳しいプロジェクト環境の中、停止が許されない流通システムを短期間でオープン化	Gartner Symposium2023
株式会社村田製作所様	IT部門が攻めの姿勢で経営リスクを回避！システムリフォームによるレガシーからの脱却	BSIAシンポジウム2019
日産自動車株式会社様	IBMメインフレーム2台・6システムの短期間並行リフォーム	BSIAシンポジウム2018
日産自動車株式会社様	試作基幹システムの先進的なリフォーム	ガートナーアプリケーションサミット2017
ユニチカ株式会社様	基幹システム刷新後の柔軟性・拡張性を実現する　「システムリフォーム（ユニチカモデル）」の全容	Gartner Symposium ITxpo 2017
出光興産株式会社様	新しい開発モデルへの挑戦　～出光興産のシステムリフォーム事例～	JUAS Future Aspect 2014
マツダ株式会社様	マツダがリフォーム事例を語る！　システム刷新の主流　システムリフォーム	Gartner Symposium2014
ソフトバンクBB株式会社様	BB販売管理システムシステムリフォーム	Gartner Symposium2014

メインフレーム・オフコンオープン化の大きな懸念

・知識不足：

お客様と既存ベンダーのOPEN化経験不足より、企画、ベンダー選択などが難しい。

・投資制約：

付加価値を実現しにくいOPEN化での予算確保、担当要員確保に苦労する。

・リスクへの懸念：

既存の基幹システムが重要で安定しているので、品質への要求が高いが、失敗の噂が多く、不安。

メインフレーム・オフコンオープン化の本質

メインフレーム・オフコンのオープン化では、究極な高品質と低コストが要求されているので、高度な変換・テストツールでの自動工場生産が必要。
※オフショアの低単金、業務知識の弱い大量技術者投入でも、コストと品質問題をカバーできない。

→25年にわたる、約1,000件の移行実績に基づき、最適な解決策をご提示します。

メインフレーム・オフコンオープン化の選択肢

メインフレーム・オフコンのオープン化は、対象システム、お客様の実情に合わせて、以下のパターンを選択する。

選択肢	将来の拡張性	移行コスト	プロジェクトリスク
スクラッチ再開発	◎ 高	× 高	× 最大
全面Java化	◎ 高	△ 中	○ 中～低
レガシー言語 OPENバージョン化	△ 維持	◎ 低	◎ 最小
ハイブリッド化	○ 中～低	○ 中～低	◎ 低

・

２０年以上の経験を持つトップレベルの移行会社なら、全面Java化のリスクがとても低く、コストはレガシー言語OPENバージョン化より、３～４割高い。

・

ハイブリッド化では、重要な機能、よく仕様変更される機能、画面系などをJavaに移行することが多い。

・

C#に移行するケースが少なく、ツールはまだ弱い。

確実な移行

1. 豊富な全工程請負型工場生産の実績が必須

必須な理由

・

複数のレガシー言語、IF、帳票、DB、文字コードなどの技術要素がとても多く、磨かれたツールと経験豊富な専門移行技術者・管理者が必要。

・

ユーザーはベンダー能力を確認することが困難で、豊富な全工程請負型実績は一番確実な確認ポイント。

当社の実績

・

25年間、970件以上の移行で得られた全工程請負型実績。

・

550名以上の移行専門技術者体制と1700 名以上のパ一卜ナ一体制。

▶ 累計30以上のお客様講演事例

落とし穴！

・

技術者の多い大企業なら安心だと思われるが、長年の移行経験を持つ専門技術者しか役に立たない

・

オフショア会社のマイグレーション経験数が多い傾向だが、多くは技術者提供（準委任）であり、全工程請負型実績が乏しい

2. 言語仕様の徹底把握とほぼ100%AI自動変換

当社変換ツールの特徴

ほぼ100％自動変換によるPureJava、OPENデータと性能。

落とし穴！

・

大多数のベンダーは、既存と移行先の詳細言語仕様、その他仕組みを把握しきれず、ツールの知能も低く、JaBOLにしか変換できなく、品質と性能のリスクが高く、技術者の介入でコストも高い

・

オフショア会社の移行経験が乏しく、わかりにくいレガシー仕組みではJavaで無理にレガシー基盤機能を作るしかなく、修正困難箇所が散在することになり、移行とその後の保守のリスクが高い

3. 確実な自動テスト

当社テストの特徴

① 100％カバー率の実現

② 大量の本番営業日再現・新旧比較で、最高の安心を実現

落とし穴！

・

言語等詳細技術仕様をきちんと把握しない移行業者が殆どで、品質は顧客提供データ頼みになる

・

総合テストにおいても、テストの自動化や問題原因特定まできちんと対応できない業者が多く、顧客の負担が大きく、テスト量も大幅に制限される

・

殆どのオフショア会社に全網羅テストツールがなく、業務知識も弱く、品質確保が困難

4. 厳格な本番データ移行

厳格な本番データ移行をしないと、データ間違いにより本番で大きな問題が発生します。

当社本番データ移行

・

枯れたツールで対象データを漏れ・重複なく洗出し、OPENのフォーマットと構造に自動移行する。

・

独自のツールで、データ移行の結果を徹底的にテストする。

落とし穴！

多数の移行ベンダーは「データ移行結果テストツール」を持たないので、その有無の確認が必要

大規模案件の安心な移行

主な挑戦

・

移行の確実性と高品質が必須。
※安定の既存と比較されるし、バグの密度が低くても規模が大きい分、影響が大きい。

・

大きな投資と自社リソースの確保が難しい。
※OPEN化の為のリソース確保が難しい。

対応策

・

段階的な移行（石橋を叩いて進む)
棚卸→PoC→小さい機能の移行→中規模機能の移行→固定体制で時間をかけて、確実に開発。

・

複数移行パターンの併用
重要、仕様変更が頻繁なサブシステムはJavaに移行するが、塩漬機能はOPENCOBOLなどに移行し、Javaへの移行より、３～４割のコストダウンを実現する。

・

レベルの高い移行ベンダーを選んで、高い自動化率の元に低コスト・高品質の実現

落とし穴！

・

難しい移行だからこそ、相手企業の規模、単金で選ぶと失敗するリスクがとても高い。全工程一括請負の移行を１０年間以上やってきた移行専門技術者が開発チームの何割を占めるかが重要

・

並行運用を長く設けても、ユーザー負担が高く、全量データ比較されない場合が多くリスクが高い

・

段階移行では、複数回移行、既存とOPEN化された部分の結合もあり、移行経験への要求が高い

モダナイゼーション

1. モダナイゼーションの基本

・PureJavaの実現：

Javaプログラムの中に大量のレガシー要素を混入させてはいけない。特に変数までCOBOL化、Javaで作るマルチレイアウトの仕組みなどを無くすこと。

・OPENデータの実現：

RDBのデータ構造、CSVに移行し、不可視データなどのレガシー要素を無くすこと。

・ソース統一性の実現：

レガシー文法・仕組みの移行でバラツキが出たら、保守性への影響が大きい。

落とし穴！

ストレートコンバージョンによるJABOL

・

ほぼすべてのレガシー技術要素をJavaクラスで置換されるので、移行後もレガシーと同じように動く。レガシーとJava両方の技術を把握しないと、保守できず、データ分析が難しくなる。移行後の保守でバグも出やすい

手動作業による問題

・

品質が悪く、ソースコードの統一性も悪い

・

マルチレイアウトなどの複雑なレガシー基本機能を利用している部分の解析が難しく、結果的にJavaでレガシー要素を作りこむことになり、修正困難な箇所は散見される

2. AI時代に必須なAIネイティブ

移行後、AI コーディング・AI データ分析が適用できます。

仕様提示でAIコーディング

チャット指示でのデータ分析

落とし穴！

AIネイティブに移行をしないと、3年以内に、当たり前になるAIコーディングとAIデータ分析が利用できず、システムはまたレガシーになってしまう

3. モダナイゼーションで同時推進するシステム改善

・セキュリティ機能導入
・CI/CD、コンテナなどの導入
・データ分析基盤、ワークフロー、RPA、WEB連携などの導入
など

落とし穴！

改善要望は移行で実施可能なものなら、移行した方が良い。移行後に開発するなら、コストが高く、リスクが高い

低コスト

アプリケーション移行のコストだけではなく、以下の費用も確認する。

・お客様作業：

特に多数のベンダーが苦手な総合テスト、品質保証は要確認。全工程請負型がベスト。

・保守のランニングコスト：

特にベンダーロックの可能性は要確認。

・インフラランニングコスト：

きちんとOPENに移行しなければ、マシン負荷がとても高くなる。

移行付属改善

ユーザー業務の大半はほとんど変わらず、一部だけの改善で大きな業績向上につながります。
コストの高い再構築よりモダナイゼーションを選んで、節約した大半のコストと時間を改善に注ぎ込むことをお勧めします。

1. 業務改善の極意

2. 保守改善の極意

保守側も、保守性向上により節約したIT予算により、機能改善・技術力向上といった好循環につながります。

3. 世界トップIT情報の提供

弊社のお客様を、弊社講演・展示を行うIT業界トップレベルのイベント(日本・アメリカ)にご招待し、最新のIT情報を提供させて頂いております。
※大きな実績を残したお客様にご講演頂くことにもなっております。

4. その他移行付属改善

移行することで下記改善効果も期待できます。
・スリム化
・DX基盤作り
・仕様明確化の促進
・機能改善

ソフトロードのメインフレーム・オフコンオープン化の主なパターン

OSの主要変換パターン

富士通メインフレーム

IBMメインフレーム

日立メインフレーム

NECメインフレーム

UNISYSメインフレーム

富士通オフコン

IBMオフコン

日立オフコン

NECオフコン

MSP・XSP

OS/390・Z/OS・Z/VM

VOS3・VOS1

ACOS4

OS2200・MCP

ASP

IBMi(OS400)

VOSK

ACOS2

➔

Linux

Windows

言語主要変換パターン

COBOL

RPG

PL/I

NATURAL

APL

IDLⅡ

EASY PLUS

Fortran

アセンブラ

➔

Java

OpenCobol化

バージョンアップ

.NET

など

DBの主要変換パターン

VSAM/ISAM/VSAS

ADABAS

IMS/DB

AIM

XDM/RD、XDM/SD

RIQS/RIQSIIなど

DB2

➔

Oracle

SQLServer

DB2

PostgreSQL

弊社セミナー・講演会について

2026年4月8日（水）～4月10日（金）Japan IT/DX Week 春2026に出展いたします。

2026/2/19 BIPROGY社主催オンラインセミナー「もう迷わない！基幹システム刷新の成功ロードマップ」にて講演しました。

類似移行事例の抜粋

製造業生産・販売・アフターサービスなどIBMメインフレーム２台の６つシステム

開発工程: 棚卸、移行設計、UI設計、ソース移行～総合テスト、運用テスト支援、本番移行
システムリフォーム情報
既存システム規模: COBOL：2,487KL、JCL：545KL、NATURAL：429KL、PL/I：2,156KL、ASM：35KL、帳票：781本、画面：1,572本
開発期間: 20ヶ月（※各システムの移行は１年間ぐらいで実施しました。）

開発言語	COBOL ➡ Java
COBOL ➡ MF COBOL
NATURAL ➡ Java
PL/I ➡ MF PL/I
JCL ➡ Java+XMLファイル
ASM ➡ MF COBOL
データベース	ADABAS ➡ SQL Server
サーバOS	OS/390 V2 ➡ Windows Server 2012

製造システム

開発工程: 棚卸、移行設計、仕様書再生、UI設計～移行テスト、総合/運用テスト支援
システムリフォーム情報
既存システム規模: COBOL：141.5KL、PL/I：37.2KL、JCL：44.8KL
開発期間: 13ヶ月

開発言語	COBOL ➡ Java
PL/I ➡ Java
JCL ➡ Shell
データベース	VSAM ➡ Oracle
サーバOS	富士通ホスト ➡ Linux

新基幹会計システム※クラウドへ移行

開発工程: 棚卸、移行設計、ソース移行～移行テスト、仕様変更、総合テスト、運用テスト支援、本番移行
システムリフォーム情報
既存システム規模: MED、MAP：11.9KL、COBOL：1,934.2KL、JCL：751.3KL、ASM：3.8KL、CLIST：1.7KL、COPY：41.7KL、ユーティリティー：50個、マクロ：4KL
開発期間: 30ヶ月

開発言語	COBOL ➡ Java11
MED、PSAM ➡ HTML5.0（画面定義体）
JCL、マクロ、CLIST ➡ Java11+XMLファイル
ASM、ユーティリティー ➡ Java11
データベース	VSAMファイル ➡ SQL Server 2019
ファイル	ファイル(PS、DAM、PO) ➡ Linux標準ファイル
サーバOS	XSP ➡ Red Hat Enterprise Linux 8.4(AWS)

コンピュータ集計処理システム

開発工程: 棚卸、移行設計、ソース移行～移行テスト、総合/運用テスト支援、本番移行支援
システムリフォーム情報
既存システム規模: IDLⅡ：775.9KL、COBOL：386.8KL、COBOLS：49KL、HPL：9.8KL、JCL：327.3KL
開発期間: 36ヶ月

開発言語	IDLⅡ、COBOL、COBOLS、HPL ➡ Java
JCL ➡ Java+XMLファイル
データベース	ADBS/RIQS ➡ SQL Server 2016
サーバOS	ACOS4 ➡ Windows Server 2016

次期基幹システム

開発工程: 棚卸、移行設計、ソース移行～移行テスト、総合/運用テスト支援
システムリフォーム情報
既存システム規模: COBOL：520KL、ASM：0.9KL、JCL：178.5KL
開発期間: 11ヶ月

開発言語	YPS COBOL ➡ Java
ASM ➡ Java
データベース	NDB+RDB+VSAM ➡ Oracle 12c
サーバOS	富士通ホスト ➡ RHEL6

原価管理システム

開発工程: 棚卸、移行設計、仕様書再生、ソース移行～移行テスト、総合/運用テスト支援
システムリフォーム情報
既存システム規模: COBOL：104.3KL、COBOLS：124.5KL、COBOLX：7.7KL、DATASSF：5.0KL、IDLⅡ：391.1KL、RPG：1.4KL、JCL：431.5KL、マクロ：10KL
開発期間: 20ヶ月（※POCを含む）

開発言語	COBOL、COBOLS、COBOLX、IDLⅡ、RPG、マクロ ➡ Java
開発言語	JCL ➡ KShell
データベース	ADBS ➡ Oracle
データベース	VSAS/RIQS ➡ Oracle
サーバOS	ACOS4 ➡ Linux

マイグレーションパターン

メインフレーム・オフコンのオープン化

メインフレーム・オフコンオープン化の大きな懸念

メインフレーム・オフコンオープン化の本質

メインフレーム・オフコンオープン化の選択肢

確実な移行

大規模案件の安心な移行

モダナイゼーション

低コスト

移行付属改善

ソフトロードのメインフレーム・オフコンオープン化の主なパターン

弊社セミナー・講演会について

類似移行事例の抜粋

マイグレーションパターン

CONTACT コンタクト