--- title: "賃貸管理システムのオンプレミス型：クラウドとの違いと継続か移行かの判断" url: "https://www.issoh.co.jp/column/details/18904/" published: 2026-10-26 updated: 2026-10-26 categories: ["Webシステム"] publisher: "株式会社一創" --- # 賃貸管理システムのオンプレミス型：クラウドとの違いと継続か移行かの判断 社内のサーバーで動かしている賃貸管理システムは、パッケージの機能に不満が無くても、土台のOSやデータベースのサポート期限が、現在の構成のままで使い続けられるかを判断する際の基準です。この記事では、オンプレミス型とクラウド型の違いを保守の責任範囲から整理したうえで、Windows ServerとSQL Serverのサポート終了日、賃貸住宅管理業法の帳簿の5年保存と管理業務報告、個人情報保護委員会のガイドラインにある外的環境の把握を根拠に、オンプレミスを続けてよい会社と移るべき会社を分けます。クラウドへ移る場合に持ち出すデータの範囲、並行稼働と切り替え月の決め方、旧サーバーの止め方まで、受託開発の視点で言い切ります。数値と期日は2026年10月26日時点の公式情報です。 ## まとめ：オンプレミスの賃貸管理システムは部品の期限と保存義務で続けるか決める オンプレミスを続けてよいのは、サーバーとデータベースの更新予算、保守契約、管理を担う担当者の3つがそろい、しかも独自に改修した機能が業務の中核になっている会社です。どれか1つでも欠けているなら、次のサーバー更新を待たずにクラウド型への移行を計画したほうが安全です。 判断の起点は、自社サーバーの部品ごとの期限です。SQL Server 2016の延長サポートは2026年7月に終わっており、Windows Server 2016も2027年1月に終わります。この組み合わせで動いているなら、残された時間は数か月しかありません。 移行で気をつけるのは、旧システムの中身を全部移そうとしないことです。現行の契約と入出金は新システムへ移し、閉じた帳簿は法定の5年が過ぎるまで読み出せる形で別に保管します。切り替えは更新や送金の締めが重なる月を避けて決めます。 ## オンプレミス型とクラウド型の賃貸管理システムの違いと保守の責任範囲 2つの型の違いは、画面や機能よりも「誰がサーバーの面倒を見るか」にあります。比較サイトでよく並ぶセキュリティやカスタマイズの差も、この責任の分かれ方から出てきます。 ### サーバーの置き場所とOS更新の担い手で比べる2つの提供形態の違い オンプレミス型は、自社が買ったサーバーにパッケージを入れて使う形です。サーバーの置き場所が社内でもデータセンターでも、OSとデータベースの更新、バックアップ、障害時の復旧は自社か保守会社の仕事になります。クラウド型は、ベンダーが用意した環境をブラウザから使う形で、これらの作業は月額料金に含まれます。 | 比べる項目 | オンプレミス型 | クラウド型 | | ------------- | --------------- | ------------- | | サーバーとOS・DBの更新 | 自社または保守会社 | ベンダー | | 費用の出方 | 購入時と更新時にまとまって発生 | 管理区画数などに応じた月額 | | 法改正に伴う機能追加 | 保守契約の範囲で個別に適用 | 全利用者へ一斉に反映 | | 独自の改修 | 本体まで手を入れられる | 設定と外部連携の範囲まで | | 停止したときの復旧 | 自社の手順と人員で対応 | ベンダーの復旧に依存 | 業種を問わない一般的な比べ方は[オンプレミスとクラウドのコスト・セキュリティ・拡張性の比較](https://www.issoh.co.jp/column/details/13425/)にまとめています。賃貸管理で差が大きいのは、表の3行目と4行目です。 ### 「オンプレミスのほうが安全」が当てはまる会社と当てはまらない会社 オンプレミスは自社でデータを持てるので安全だ、という説明はよく見かけます。ただ、安全かどうかを決めるのは置き場所ではなく、更新と監視を誰が続けられるかです。IPAの[情報セキュリティ10大脅威 2026](https://www.ipa.go.jp/security/10threats/10threats2026.html)（2026年1月29日公開）では、組織編の1位が「ランサム攻撃による被害」でした。社内サーバーの修正プログラムの適用が数か月遅れている会社は、クラウドより安全とは言えません。 一方、同じ資料の2位は「サプライチェーンや委託先を狙った攻撃」です。クラウド型を選ぶ場合も、ベンダーの管理体制と障害時の連絡手順は契約前に確かめます。障害時の責任分界とSLAの読み方は[BCP対策をクラウドとオンプレミスのどちらに置くかの判断基準](https://www.issoh.co.jp/column/details/10989/)で詳しく扱っています。 ## オンプレミスの賃貸管理システムで先に期限が来るOSとデータベースの棚卸し パッケージ本体の保守が続いていても、その土台のOSとデータベースが先にサポートを終えることがあります。継続か移行かを決める前に、部品ごとの期限を一覧にします。 ### OSとデータベースの延長サポート終了時期と、有償の更新で延命できる期限 Microsoftの公式ライフサイクルでは、[SQL Server 2016](https://learn.microsoft.com/ja-jp/lifecycle/products/sql-server-2016)の延長サポートは2026年7月15日（米国太平洋時間）に終わりました。その後は有償の拡張セキュリティ更新（ESU）が、Year 1からYear 3まで最長で2029年7月まで用意されています。[Windows Server 2016](https://learn.microsoft.com/ja-jp/lifecycle/products/windows-server-2016)の延長サポートは2027年1月13日（同）までです。 サーバーがWindows Server 2016、データベースがSQL Server 2016という構成なら、データベースはすでにサポート外です。ESUの購入でつなぐ方法もありますが、2029年7月で終わる延命策にすぎません。その間に移行先を決めて動かす前提で予算を組んでください。 ### 自社サーバーの期限を洗い出す手順と、パッケージの動作保証との突き合わせ 期限の洗い出しは、情報システムの担当者がいない会社でも、保守会社への問い合わせと画面の確認で進められます。次の順で一覧にします。 1. サーバーのOSの版と、データベースの製品名と版を確認する 2. それぞれのサポート終了日を、メーカーの公式ライフサイクルで調べる 3. 賃貸管理パッケージの保守契約の期限と、更新の条件を契約書で確認する 4. パッケージが動作を保証しているOSとデータベースの版を、ベンダーに問い合わせる 5. サーバー本体のハードウェア保守の期限と、バックアップの保存先を確認する 注意が要るのは4つ目です。新しいOSへ載せ替えたくても、パッケージ側が対応していなければ載せ替えられません。対応版が出ていない場合、継続の選択肢は事実上なくなります。 ## オンプレミス型を続けてよい会社の条件と、続けると危うくなる場面 期限の一覧ができたら、続ける場合の負担を引き受けられるかで判断します。ここでは条件を言い切ります。 ### 継続してよい条件：更新予算・保守契約・担当者がそろい独自改修が中核 オンプレミスを続ける理由になるのは、本体まで手を入れた独自の改修です。たとえば、サブリースの借上げ賃料と転貸賃料を自社独自の計算で精算している、グループ会社の基幹システムと社内ネットワーク内で直接つないでいる、といった改修がこれに当たります。 そのうえで、次の更新までのサーバーとデータベースの費用を予算に入れられること、パッケージの保守契約が続くこと、修正プログラムの適用と監視を担う担当者か保守会社がいることの3つがそろえば、続けてかまいません。どれか1つでも欠けると、改修の価値より停止と漏えいの危険が上回ります。 ### 見送るべき場面：担当者1人のサーバー管理と、保守が切れた旧版の延命 続けるべきでない典型は、サーバーの管理を社員1人が兼務で担っている会社です。その人が退職すると、バックアップの戻し方も分からない状態が残ります。パッケージの保守が切れた旧版を、改修が無いのに使い続けている会社も同じです。 独自の改修が無いなら、オンプレミスに残る利点はほとんどありません。この2つに当てはまる会社は、次のサーバー更新の見積もりを取る前に、クラウド型の比較へ進んでください。規模に応じたクラウド型の選び方は[管理戸数帯で変わる賃貸管理システムの選び方](https://www.issoh.co.jp/column/details/18902/)で解説しています。 ## クラウドへ移行するときのデータ移行：持ち出す範囲と旧帳簿の保存 移行の難しさは、旧システムのデータを全部移そうとするところから生まれます。新システムで使うデータと、法律で残すだけのデータを分けると、作業量と失敗の余地が減ります。 ### 移すデータと残すデータの分け方：現行契約と、閉鎖後5年保存の帳簿 [賃貸住宅管理業法](https://laws.e-gov.go.jp/law/502AC0000000060)第18条は、登録事業者に管理受託契約ごとの帳簿を備えることを求めています。[同法施行規則](https://laws.e-gov.go.jp/law/502M60000800083)第38条は、この帳簿を電磁的記録で代えることを認めたうえで、事業年度の末日で閉鎖し、閉鎖後5年間保存するよう定めています。 この規定から、データは次のように分けられます。新システムへ移すのは、現行の契約、入居者、オーナー、未収と前受けの残高です。閉鎖した事業年度の帳簿と退去済みの契約は、新システムへ移さず、旧システムから出力したファイルとして読み出せる形で保管します。移す件数が減るほど、照合の手間も減ります。 ### 旧システムからの持ち出し方：CSV出力の範囲と、DBから直接抜く場合の確認 最初に、パッケージの画面から出せるCSVで足りるかを確かめます。物件、契約、入居者、オーナー、入出金の明細がそれぞれ出せれば、新システムの取り込み形式へ変換するだけで済みます。 画面から出せない項目があると、データベースから直接抜く作業になります。このときは、テーブル構造をパッケージのベンダーが開示してくれるか、作業を保守会社に依頼できるかを先に確認してください。独自に追加した項目や区分コードは、旧システムでの意味を書き出した対応表が無いと新システムで正しく読み替えられません。入金名義と契約の対応など業務データの整え方は[導入事例と移行で詰まる点](https://www.issoh.co.jp/column/details/18898/)で手順にしています。 ### 並行稼働と切り替え月の決め方：更新・送金の締めと管理業務報告を避ける 切り替え月を決める際に避けたいのは、契約更新が集中する月とオーナー送金の締めです。施行規則第40条は、管理受託契約を結んだ日から1年を超えない期間ごとに、管理業務報告書を作ってオーナーへ渡すよう定めています。報告の作成時期が重なる月に切り替えると、旧と新のどちらの記録で報告するかが曖昧になります。 並行稼働は、少なくとも1回分の家賃入金と送金を、旧と新の両方で処理して結果を突き合わせるまで続けます。送金額が1件でも合わない場合は、切り替えの延期が必要です。移行方式の選び方そのものは[システム移行の方式と進め方](https://www.issoh.co.jp/column/details/15261/)で整理しています。 ### 旧サーバーの止め方：保存義務のある帳簿の置き場所と個人データの消去 旧サーバーは、切り替えた日に止めず、帳簿の出力ファイルが別の保存先で開けることを確かめてから止めます。保存先は、社内のファイルサーバーでも、新しいクラウド型の添付ファイル機能でもかまいません。大事なのは、5年の保存期間が終わる日と、そのときに消す担当者を決めておくことです。 サーバー本体を廃棄するときは、入居者や連帯保証人、オーナーの個人データがディスクに残ります。廃棄業者に任せる場合も、消去の方法と証明書の発行を契約に入れてください。 ## クラウド型へ移る前にオンプレミス利用者が確かめるデータ所在と改修機能 オンプレミスで使ってきた会社は、データの所在と独自の改修の扱いで、クラウド型の比較に追加の確認項目が生じます。 ### データの保管国と外的環境の把握：個人情報保護委員会ガイドライン10-7 個人情報保護委員会の[通則ガイドライン](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)（令和8年6月一部改正）の10-7は、外国で個人データを取り扱う場合、その国の個人情報保護の制度を把握したうえで安全管理措置を講じるよう求めています。社内サーバーでは意識しなかった論点です。 クラウド型の比較では、データを保管するサーバーの国と、バックアップの保管先の国をベンダーに確認します。国内のデータセンターだと明示している製品なら、この確認は1行で済みます。回答が曖昧な製品は、オーナーや入居者への説明が難しくなるため、候補から外してかまいません。 ### 独自改修の置き換え方：標準機能・設定・外部の連携開発の順で当てる オンプレミスで本体に入れた改修は、クラウド型では同じ形で持ち込めません。改修ごとに、標準機能で足りるか、帳票や項目の設定で再現できるか、本体の外で連携として作るかの順で当てはめます。 項目の追加や帳票の書式のような改修なら、最初の2つで吸収できる場合があります。残るのは、独自の精算計算や基幹会計への仕訳連携のように、標準の外にある処理です。この部分だけは、クラウド型のCSV出力やAPIを起点に、本体とは別のプログラムとして作ります。一創では[不動産会社向けのシステム開発](https://www.issoh.co.jp/service/system/estatesystem/)として、既製の賃貸管理システムとつなぐ連携部分から受託しています。連携部分の発注先を比べるときの確認項目は[賃貸管理システムの開発会社の選び方：見積り比較と要件定義で詰める点](https://www.issoh.co.jp/column/details/18906/)で解説しています。 ## 判断表：オンプレミス継続・クラウド移行・既製品と連携開発の組み合わせ ここまでの条件を、選ぶ構成ごとにまとめます。 ### 自社の状況別に選ぶ構成と、その状況では見送るべき選択肢の一覧 | 自社の状況 | 選ぶ構成 | 見送る選択肢 | | --------------- | ---------------- | -------------- | | 改修なし・サーバー管理は兼務 | クラウド型へ移行 | サーバー更新、ESUでの延命 | | 改修あり・担当者と予算がない | クラウド型＋改修部分の連携開発 | 保守切れ旧版の継続 | | 改修が中核・担当者と予算がある | オンプレミス継続（期限前に更新） | サポート外の部品での運用 | | パッケージが新OS非対応 | クラウド型へ移行 | OSだけの載せ替え | 判断に迷いやすいのは2行目です。改修の価値は残しつつ、サーバーの管理からは手を離す構成を選びます。移行後に月額がどう積み上がるかは[賃貸管理システムの費用と3年総額の増え方](https://www.issoh.co.jp/column/details/18900/)で試算しています。 ### オンプレミスのまま賃貸管理システムを作り直す選択を勧めない理由 改修が多い会社ほど、いっそ自社専用に作り直そうという声が出ます。しかし作り直すと、法改正への追従もサーバーの更新も、すべて自社の負担として残ります。今回の移行で手放そうとしている負担を、もう一度抱え込む形です。 作り直しが割に合うのは、賃貸管理が本業の一部にすぎず、独自の基幹システムに賃貸の機能を組み込む会社くらいです。パッケージと作り込みの比べ方は[スクラッチ開発とパッケージの違いと発注判断](https://www.issoh.co.jp/column/details/13203/)で解説しています。 ## よくある質問 オンプレミス型の賃貸管理システムを使っている会社からよく出る質問に答えます。 ### クラウド型はオンプレミス型よりセキュリティ面で劣りますか？ 型だけでは決まりません。オンプレミス型は自社でデータを持てる反面、修正プログラムの適用と監視を自社で続ける必要があります。IPAの情報セキュリティ10大脅威2026では、組織編の1位がランサム攻撃による被害でした。社内サーバーの更新が遅れがちな会社なら、ベンダーが一斉に更新するクラウド型のほうが、修正されないまま残る穴は少なくなります。比べるときは、更新の担い手とベンダーの管理体制を見てください。 ### 保守契約が切れたオンプレミスの賃貸管理システムを使い続けても問題ありませんか？ 勧めません。保守が切れると、法改正に合わせた機能追加も、障害時の復旧支援も受けられなくなります。データベースやOSのサポートも切れていれば、見つかった脆弱性は修正されないまま残ります。独自の改修が業務の中核でないなら、次のサーバー更新を待たずにクラウド型への移行を計画してください。改修がある場合も、改修部分だけを連携として作り直す構成を先に検討します。 ### 独自に改修したオンプレミス型からでもクラウド型へ移れますか？ 移れます。改修ごとに、標準機能、帳票や項目の設定、本体の外での連携開発のどれで置き換えるかを決めていけば、移行の範囲を定めることが可能です。最後まで残りやすいのは独自の精算計算や基幹会計への連携のような処理で、これはクラウド型のCSV出力やAPIを起点に別のプログラムとして作ります。改修の一覧と、それぞれを誰が使っているかを先に書き出すと、置き換えの範囲を見積もりやすくなります。 ### クラウドへ移行するとき、退去済みの契約データも移す必要がありますか？ 新システムへ移す必要はありません。賃貸住宅管理業法の施行規則第38条は、帳簿を事業年度の末日で閉鎖し、閉鎖後5年間保存するよう求めていますが、保存先までは指定していません。退去済みの契約や閉じた帳簿は、旧システムから出力したファイルとして読み出せる形で保管し、保存期間の終わる日を記録しておけば足ります。移す件数を減らすほど、移行後の照合も楽になります。 ### 社内サーバーをそのままクラウドのサーバーに載せ替える移行はありですか？ パッケージのベンダーがクラウド上での動作を保証していれば、選択肢になります。サーバーの購入と設置からは解放されますが、OSとデータベースの更新、バックアップの管理は自社に残ります。サポート期限の問題も、載せ替えただけでは解決しません。載せ替え、作り直し、SaaSへの乗り換えといった移行の型の比べ方は[クラウド移行の7Rの選び方と進め方](https://www.issoh.co.jp/column/details/13424/)で解説しています。 ## 関連記事 - [賃貸管理システムとは？機能・種類と選び方、自社開発が必要になる判断まで解説](https://www.issoh.co.jp/column/details/15400/)：機能・種類・選び方の全体像を整理した親記事です。 - [賃貸管理システムの導入事例：入金消込・更新・オーナー送金の変化と移行で詰まる点](https://www.issoh.co.jp/column/details/18898/)：移行前に整える業務データの手順を公開事例とあわせて確かめられます。 - [賃貸管理システムの費用：公開料金で見る初期費用・月額と3年総額の増え方](https://www.issoh.co.jp/column/details/18900/)：クラウド型へ移った後の月額とオプションの試算です。 - [不動産管理DXの進め方：入居者対応・修繕・オーナー報告と管理業法の記録要件](https://www.issoh.co.jp/column/details/18886/)：管理業法が求める記録をデジタルで残す進め方です。 - [賃貸管理システムの中小企業向けの選び方：管理戸数帯で変わる機能と大企業との差](https://www.issoh.co.jp/column/details/18902/)：移行先のクラウド型を規模別に選ぶ観点です。 --- 出典: [賃貸管理システムのオンプレミス型：クラウドとの違いと継続か移行かの判断]()（株式会社一創）