プリザンターのバージョンアップ・環境移行

• 01

  実行環境（.NET）やサーバーのOS（Windows Server、CentOS など）のサポートが終わる、またはすでに終わっている

• 02

  0.4x〜0.51 などの古いバージョンのまま使っていて、新しい機能やセキュリティの修正を取り込めていない

• 03

  SQL Server Express の容量の上限が近づいた、または上限に達した

• 04

  自社で運用している環境から、クラウドへ移したい

• 05

  移行にあわせて、二要素認証や通信の暗号化（TLS）で、セキュリティを強化したい

• 06

  テーブルの項目が足りなくなってきた

• 07

  作り込んだスクリプトがバージョンアップ後も動くか分からず、踏み切れない

• 08

  構築した担当者が異動・退職して、中身が分からないまま古いバージョンで動いている

実行環境とOSの、サポートの終了日

サポートが終わった実行環境やOSには、セキュリティの修正が提供されません。すでにサポートが終わったものと、これから終わるものは、次のとおりです。プリザンター 1.4 が動く .NET 8 は、2026年11月10日でサポートが終わります。

※ 日付は Microsoft・CentOS Project・Red Hat の公表によります（2026年10月時点。Microsoft の日付は米国太平洋時間）。

いまの環境の調査から、移行の計画、本番の作業の手順づくりまで、開発元のエンジニアに任せられます。オンサイトでも、リモートでも、エンジニアが直接対応します。

1. 不具合の修正や機能追加の影響で、動作時の挙動が変わる可能性はあります。本番に適用する前に、検証環境でスクリプトやサーバスクリプトの動作を確かめてください
2. スクリプトやCSSが、画面のDOM構造に依存した書き方になっていると、バージョンアップによって見た目や動作が変わることがあります
3. 作業の前に、システムとデータベースのバックアップを取ります
4. 運用中のパラメータファイルを、新しいバージョンへそのまま上書きコピーしないでください。新しいバージョンで追加されたパラメータが失われます
5. 元のバージョンへ戻したいときは、作業の前に取ったバックアップと、以前のバージョンの資産を使って、環境を作り直して戻せます。作業の前のバックアップが、戻すときの備えになります

バージョンアップ・移行の手順の一覧（ユーザマニュアル）

自社で進めるときに、つまずきやすいところ

1. パラメータファイルを、以前の環境から新しいバージョンへ上書きコピーしてしまう
2. 実行環境（.NET）を、新しいバージョンが動くものに入れ替えていない（プリザンター 1.5 は .NET 10 で動きます）
3. プリザンター 1.5 にしたあと、SQL Server に接続できない（TLS 証明書の検証が既定で有効になりました。SQL Server に証明書を設定するか、接続文字列を見直します）
4. CodeDefiner を実行していない、または実行するときのパラメータが手順と違う

自社で進めるのが不安な場合や、途中でつまずいた場合は、技術支援サービス（システム導入支援サービス）で、手順づくりから本番の作業まで支援を受けられます。

Windows Server 2016 で動かしている場合

プリザンター 1.5 が動く .NET 10 は、Windows Server 2016 に対応しています。ユーザマニュアルの動作環境にも、Windows Server 2016 が入っています。そのため、OSはそのままでも 1.5 へバージョンアップできます。

ただし、Windows Server 2016 の延長サポートは 2027年1月12日に終わります。1.4 が動く .NET 8 のサポートの終了（2026年11月10日）の、2か月後です。サポートが終わったOSには、セキュリティの修正が提供されません。1.5 へのバージョンアップを計画するときは、同じ機会に新しいOS（Windows Server 2019 / 2022 / 2025）のサーバーへ移すことをおすすめします。作業と検証をまとめられます。

動作環境と推奨スペック（ユーザマニュアル）

1. 移行先のOS・データベースが、動作を確認している環境に入っているかを確かめます（Windows Server 2019 / 2022 / 2025、Red Hat Enterprise Linux、Ubuntu、AlmaLinux など）
2. CentOS で動かしている場合は、Red Hat Enterprise Linux・AlmaLinux・Ubuntu などのサーバーへ移します。CentOS 7 では、プリザンター 1.4.0.0 以降が動作しません
3. SQL Server の場合は、移行元でデータベースを書き出し、移行先で取り込みます
4. PostgreSQL・MySQL の場合は、バックアップとリストアで移します
5. 添付ファイルをデータベースの外に保存している場合は、保存先のフォルダも移します
6. 移行元と移行先で、サーバーやデータベースのタイムゾーンの設定が同じかを確かめます。違うと、記録される日時がずれることがあります

動作環境と推奨スペック　異なる環境にデータベース（SQL Server）を移行する手順　PostgreSQL のバックアップ・リストア手順

移行先でプリザンターのURL（ホスト名）が変わると、レコードに書いたリンクや、外部のシステムに登録したURLが使えなくなることがあります。URLを引き継ぐかどうかは、移行の計画の段階で決めておくのがおすすめです。

新しいサーバーの構築と、旧環境からのデータの移行は、技術支援サービス（システム導入支援サービス）で承ります。URLが変わる場合の影響の洗い出しや置き換えも、ご相談いただけます。

構成の例（ユーザマニュアルの手順の構成）

SQL Server・PostgreSQL を AWS のマネージドのデータベースで使う場合の注意や、添付ファイルを AWS のストレージサービスに置けるかは、お問い合わせください。

移し方の流れ

1. 移行元で、データベースのバックアップを取ります。SQL Server はデータベースを書き出し、PostgreSQL・MySQL はバックアップを取ります
2. AWS 側で、Amazon EC2 のサーバーにプリザンターをインストールします。手動でインストールする手順と、インストーラを使う手順があります
3. データベースを移します。別の環境にデータベースをリストアしたら、CodeDefiner を実行します
4. 接続設定（Rds.json）を、移行先のデータベースに合わせます。ほかの設定ファイル（Parameters）も、移行元と見比べて移します。Enterprise Edition をお使いの場合は、ライセンスファイルも移します
5. プリザンターにログインし、データが移ったことを確かめます

Amazon EC2 の Red Hat Enterprise Linux 10 にインストールする　インストーラで Amazon EC2 の Red Hat Enterprise Linux 10 にインストールする　Rds.json（データベースの接続設定）　BinaryStorage.json（添付ファイルの保存先）　Amazon SES でメールを送信する

異なる環境にデータベース（SQL Server）を移行する手順　MySQL のバックアップ・リストア手順　PostgreSQL のバックアップ・リストア手順　バックアップとリストアの方法（別の環境へリストアするとき）（いずれもユーザマニュアル）

移行にあわせてできること

AWS へ移す機会に、データベースを SQL Server から PostgreSQL へ移すことや、Enterprise Edition にして項目を増やすこともできます。

PostgreSQL へ移行する（SQL Server Express の容量の上限に達したら）　Enterprise Edition にして項目を増やす（項目拡張）

AWS で使う OS・データベースの選び方や、サーバーのスペックの目安は、お問い合わせください。新しいサーバーの構築と、旧環境からのデータの移行は、技術支援サービス（システム導入支援サービス）で承ります。

メモリとCPUにも上限があります。容量に余裕があっても、利用者やデータが増えて性能の改善が必要になった場合は、SQL Server の有償のエディションなどへの移行をおすすめします。どこが遅いのかの調査は、技術支援サービスのパフォーマンス調査で承ります。

データベースの使用量を減らす

移行の前に、いまのデータベースの使用量を減らせる場合があります。

• 01

  添付ファイルをデータベースの外に保存する

  設定（BinaryStorage.json）で、添付ファイルや画像の保存先を、データベースからサーバーのフォルダ（ローカルストレージ）に変えられます。設定を変えたあとにアップロードしたファイルから、新しい保存先に保存されます。この設定にすると、以後のバックアップと移行では、データベースと保存先のフォルダの両方が対象になります

• 02

  システムログ（SysLogs）を定期的に削除する

  設定（BackgroundService.json の DeleteSysLogs）で、保存日数を過ぎたシステムログを自動で削除できます（1.3.23.0 以降）。たまったログをまとめて削除する手順もあります

• 03

  ごみ箱のレコードを定期的に削除する

  削除したレコードは、ごみ箱に残ります。保存期間を過ぎたものを自動で削除できます（1.3.25.0 以降）

BinaryStorage.json（添付ファイルの保存先）　添付ファイル格納方式の選択基準　プリザンターのログを削除したい　BackgroundService.json

PostgreSQL へ移行する

PostgreSQL はオープンソースのデータベースで、SQL Server Express のようなデータベース容量の上限がありません。プリザンターは PostgreSQL 14〜18 での動作を確認しており、SQL Server のデータを PostgreSQL へ移行する手順を用意しています。移行には、プリザンターに付属するツール（CodeDefiner）を使います。

1. 移行元と移行先のプリザンターを、同じバージョンにそろえてから移行します
2. データベースごとの仕様の違いでエラーになることがあるので、本番の前にリハーサルを行います
3. 数百メガバイト単位の添付ファイルなど、大きなデータは移行中にエラーになる可能性があります。事前に確かめておきます

SQL Server Express の制約について　異なる種類のDBにデータを移行する手順

データベースの移行の計画と実行は、技術支援サービス（システム導入支援サービス）で承ります。

ほかの選択肢

SQL Server 2022 Express 以前をお使いの場合は、SQL Server 2025 Express にすると、データベース容量の上限が 10 GB から 50 GB になります。データが増え続ける見込みなら、上限の無い PostgreSQL への移行か、SQL Server の上位のエディションを検討します。

上限に達する前に気づく

Enterprise Edition の運用管理ツール（Operations Tools）の監視アラートでは、データベース・システムテーブル・サイトの使用量に上限値を設定でき、超えると画面にアラートが表示されます。レコード数やバイナリサイズの推移も、運用レポートのグラフで確かめられます。

Enterprise Edition の機能を見る

すでに上限に達して、登録できなくなっている場合

SQL Server 2025 Express への入れ替え（上限 50 GB）か、PostgreSQL への移行で解消できます。お急ぎの場合は、お問い合わせください。

※ 6種類の項目は、分類・数値・日付・説明・チェック・添付ファイルです。

移行のときが、項目を増やすよい機会です

1. 項目拡張は、データベースのテーブルの構造を変える作業です。事前にデータベースのバックアップを取り、CodeDefiner を実行します
2. 移行やバージョンアップでも、データベースのバックアップを取り、データベースを扱います。同じ機会に行うと、作業と検証をまとめられます
3. Enterprise Edition へは、いまの環境にライセンスファイルを置いて切り替えます。環境を作り直す必要はありません

データベースを扱う作業は、開発元に任せられます

データベースを直接扱う作業は、慣れていないと不安なものです。移行の作業とあわせて、Enterprise Edition へのアップグレードと項目拡張まで、開発元のエンジニアに任せられます。技術支援サービス（システム導入支援サービス）で承ります。

Enterprise Edition は、年間サポートサービスのご契約で使えます。

Enterprise Edition の機能を見る　項目拡張手順（ユーザマニュアル）

これまでのお知らせは 7 件（2022年11月〜2025年10月）です。いちばん新しいものは、1.4.21.0 以降で解消しています。

クラウド（Pleasanter.net）をお使いの場合は、開発元がメンテナンスやバージョンアップで対策を適用しています。