Softroad
  • contact
  • menu
qanda移行Q&A

移行の失敗例と解決策

システムの更新でも、失敗例は決して少なくありません。
システムリフォームは750回以上のシステム更新を行い、殆ど失敗例がありません。
他社の移行失敗例を説明することで、失敗を避ける対応策を提示します。

VBの.net化 失敗例と対策

状況

高い変換率を実現する為に無理なツール変換を行った。
OS等まで弄る基盤を導入したので、OSが不安定になり、バグ対応がとても難しくなった。
当社が火消に参加したにもかかわらず、納期が大幅に遅れてしまい、品質も悪かった。

再発防止策

移行先がおかしくなる程の、無理な自動変換を避けた方がいい。
安定したリホスト用ミドルウェア、何回も実証された変換ツール以外の利用は要注意。
保守性も守って移行した方が、問題が出る時に解決しやすい。

メインフレームOPEN化 失敗例と対策

状況

性能をきちんと考慮した移行を行わず、テストする時に性能問題が出たため、大きな移行方針転換になった。結果的に納期に間に合わず、移行が失敗した。

再発防止策

移行において、性能問題がよく発生する上に、簡単に解決できないケースも多い。
各種の移行性能問題をクリアしてきた、豊富な移行経験及び高い移行技術力を持つ会社を選択することは重要。
具体的な性能問題の発生理由と対応方法は移行性能問題のQ&Aをご参考下さい。

Oracleバージョンアップ 失敗例と対策

状況

業務知識を持つ保守会社に任せたが、技術問題が多数発生し、移行が大幅に遅れた。

再発防止策

一見簡単なOracleバージョンアップ、Javaのフレームワーク変更でも、簡単に対応できない問題が発生する可能性が高く、移行経験がないと、対処法がわからず、大幅に遅れる可能性が高い。
移行経験豊富な移行会社に依頼した方が無難。

大型リホスト 失敗例と対策

状況

予想外に手動対応しないと動かない部分は多いので、予算が大幅にオーバーし、技術検証は不合格になってしまった。

再発防止策

ホストの機能をミドルウェアで再現するのは難しいので、リホスト用ミドルウェアに不備が多い。
予算及び期間に余裕をもって、移行会社によるソース変換+リホスト用ミドルウェア開発会社によるソフト改善の両面からアプローチする。
リホスト以外に、よく利用され、確実性の高い言語変換、言語バージョンアップの選択肢もある。

大型メインフレーム画面系の高速開発ツールによる再構築失敗例と対策

状況

超高速開発ツールで再開発しようとしたが、工数は予想より大きくオーバーし、開発が頓挫した。

再発防止策

システムの移行は、新規開発と違う開発の専門分野である。
超高速開発という新規開発の手法は、大型システムの移行に向かない。
詳細理由は移行によくある誤解のNo2をご参考下さい。

パッケージでの再構築案件 失敗例と対策

状況

パッケージで大規模基幹システムを再構築したので、Fit&Gapが困難で、本番になった時に沢山の機能が実業務に合わなく、会社の運営が厳しくなった。

再発防止策

ビックバン的なスクラッチ開発、パッケージ導入を慎重に考え、移行+機能変更で確実に開発した方がいい。

CONTACT コンタクト

システム移行に関するお問い合わせは
こちらからどうぞ。