オフコン移行先の比較|保守終了までに決めることとリプレイスの進め方

オフコンのリプレイスで最初に決めるべきなのは、移行先の製品ではなく「いつまでに、どの業務を、どの形で移すか」です。移行先は、延命・リホスト・リライト・パッケージ・SaaS・再構築のどれか一つを選ぶのではなく、業務ごとに組み合わせて比べます。この記事では、メーカー公式発表で確認できた保守終了の情報、自社の機種の期限を確かめる手順、移行先の比較表、見積もり前に用意する現行資産の一覧、保守終了から逆算したスケジュール例、オフコン特有の移行の難しさを、大手コンサルティングファーム出身の専門家の知見をもとに解説します。
- メーカー公式発表で確認できるオフコン関連の販売・保守終了時期
- 自社の機種のサポート期限を確かめる5つの手順
- オフコンの移行先6パターンの比較(向くケース・注意点・業務改善の余地)
- 見積もり・提案依頼の前に用意する現行資産の一覧
- 保守終了から逆算したスケジュール例と、オフコン移行特有の3つの難しさ
オフコンのリプレイスが避けられなくなっている理由
オフコン(オフィスコンピュータ)は、販売管理・在庫管理・給与計算などの基幹業務を、専用のハードウェアとOSで動かしてきた業務用コンピュータです。止まらず、速く、長く使えるため、地方の中小企業では今も現役で使われていることがあります。富士通は1984年にオフコン「FACOM Kシリーズ」の国内提供を始め、40年以上にわたって販売管理や生産管理などのオフコンシステムを支えてきたと説明しています。
一方で、メーカー側では販売・保守の終了が進んでいます。富士通グループ(エフサステクノロジーズ)は、オフコンのモダナイゼーション(新しい環境への移行)を2031年3月末までに完了するよう推進する方針を公表しています。公式発表で確認できた主な時期は次のとおりです。
| 対象 | 内容 | 時期 |
|---|---|---|
| PRIMERGY 6000(本体装置) | 最終機種(/80B)の販売終了 | 2018年3月 |
| Cloud Service for オフコン | 新規販売の終了 | 2026年3月31日 |
| Cloud Service for オフコン | サービス提供の終了 | 2031年3月31日 |
| ASP ほか関連ソフトウェア | 販売中止(Kシリーズ端末エミュレータ等は2030年3月31日) | 2026年3月31日 |
| ASP ほか関連ソフトウェア | 保守中止 | 2031年3月31日 |
※エフサステクノロジーズ(富士通グループ)の公式ページ「Cloud Service for オフコン サービス提供終了までのご案内」「販売終了した製品」、富士通のプレスリリース(2025年3月21日)に基づきます(2026年11月確認)。製品・版数によって時期が異なるもの、未定のもの(例:PowerRDBconnector V3.2)があります。オンプレミスで使っている本体装置の保守期限は、上の表には含まれていません。契約内容とあわせて販売元に確認してください。
富士通は同じ2025年3月21日のプレスリリースで、資産分析・可視化、COBOL資産の変換、業務パッケージへの移行、SaaSを組み合わせた再構築など、オフコン向けのモダナイゼーションサービスを体系化したと発表しています。メーカー自身が「同じものを動かし続ける」のではなく、移行を前提にした支援へ軸足を移していることがわかります。
他メーカーの機種については、公式発表で終了時期を確認できなかったため、この表には載せていません。自社の機種については、次の手順で確認してください。
自社の機種のサポート期限を確かめる5つの手順
「まだ動いているから大丈夫」と思っていても、保守契約の更新時に初めて終了を知らされることがあります。期限は、ハードウェア・OS・周辺ソフトで別々に決まっていることに注意してください。
- 機種名・型番・OSの版数を控える
本体の銘板、保守契約書、導入時の納品書から、機種名・型番・OSとその版数を書き出します。 - 保守契約書の範囲と期限を確認する
ハードウェアの保守、OS・ミドルウェアの保守、アプリケーション(自社向けに作ったプログラム)の保守が、それぞれ誰との契約で、いつまでかを確認します。 - メーカー・販売店に書面で照会する
「ハードウェア保守の終了時期」「交換部品の供給見込み」「OS・ミドルウェアの保守終了時期」「延長保守の有無と条件」を、型番を添えて問い合わせ、回答をメールなど記録に残る形でもらいます。 - 周辺機器・周辺ソフトも確認する
端末エミュレータ、帳票用プリンタ、他システムとのデータ連携ソフト、端末として使っているパソコンのOSなど、オフコンにつながっているものの期限も同じように確認します。本体より先に周辺が終わることがあります。たとえばWindows Server 2016の延長サポートは2027年1月12日(米国時間)に終わります。 - 一番早い期限を「実質の期限」にする
確認した期限のうち、最も早いものを社内の計画の基準にします。メーカー以外の保守サービスで延命できる場合も、部品の確保や対応範囲の条件を確認したうえで、移行までの「つなぎ」として扱います。
| 確認対象 | 記入する項目 | 記入例 |
|---|---|---|
| 本体装置 | 型番/保守契約先/保守期限/部品供給の見込み | 型番〇〇/販売店A/2028年3月/回答待ち |
| OS・ミドルウェア | 名称と版数/保守期限 | OS 〇〇 V〇/2031年3月 |
| 端末エミュレータ・印刷 | 製品名/販売・保守期限 | 端末エミュレータ V〇/販売2030年3月・保守2031年3月 |
| 端末・周辺サーバー | OSとサポート期限 | 連携用サーバー Windows Server 2016/2027年1月 |
| アプリケーション保守 | 保守契約先/担当者の在籍状況 | 地元ソフト会社B/担当者は2名 |
※記入例は説明用の例です。実際の期限は自社の製品・契約で確認してください。
オフコンの移行先6パターンの比較
移行先の選択肢は大きく6つです。ポイントは、どれか一つを全業務に当てはめないことです。会計や給与は標準的な製品に、独自の受注方式や原価計算はプログラムを活かす、というように業務ごとに組み合わせる方が、費用と業務改善のバランスがとりやすくなります。
| パターン | 中身 | 向くケース | 注意点 | 業務改善の余地 |
|---|---|---|---|---|
| ①延命 | メーカーのクラウドサービスや第三者保守で、今の仕組みを使い続ける | 移行準備の時間を稼ぎたい | 問題の先送り。期限のあるサービスが多い | ほぼなし |
| ②リホスト | 既存のプログラム(COBOLなど)をほぼそのまま、Windows・Linuxなどの環境で動かす | 業務ロジックに独自性があり、短期間で移したい | 古い仕組みと属人化はそのまま残る | 小さい |
| ③リライト(変換) | 既存プログラムを別の言語・構造に書き換える | ロジックは残しつつ、保守できる人を増やしたい | 変換しても仕様の分からない部分は残る | 小〜中 |
| ④パッケージ・ERP | 標準機能を持つ製品に、業務を合わせて移す | 販売・在庫・会計など標準化しやすい業務が中心 | 標準機能に合わない業務の扱いを決める必要がある | 大きい |
| ⑤SaaSの組み合わせ | 会計・販売・勤怠などのクラウドサービスを連携させる | 業務ごとに適した製品を選びたい | サービス間の連携とデータの一致を設計する必要がある | 中〜大 |
| ⑥再構築(スクラッチ) | 業務を整理し直し、新たに開発する | 競争力に直結する独自業務がある | 費用・期間が大きく、作った後の保守体制が必要 | 大きい |
経済産業省が2025年5月に公表した「DXの現在地とレガシーシステム脱却に向けて」は、中堅・中小企業について、オーダーメイドのスクラッチ開発は避け、パッケージやSaaSを原則とすべきという考え方を示しています。オフコンの移行でも、⑥を選ぶのは競争力に直結する業務に絞り、それ以外は④⑤を基本に考えるのが現実的です。
※説明用の例です。業務を「標準に合わせるもの」「独自に残すもの」「やめるもの」に分けると、移行の対象そのものが小さくなり、費用も期間も見通しやすくなります。
比べるときの観点は、次の6つです。
| 観点 | 確認すること |
|---|---|
| 業務要件の充足 | 標準機能で、自社の業務要件をどこまで満たせるか |
| 総保有コスト | 初期費用だけでなく、データ移行・教育・保守を含む5年程度の総額 |
| 将来の変更への対応 | 拠点・取引形態・制度が変わったとき、どこまで設定で対応できるか |
| 連携のしやすさ | 会計・給与・EC・取引先とのデータ交換など、既存システムとつなげるか |
| 社内での運用 | 日常の運用・軽微な変更を社内で回せるか |
| 依存リスク | 特定のベンダー・開発者がいなくなったときに引き継げるか |
オフコンからの移行は、「同じものを新しい機械で動かす」だけで終わらせると、属人化した処理や例外がそのまま残ります。保守終了は、業務を見直す数少ない機会でもあります。再構築の方式ごとの違いとタイミングの見極め方は基幹システムのリプレイス、パッケージとスクラッチの組み合わせ方は中小企業のERPの選び方も参考にしてください。
①延命を選ぶときに確認する4点
- 期限:延命策そのものの提供期限。Cloud Service for オフコンのように、延命先のサービスにも終了日がある
- 対象範囲:本体だけか、OS・端末エミュレータ・プリンタまで含むか
- 部品と障害対応:第三者保守の場合、交換部品の確保方法と、故障時に復旧できるまでの目安
- 移行計画との関係:延命期間中に、どの業務から順に移すか。延命は移行計画とセットで決める
延命の期間を「移行が終わるまで」とあいまいにすると、延命の費用を払い続けながら移行の着手が遅れます。延命を選ぶ場合も、終わりの日を先に決めてください。
見積もり・提案依頼の前に用意する現行資産の一覧
移行先を比べるには、開発会社や製品ベンダーに見積もりを依頼する必要があります。オフコンの場合、現行の規模が分からないと、各社が違う前提で見積もり、金額の幅が大きく開きます。依頼の前に、次の一覧を作っておきます。
| 資産 | 数えるもの | 見積もりへの影響 |
|---|---|---|
| プログラム | 本数、言語、最終更新日、実際に使っているか | リホスト・リライトの作業量。使っていないプログラムを外せば対象が減る |
| 画面 | 画面数、利用部署、入力件数の多い画面 | 新システムでの画面設計と操作研修の範囲 |
| 帳票 | 帳票数、専用用紙の有無、取引先指定の様式 | 独自帳票の作成費用。取引先指定の様式は残す必要がある |
| ファイル(データ) | ファイル数、件数、保存年数、外字の有無 | データ移行・文字コード変換・照合の作業量 |
| 連携 | 連携先(会計・給与・EDI・取引先)、方式、頻度 | 連携の作り直しの費用 |
| 月次・年次の処理 | 締め処理、棚卸、年次更新の手順 | 総合テストと移行リハーサルで確かめる処理の数 |
このうち「実際に使っているか」の確認が一番効きます。長く使ってきたオフコンでは、過去に作ったものの今は使われていないプログラムや帳票が残っていることが珍しくありません。利用部署への聞き取りと、実行履歴が取れる場合はその記録で、移行対象から外せるものを先に特定します。一覧は、移行先の比較表やRFP(提案依頼書)の「現行システムとデータ」の章にそのまま使えます。
オフコン移行特有の3つの難しさ
オフコンからの移行は、一般的なシステムの入れ替えより手前の調査に時間がかかります。理由は次の3つです。
| 難しさ | 何が起きるか | 事前にすること |
|---|---|---|
| データの取り出し | データ形式が特殊で、一般的な方法では取り出せない。文字コードの変換で外字や半角カナが崩れる | 全ファイルについて、取り出せるか・どの形式で出るかを試し出しで確認する |
| 仕様の把握 | 作った担当者が退職し、仕様書もない。何十年分の改修の経緯が分からない | プログラム・ファイル・帳票の一覧を作り、実際に使われているものを特定する |
| 業務の再現 | 在庫評価、売上計上のタイミング、取引先ごとの締めなど、内部で独自の計算・変換をしている | 現行と新システムで同じデータを処理し、結果を突き合わせる検証を計画に入れる |
オフコンや独自システムからの移行では、移行計画を立てる前に、既存システムの構造、データを抽出できるか、業務ロジック、外部との連携を調べておく必要があります。その際は「システムに詳しい人」と「業務に詳しい人」の両方に確認します。どちらか一方だけでは、なぜその計算をしているのかが分かりません。
「オフコンと同じ画面・同じ帳票で」という要望が出たら注意が必要です。そのまま要件にすると、パッケージを選んでも追加開発が膨らみます。帳票は取引先に出すものと社内で見るものに分け、社内用は新システムの標準帳票に合わせられないかを先に検討します。
データの中身にも注意が必要です。長く使ってきたシステムでは、同じ取引先が営業所や担当者ごとに「株式会社〇〇建設」「〇〇建設」「(株)〇〇建設」と別名称・別コードで登録されていたり、使わなくなったコードが別の取引先に再利用されていたりします。そのまま移すと、過去の取引履歴が誤った取引先に紐づきます。名寄せと採番ルールの決め方はマスタデータ整備とコード体系の決め方で解説しています。
「システム上読み込めた」と「業務上正しく使える」は別物です。数量は一致していても商品コードが違う、残高が合わない、といった不整合は、取り込みのエラーとしては出てきません。
データ移行は、単なるデータのコピーではなく、会社の業務情報を整理し直す作業です。重複・欠損・不整合の抽出、コードと名称の統一ルール、新旧コードの対応表づくりまでを、要件定義の段階から計画に入れておきます。計画・クレンジング・照合・リハーサルの進め方は基幹システムのデータ移行をご覧ください。
保守終了から逆算したスケジュール例
保守終了の期限が決まっている場合は、そこから逆算して開始時期を決めます。次の表は、オフコンで販売・在庫・購買・会計を動かしている会社が、パッケージを中心に移行する場合の例です。
| 保守終了までの残り | 段階 | 期間の目安 | この段階で決めること |
|---|---|---|---|
| 30か月前 | 現行調査 | 1〜2か月 | プログラム・ファイル・帳票の一覧、データの取り出し可否、使われている機能 |
| 28か月前 | 構想策定 | 1〜2か月 | 刷新の目的と成功基準、対象業務、標準化する業務と残す業務 |
| 26か月前 | 要件定義 | 1〜3か月 | 機能要件、データ移行の範囲と判定基準、対象外 |
| 23か月前 | 製品選定・発注先決定 | 1〜2か月 | 移行先の組み合わせ、発注先、固定見積もり |
| 21か月前 | 設計・開発・設定 | 6〜9か月 | 2〜4週間ごとに画面と動きを確認 |
| 12か月前 | テスト・移行リハーサル | 2〜4か月 | 業務シナリオでの総合テスト、移行リハーサル2回以上 |
| 8か月前 | 本番移行・稼働 | ― | 決算期・繁忙期を避けた移行日 |
| 8〜5か月前 | 定着 | 3か月 | 使われていない機能・入力負荷の高い部分の改善 |
| 5か月前〜 | 予備期間 | ― | 延期・やり直しが必要になったときの余裕 |
※説明用の例です。期間は対象業務の範囲・データの状態・移行先によって変わります。リホスト中心の場合は短く、再構築の場合は長くなります。
開発を伴う場合の工期の見当には、公開されている調査が使えます。JUAS(日本情報システム・ユーザー協会)の「ソフトウェア・メトリクス調査2025」は、開発プロジェクトの実績から標準工期を「3.23×工数(人月)の立方根」と示しています。たとえば工数64人月なら、64の立方根は4なので約13か月です(※計算は説明用の例です)。同じ調査では、標準工期を超過したプロジェクトが全体で49%、50人月未満でも56%ありました。期限から逆算した計画が標準工期より短くなっている場合は、範囲を絞るか、開始を早める必要があります。
この例で押さえたいのは、予備期間を最初から確保することと、稼働後の定着期間を保守終了より前に終えることです。移行リハーサルで数字が合わず稼働を延期すると、予備期間がなければ旧システムの保守が切れた状態で本番を迎えることになります。稼働してよいかの判定基準と切り戻し計画は稼働判定と本番切替、各段階で何を承認してから次に進むかは基幹システム導入の進め方と判断ゲートで解説しています。
保守終了までに決めておく10のこと
- ハードウェア・OS・周辺ソフトのうち、最も早いサポート期限
- 延命策(クラウドサービス・第三者保守)を使うか、使うならいつまでか
- 刷新の目的と、成功を測る数字
- 移行する業務と、移行しない(廃止する・手作業に戻す)業務
- 業務ごとの移行先(パッケージ・SaaS・リホスト・再構築)の組み合わせ
- 移行するデータの範囲(何年分の履歴を移すか)
- 取引先・品目コードの統一ルールと、新旧コードの対応表の作成担当
- 移行完了の判定基準と、不一致が残ったときの延期・切り戻しの判断者
- システムに詳しい人と業務に詳しい人の、プロジェクトへの参加時間
- 本番移行の時期(決算期・繁忙期を避ける)と予備期間
よくある質問
オフコンを延命しながら、少しずつ移行することはできますか?
できます。延命策で時間を確保し、会計や給与のように標準化しやすい業務から先に移す方法もあります。ただし、延命策自体にも期限があることが多く、旧システムと新システムの間でデータを連携する仕組みが必要になります。延命の期限と、連携の手間を含めて計画してください。
オフコンのプログラムをそのまま移すリホストと、パッケージへの移行はどちらがよいですか?
業務によって違います。競争力に直結する独自の処理はプログラムを活かし、会計や在庫のように標準化できる業務はパッケージに移す、という組み合わせが合理的なことが多くあります。「昔からこの方法だから」という理由だけで独自の処理を残すと、移行後も保守の負担が続きます。
システムを作った担当者がもういません。移行できますか?
できますが、調査に時間がかかります。プログラム・ファイル・帳票の一覧を作り、実際に使われているものを特定したうえで、現行と新システムで同じデータを処理して結果を突き合わせる検証を計画に入れます。業務を担当している人への聞き取りが、仕様書の代わりになります。
過去の取引履歴は、すべて新システムに移す必要がありますか?
必ずしも必要ではありません。新システムには直近数年分と残高だけを移し、それより古い履歴は旧データを参照用に保管する方法もあります。法令で保存が必要な帳簿書類や、取引先からの問い合わせに答えるために必要な期間を確認したうえで、移す範囲と参照方法を決めてください。
オフコンの移行にはどのくらいの期間を見ておけばよいですか?
販売・在庫・購買・会計をパッケージ中心に移す場合、現行調査から稼働後の定着までで2年前後を見ておくと、予備期間を確保しやすくなります。リホスト中心なら短く、再構築なら長くなります。仕様が分からない部分が多いほど現行調査に時間がかかるため、保守期限まで3年を切っているなら、まず現行資産の一覧づくりから始めてください。
移行するデータの棚卸し、コード統一ルール、新旧コード対応表、照合の方法と移行判定基準を、そのまま使える形にまとめた資料です。
資料をダウンロードする(無料)まとめ
オフコンのリプレイスは、保守終了の期限から逆算して、現行調査・構想策定・要件定義を早めに始めることが要です。移行先は一つに決め打ちせず、標準化する業務はパッケージやSaaSへ、独自の業務はプログラムを活かすか作り直すという組み合わせで比べます。見積もりの前に現行資産を数えて使っていないものを外し、データが取り込めたかではなく、業務で正しく使えるかで移行の完了を判定してください。
自社の場合、何から調べればよいか分からない、という方は、無料診断で現状のシステムと業務を整理し、保守終了までに決めるべきことを明らかにします。
移行計画書のひな形、照合シート、リハーサル計画
資料をダウンロードする

