MIGRATION PATTERN｜オープン系
Javaフレームワークの移行・バージョンアップ
Struts 1.x・Seasar2・旧バージョンのJava EE で構築されたシステムを、Spring Boot と新しいJavaへ移行します。言語が変わらないぶん、現行を理解している方の知見をそのまま活かせるのがこの移行の特徴です。
Issueこの移行で問題になりやすいこと
Javaシステムのご相談で、実際に確認することの多い四点です。
Javaで動いているシステムは、「まだ動いているから」と後回しにされやすい領域です。ただし、サポートが終了したフレームワークは、脆弱性が公表されても修正が提供されません。この点が、他のレガシー移行とは異なる緊急性を持ちます。
サポート終了したフレームワーク
Struts 1.x や Seasar2 はすでに開発が終了しています。新たな脆弱性が見つかっても公式の修正は出ないため、自社で対処するか、フレームワークごと移行するかの二択になります。
ライブラリの依存が固まっている
古いフレームワークに合わせたライブラリ群が、そのバージョンでしか動かない状態です。一つ上げると他が壊れるため、個別のバージョンアップでは進まなくなっています。
自動テストが残っていない
移行の可否を判断する材料がない状態です。現行の振る舞いを確認する手段がないまま書き換えると、差分を見つけられません。
Applet・Flash に依存した画面
ブラウザ側がプラグインの対応をやめているため、すでに動かなくなっている画面です。「そのうち」ではなく、現に業務が止まっている状態からのご相談も承ります。
Scope対象となるJavaシステム
現行の世代によって、移行の重さと進め方が変わります。
現行がどの世代のJavaかによって、移行の重さが変わります。棚卸しの段階で、まずここを切り分けます。
| 現行 | 状況 | 移行先の例 |
|---|---|---|
| Struts 1.x | 開発終了。設定ファイルとActionクラスに処理が分散しており、画面遷移の全体像が把握しにくい状態になっていることが多い | Spring Boot ／ Spring MVC |
| Seasar2 | 開発終了。DIコンテナとO/Rマッパーが密接に結びついているため、段階的な置き換えの設計が必要 | Spring Boot ／ MyBatis・JPA |
| 旧 Java EE （J2EE・EJB2 など） | アプリケーションサーバに依存した構成。サーバ製品のサポート期限が移行のきっかけになることが多い | Spring Boot ／ Jakarta EE |
| Java Applet | ブラウザ側が対応を終了済み。すでに動作しない状態 | Web（HTML5・React・Vue.js） |
| Java 6 ／ 7 ／ 8 | フレームワークは変えずに、言語とランタイムのバージョンだけ上げる案件。ライブラリの依存解決が中心の作業 | Java 17 ／ 21（LTS） |
複数が混在している場合もございます。その場合は、業務上の重要度と改修頻度に応じて対象の優先順位をご提案いたします。
Approach移行方式の選択肢
言語が変わらないぶん、進め方の選択肢が広い領域です。
この移行の特徴は、言語が変わらないことです。現行システムを理解されている方がいらっしゃる場合、その知見をそのまま設計に活かせます。そのぶん、進め方の選択肢も広くなります。
| 方式 | 内容 | 適する場合 |
|---|---|---|
| バージョンアップのみ | フレームワークは維持し、Javaとライブラリのバージョンを上げる | 構成に大きな問題がなく、まずサポート期限の問題を解消したい場合 |
| フレームワーク移行 | Spring Boot などへ載せ替え、業務ロジックは保持する | サポートが終了したフレームワークを使っている場合。もっともご相談の多い形です |
| 段階的移行 ストラングラー方式 | 新旧を並行稼働させ、機能単位で順に新環境へ移す | 止められないシステムの場合。一度に切り替えるリスクを避けたい場合 |
| リビルド | 業務要件から作り直す | 現行の作りが業務の実態と合わなくなっている場合。移行ではなく新規開発として扱います |
段階的移行を選ぶ場合、新旧どちらでセッションとデータを持つかを先に決めておく必要があります。ここを曖昧にしたまま進めると、並行稼働の期間に不整合が生まれます。
Cautionこの工程で見落とされやすい点
| 見落とされやすい点 | 内容 |
|---|---|
| 先に自動テストを用意しないこと | 現行の振る舞いを確認する手段がないまま書き換えると、移行後の差分を見つけられません。移行対象の中核部分については、書き換えの前に回帰テストを整えることをお勧めします |
| ライブラリを一つずつ上げようとすること | 古いフレームワークに固定された依存関係は、個別に上げると連鎖して壊れます。依存の全体像を先に把握したうえで、まとめて決める工程が必要です |
| 設定ファイルに書かれた処理を見落とすこと | Struts の設定ファイルには画面遷移とバリデーションが書かれています。Javaコードだけを読んでも、業務の流れは再現できません |
| 文字コードと日付処理を後回しにすること | 古い世代のJavaと新しいJavaでは、文字コードの既定値や日時APIの扱いが異なります。帳票と外部連携で差分が出やすい箇所です |
| アプリケーションサーバ固有の機能に気づかないこと | 特定のサーバ製品でしか動かない実装が残っている場合、移行先で代替を設計する必要があります |
ExperienceJavaシステムに関する取り組み
Javaは当社の中核的な開発領域です。新規開発と保守の双方で継続的に扱っており、移行案件においても現行コードを読み解いて再設計する工程からご一緒しております。
公演チケット販売システムの開発・運用
Java8 ＋ VB.NET ・ AWS ／ Aurora PostgreSQL
一般ユーザー向けサイトをJava8で構築し、管理側アプリケーションはVB.NETで運用しています。データベースはAWS上のAurora／PostgreSQLです。
公演登録・座席設定から予約・発券・決済・会員管理までを扱うシステムで、Javaと他言語が混在する構成を運用してきた経験がございます。
フレームワーク移行の実績
Xamarin → .NET MAUI ・ 3人月 × 3ヶ月
医療用画像ビューアのモバイルアプリ二本を、開発が終了したXamarinから後継の.NET MAUIへ移行しました。DICOM画像の参照機能とチャット機能を対象に、業務機能を保ったままフレームワークだけを置き換える形で実施しています。
言語系統は異なりますが、本ページでご説明している移行と同じ性質の案件です。サポートが終了した基盤から後継へ、振る舞いを変えずに移す——Struts や Seasar2 からの移行で必要になる進め方と重なります。
対応領域：アプリ開発・単体テスト・総合テスト
対応できる作業範囲
現行資産の棚卸し（ソース・設定ファイル・依存ライブラリ・外部連携の一覧化）／現行業務仕様の文書化／移行方式の決定／回帰テストの整備／フレームワーク移行の実装／総合テストと受入支援。
まず棚卸しだけ、というご依頼も承っております。
※ 案件ごとの規模・期間の目安については、現行資産の構成をお伺いしたうえで個別にご提示いたします。
Structure誰が担当し、誰が責任を持つか
移行の可否と範囲を決める工程は、お客様と直接お話ししながら進める必要があります。この部分は日本法人の責任者が担当いたします。
| 項目 | 内容 |
|---|---|
| 現行資産の解析 | 技術者が実際に読み解き、現行の業務仕様として文書化します。運用されている方への確認と、実データとの突合も併せて行います |
| 要件の確定・設計の承認 | 日本法人（株式会社DEHA SOLUTIONS）が担当します。窓口は日本側で一本化しており、仕様のやり取りで齟齬が出ない体制です |
| 実装・テスト | 要件が確定したあとの工程を、開発拠点 DEHA VIETNAM（ハノイ・200名以上）が担います。CMMI Development & Services レベル3の評定を受けたプロセスと三層QAのもとで進めます。開発拠点 DEHA VIETNAM は ISO/IEC 27001:2022 の認証を取得しています |
| 責任の所在 | 契約の当事者は当社（日本法人）です。請負契約では成果物の完成について、準委任契約では業務の適切な遂行について、当社が責任を負います |
まずは無料レガシー簡易診断からご相談いただけます
移行をご判断いただく前の段階でも構いません。資産一覧をお送りいただくだけで、概算と移行リスクの見取り図をお返しします。ソースコードのご提供は不要です。その先の現行調査（As-Is分析）は、稼働中のシステムを変更しない読み取り専用の解析で、作業範囲とお見積りを着手前に確定いたします。
無料レガシー簡易診断を申し込む 現行調査（As-Is分析）についてFAQよくあるご質問
まだ動いているのですが、急ぐ必要はありますか。
動作している状態でも、サポートが終了したフレームワークは、脆弱性が公表されたときに公式の修正が提供されません。まず現行資産の棚卸しだけ先に行い、移行の規模と選択肢を把握しておく進め方もご提案できます。
フレームワークは変えず、Javaのバージョンだけ上げることはできますか。
はい。構成に大きな問題がない場合は、その進め方をご提案することもございます。ただしライブラリの依存関係によっては、フレームワーク側も同時に検討が必要になる場合があります。棚卸しの結果をもとにご提示いたします。
自動テストがないのですが、移行できますか。
そのような状態からのご相談も承っております。移行対象の中核部分について、書き換えの前に回帰テストを整える工程を含めてご提案いたします。移行の確認手段であると同時に、移行後も残る資産になります。
止められないシステムなのですが。
新旧を並行稼働させ、機能単位で順に移す段階的な方式をご提案できます。新旧どちらでセッションとデータを持つかを、着手前にお取り決めいたします。
費用の考え方・体制・品質保証について
費用の構成要素、プロジェクト体制と責任の所在、品質保証の仕組み、そして刷新を任せる相手を選ぶ観点については、モダナイゼーションのページにまとめております。Javaフレームワークの移行に限らず共通してご確認いただける内容です。
モダナイゼーション全体のご案内へレガシー刷新の進め方（全体） ／ 業務ロジック可視化・設計書復元 ／ 移行後の運用保守・AI活用 ／ レガシー刷新の導入事例
現行資産の棚卸しからご相談いただけます
サポート期限の確認、依存ライブラリの整理、移行方式の選択肢の提示まで。まずは現行の構成をお聞かせください。
お電話でのお問い合わせ 03-6260-6226平日 9:00–18:00