Why an air-gapped ERP is a different build for finance teams
The edition and plan decide whether on-premise hosting is allowed at all, and the offline update path decides how the system stays patched. For a finance or operations team that must keep its ERP in an enclave with no internet route, those two questions come before any module choice. On Odoo, on-premise hosting is available only on the Custom plan, and the Enterprise edition is the one that carries the upgrade service and the subscription activation that an on-premise database needs. The short answer on platforms is therefore Odoo Enterprise on-premise on the Custom plan, or ERPNext self-hosted with Docker Compose or the bench command line tool, where self-hosting is free and no vendor subscription gates the install. Everything beyond that choice is a question of which features call external services.
Those external calls are where most air-gapped builds get harder than the installation itself. Confirm with the vendor, in writing, which features need a licence check, a cloud API, an in-app credit purchase or a remote update source, and which of them keep working when the network is closed. Odoo 20 states that all AI features require credits bought as in-app purchases, so those features should be treated as unavailable inside the enclave unless the vendor confirms otherwise for your subscription. On the ERPNext side, Server Scripts are disabled by default from version 15 and must be enabled deliberately, and Frappe Cloud is not a path into the enclave. Build a register of every integration, plugin and authentication method, including LDAP for Odoo and ERPNext, and check each one against the isolated network before go-live.
The offline update path is the control that keeps the system supportable, and it needs an owner before the first install. Odoo standard support covers three years after a major release for on-premise customers, and Odoo 20.0 standard support is planned until September 2029, so the upgrade cycle must be scheduled around those dates. ERPNext and Frappe Framework version 14 reached end of life on January 31, 2026, so the version you deploy should be on a listed version at the time of the decision. Each package carried across the boundary should be verified for integrity and authenticity, the same expectation NERC CIP-013-2 sets for vendor software and patches. Ask your implementation partner how they will stage packages, test upgraded databases and document the transfer.
Which regulatory and control requirements shape an isolated ERP
This table maps each requirement to what it means for the ERP build, the evidence an assessor will ask for, and where isolated deployments usually fall short. A requirement applies to the institution, so the platform supports the controls but does not satisfy them on its own. Read each row as a question to answer in your own architecture and procedures.
| Requirement | What it means for the ERP build | Evidence to prepare |
|---|---|---|
| FTC Safeguards Rule, 16 CFR 314.4 (encryption) | Customer data in transit over external networks and at rest must be encrypted, including database backups, file stores and transfers into the enclave. | Encryption configuration for database, file storage, backups and transfer channels, with key ownership documented. |
| FTC Safeguards Rule, 16 CFR 314.4 (MFA) | Every individual accessing the ERP needs multi-factor authentication, including administrators and service accounts where interactive use occurs. Identity must work without internet access. | Identity provider configuration, MFA enrollment records and a list of privileged accounts with their authentication method. |
| FTC Safeguards Rule, 16 CFR 314.4 (change management) | Customizations, module installs, upgrades and configuration changes move through a documented approval and testing path, even when packages arrive on removable media. | Change tickets, test results on a staging copy and a record of who approved each production release. |
| FTC Safeguards Rule, 16 CFR 314.4 (activity logging) | User actions in the ERP, especially financial postings, master data edits and permission changes, must be logged and kept where the enclave team can review them. | Audit log settings, log retention period, sample review records and where logs are shipped inside the enclave. |
| FTC Safeguards Rule, 16 CFR 314.4(d)(2) (testing) | Without effective continuous monitoring, penetration tests and vulnerability assessments of the systems must run at least every six months. The ERP stack, OS and database are all in scope. | Schedule of tests, scope statements, findings tracker and remediation dates. Confirm the testing approach with your own assessor. |
| SEC Rule 17a-4(b) (retention) | Broker-dealer records such as bills receivable or payable, bank statements and original business communications must be preserved for at least three years, the first two easily accessible. Archive formats and restore tests matter in an isolated site. | Retention schedule mapped to ERP document types, archive restore test results and proof of readable access during the first two years. |
| NERC CIP-005-7 (interactive remote access) | Vendor or remote engineer access into the enclave must pass through an intermediate system with encryption and multi-factor authentication, and active vendor sessions must be detectable and disableable. | Network diagram of access paths, intermediate system configuration, session logs and the procedure for ending a vendor session. |
| NERC CIP-013-2 (software integrity) | Each Odoo or ERPNext package, container image, module and patch carried across the boundary needs verified integrity and authenticity before it is installed. Vendor support tickets that require file transfer are part of this scope. | Hash or signature verification records, transfer log for each media set, approved source list and sign-off before import. |
Which ERP platform fits an enclave and why
An isolated network narrows the ERP choice before features are compared. Licensing, the plan that permits on-premise hosting, the support window and the way upgrades reach the system decide whether a platform can be run and kept current inside the enclave. The cards below set out each option and the checks to make before committing.
Odoo Enterprise on the Custom plan
Odoo lists on-premise hosting as a feature of the Custom plan only, and that plan is also the only one that includes multi-company, Odoo Studio, external API access and custom modules. Running Enterprise on-premise also requires a subscription code to activate the database. Upgrades go through the upgrade service, which requires an Enterprise subscription, so the subscription must cover the full life of the enclave. Confirm with Odoo how the subscription check is handled when the system has no internet route.
Odoo Community without upgrade service
Odoo Community is the LGPL-3.0 open source core and carries no Enterprise features, including the upgrade service. An enclave on Community must plan every version move itself, from database migration to module compatibility, and must test those moves with no vendor tooling. Security patches come through the vendor's support model, so the team needs a documented way to receive, verify and carry each patch across the boundary. Choose Community only if that in-house capacity is already funded.
ERPNext on the Frappe framework
ERPNext is GPL-3.0 and runs on the MIT-licensed Frappe framework, so the software can be self-hosted at no license fee. It can be installed with Docker Compose or the bench command line tool, and the production Docker images package MariaDB, Redis, workers, the scheduler and Nginx. Warranty coverage from Frappe requires a listed version and a matching Frappe Cloud support plan, which is a recurring cost even when the software runs in your enclave. Confirm which version is on your approved list before the build starts.
Frappe version support windows
Frappe lists version 14 as end of life since January 31, 2026, version 15 supported until the end of 2027 and version 16 until the end of 2029. An enclave deployed on a version near the end of its window will need an upgrade project sooner than planned, and that work must be performed without vendor access. Choose the version against the planned operating life of the system, not only against the current feature set. Ask the implementation partner how they will validate each minor release inside the enclave.
Odoo support windows and SaaS cadence
Odoo standard support covers the first three years after a major release, including security updates, and on-premise paid extended support is limited to certain versions. Odoo 19.0 is supported until September 2028 and Odoo 18.0 until September 2027, so the version selected at build time sets the date of the next forced upgrade. Odoo SaaS releases arrive every two to three months and cannot use extended support, which makes SaaS release cadence a poor model for a closed network. Ask Odoo which versions carry extended support for your edition before signing.
Server Scripts and custom code controls
In Frappe, Server Scripts run Python on document events or as API endpoints. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Enabling them inside an enclave means any custom logic runs with server-side access, so the change must go through the same approval and testing path as code. Record the decision in the configuration baseline and confirm the setting on each environment, including the test copy.
How an enclave ERP rollout moves from build to first close
This sequence takes an isolated ERP from an edition decision to a first period close that runs entirely inside the enclave, with each phase producing a signed-off artifact. The order matters because license terms, package intake and upgrade rehearsal decide what can be installed, updated and supported once the network is sealed.
Confirm edition, plan and license terms in writing
Before any build work, confirm in writing which edition and plan allow on-premise or offline hosting, because the Odoo pricing page limits on-premise hosting to the Custom plan and Enterprise activation depends on a subscription code. For ERPNext, confirm whether any Frappe Cloud support plan is required for the warranty coverage you expect. The output is a signed scope note listing the edition, plan, modules, user count and support terms, plus a list of every feature that calls an external service. Ask the vendor or partner to confirm each of these points against the current terms, since pricing and plan contents change.
Design the enclave architecture and package intake
Map the enclave's boundary, the systems that sit inside it, and the single controlled path through which software, container images, Python and Node packages, and security updates enter. Define who approves each transfer, how checksums or signatures are verified, and where the artifacts are stored. Decide whether ERP components run on Kubernetes or Docker Compose, and whether they use PostgreSQL or MariaDB depending on the platform. The output is an architecture diagram and an intake procedure that a security reviewer has accepted, which later supports change management and supply chain evidence.
Build the offline mirror of images and packages
On a connected staging network, pull everything the enclave needs: base and application container images, Odoo packages or ERPNext bench sources, and the pip and npm dependencies they resolve to. Store them in a private registry and internal package repositories inside the enclave, and pin versions so a rebuild produces the same result. For Kubernetes, the kubeadm image list and a private registry make the control plane reproducible without internet access. The output is a manifest of versions and hashes that matches what was approved in the intake design, and a test run that installs from the mirror with outbound access blocked.
Stage the install and activate the database
Install the ERP first in a staging enclave that mirrors production's network controls. For Odoo Enterprise, activate the database with the subscription code; for ERPNext, configure the site, background workers, scheduler and reverse proxy from the mirrored images. Disable or block any feature that reaches an outside endpoint, such as external email, map, or AI services, and record each change. The output is a working staging instance, a list of disabled outbound features, and a configuration baseline that is stored under version control.
Configure the system and import data in batches
Configure companies, charts of accounts, users, roles and approval flows in the staging instance, then load master data and opening balances in controlled batches. ERPNext's Data Import tool advises importing only a few thousand records at a time, so plan batch sizes and keep each load traceable to its source file. Reconcile every batch against the legacy totals and record exceptions. Authentication should connect to the enclave's directory service where supported, such as LDAP. The output is a reconciled staging dataset with signed reconciliation sheets for each load.
Rehearse the upgrade on a test database
Run the upgrade path on a copy of the staging database before any production work. For Odoo, the upgrade service produces an upgraded test database that must be tested before production, and that service needs an Enterprise subscription for on-premise use. For ERPNext, check the supported-versions policy and the minor release cadence so the target version is still supported when go-live happens. Confirm custom modules still load and that no server scripts or integrations break. The output is a rehearsal log with issues, fixes and a go or no-go decision for the upgrade.
Test security and capture the evidence
Test the enclave deployment as a system: access control, MFA where the platform supports it, logging of user activity, encryption at rest and in transit inside the enclave, backup and restore, and the package intake controls. Run vulnerability assessments and penetration tests against the ERP and its supporting services, and fix or formally accept each finding. Keep the test scope, results, retests and configuration exports together. The output is an evidence pack for the assessor, which DeployOpen prepares but independent auditors and certification bodies evaluate.
Cut over and close the first period
Freeze the legacy system at an agreed cutoff, run the final incremental load, and reconcile balances, open items and subledgers against the frozen source before users transact in production. Brief users on enclave-only support paths and confirm that the escalation route, on-call contacts and patch procedure work without internet access. Run the first period close inside the enclave and compare the results with the reconciled opening position. The output is a signed cutover checklist, a first close package and a handover to the operations team that owns updates after go-live.
Which ERP features call external services and how to handle them
Start with an inventory of every feature that reaches outside the enclave, before the platform is installed. In Odoo, the list usually includes AI features, which in Odoo 20 require credits bought as in-app purchases, so an isolated instance should assume those features are unavailable until the vendor confirms how credits work without connectivity. Other candidates are outbound mail through an SMTP relay, Google or Microsoft single sign-on, LDAP directory lookups (which stay internal if the directory is inside the enclave), payment connectors, and currency and tax data feeds that update exchange rates or tax tables from the internet. ERPNext has the same pattern with its social login keys, email accounts and any integration apps. Record each item with its owner, the data it sends or receives, and the business process it supports.
Then decide, per item, one of three treatments. Replace it with an internal equivalent, such as an internal SMTP relay, an LDAP or Active Directory source for authentication, a manually loaded rate and tax table approved through change control, or a local payment gateway test stub. Disable it where the business process can run without it, and remove the menu or connector so users do not hit a failing call. Route it through a controlled transfer where the data truly must cross the boundary, with a named approver, a defined file or message format, and a log entry. Do not assume any feature is offline-safe because the documentation describes it as a standard capability. Confirm each feature's behavior with the vendor in writing, then test it on a copy of the production database inside an isolated staging network that blocks outbound traffic, and record which features fail, time out or degrade silently.
How the enclave architecture separates the ERP from the transfer zone
Odoo Enterprise on-premise is installed inside the enclave from packaged installers or from source, and each database is activated with the subscription code. Because the Enterprise edition is licensed and its source is not publicly available, the enclave needs an internal copy of every package it runs, and the subscription entitlement must be confirmed before any update is carried across the boundary. Odoo's upgrade service requires an Enterprise subscription for on-premise use, so the upgrade path must be planned without vendor access to the live system.
- Internal registry or package store: Keep the installer, the Python dependencies and any third-party modules in an internal repository that only the platform team can write to.
- Controlled transfer point: Scan and hash each release package in a staging zone, then move it across the boundary under a signed change record.
- LDAP authentication: Odoo documents LDAP authentication, so connect it to the enclave directory service, after confirming the directory version and bind settings with your identity team.
- Backup and test copies: Use database duplication with neutralization to create test copies, which disables outgoing mail and scheduled actions so a copy cannot send data out.
- Upgrade rehearsal: Run the upgraded test database and review it before any production change, since upgrades are a major source of unplanned downtime.
Confirm with the vendor which Enterprise components your enclave needs and how the subscription is renewed when no outbound connection exists.
The frappe_docker repository provides production Docker images and Compose files for ERPNext, with services for MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx. In an enclave, the images are built or mirrored into an internal registry and the Compose or orchestration files reference only that registry. The single-file demo setup is intended for short-lived evaluation only, so the production layout must be designed separately. If the team uses Kubernetes, kubeadm can prepare control plane images in advance with kubeadm config images pull and point kubeadm init at a private registry through --image-repository.
- Internal image registry: Mirror every ERPNext, Frappe, MariaDB, Redis and Nginx image, and pin tags by digest so the running version is traceable.
- Package mirror for apps: Store Frappe apps and their dependencies in an internal mirror, since application builds cannot fetch from public sources.
- Server Scripts policy: Starting from version 15, Server Scripts are disabled by default and must be enabled with the
server_script_enabledsetting, so record that decision in the change log. - Backups and test copies: Schedule database backups inside the enclave, and restore them into a test environment before any upgrade.
- Authentication: ERPNext supports LDAP integration and social login keys, so confirm which identity provider inside the enclave will be used.
Ask the implementation partner who owns the image build pipeline and how the registry is kept in step with each supported ERPNext release.
The bench command line tool installs ERPNext manually on a host you control. This route gives the most direct control over the operating system, Python and Node dependencies, but every dependency must come from a source the enclave can reach. Bench fetches apps and packages during installation and updates, so an offline build needs a prepared package mirror and a documented procedure for moving those artifacts across the boundary. Teams that choose this route should expect to maintain more of the build chain themselves.
- Internal package mirror: Host the Python, Node and system packages that bench needs, and freeze versions in a lock file that is reviewed before transfer.
- Controlled transfer point: Verify the integrity of each ERPNext and Frappe release in staging, and keep a record of the hash and the approver.
- Backup and test copies: Use the backup tooling for MariaDB, then restore into a test site and neutralize integrations before users log in.
- Upgrade path: ERPNext and Frappe version 15 is supported until the end of 2027 and version 16 until the end of 2029, so schedule upgrades against those dates and confirm the supported versions page at the time of planning.
- Operating system patching: Plan for host-level patching from the enclave's own repositories, because the bench install depends on it.
Confirm with your team whether the bench route is justified over a container route, since the maintenance load is higher and rests with your staff.
What do buyers ask before an air-gapped ERP project?
Can Odoo Community run in an air-gapped network?
Yes, the Community edition is open source under LGPL-3.0 and can be installed from source or packaged files inside an isolated network, so no license check requires internet access. What it lacks is the vendor upgrade service, which is only available with an Enterprise subscription on on-premise installations. Community users must plan major version moves themselves, including building a test database, running data conversion and checking custom modules. Confirm with Odoo which Enterprise features you would need before deciding, because the Enterprise source code is not publicly available and requires a subscription or partner access. The Odoo pricing page reserves on-premise hosting and features such as multi-company, Odoo Studio, external API access and custom modules for the Custom plan.
What drives the cost of an air-gapped ERP project?
The main drivers are the edition and plan, the number of modules in scope, the effort to build an offline package mirror, the volume of data to migrate and the depth of testing. Subscription fees for Enterprise or a Custom plan recur, while implementation, offline mirror construction, custom module work and migration are usually one-time costs paid to whoever does the work. Plan a larger testing effort if you have many modules or custom code, because each release must be rebuilt, scanned and verified before it crosses the boundary. Ask any implementation partner for a quote that separates licensing, hosting, mirror build, configuration, customization, migration, testing, training and post-go-live support, so you can see which lines recur each year.
How long does an air-gapped ERP rollout take?
The pace is set by scope and the approval path more than by the software itself. The schedule depends on how many entities, modules and integrations are in scope, how much history must be migrated, how many release approvals are needed to carry packages across the boundary, and how long user acceptance testing takes inside the enclave. Confirm the timeline in writing as part of a fixed-scope proposal, and ask the partner to list the gating steps: network and security sign-off, mirror build, trial loads, reconciliation and cutover. Delays most often come from slow approvals and unclear data ownership, not from installation.
What must our team provide for an isolated ERP deployment?
Your team must provide three groups of people and decisions. Network owners must document the enclave boundary, transfer paths, firewall rules and how media or approved transfers enter and leave. Release approvers must agree who signs off each package, patch and module before it is carried across, and how that check of software integrity and authenticity is recorded. Data owners must confirm which records are in scope for migration, who reconciles opening balances and who accepts test results. Without these named owners, the build and cutover plans stall, so agree them before the statement of work is signed.
Can our internal staff run an air-gapped ERP without vendor access?
Internal staff can run the system if they have Linux, PostgreSQL, Python and deployment skills, a documented upgrade runbook and a tested offline process for packages and backups. Without vendor upgrade services, you must own major version moves, security patches within the supported window and restore tests. Odoo standard support covers the first three years after a major release on on-premise installations, and paid extended support is limited, so plan each major upgrade before support ends. For ERPNext, confirm the supported version list and whether your partner or your team holds the matching support arrangement. Many organizations split the work: internal staff run daily operations while a partner handles upgrades and hardening on a retainer.
Which ERP features stop working without internet access?
Features that call external services need a local substitute or must be removed from scope. Typical examples are online bank feeds, currency rate downloads, tax or address lookups, cloud-based AI features, online app stores and vendor-hosted e-signature or email relays. In Odoo, AI features require in-app credits purchased from the vendor, so they do not fit an isolated network unless you confirm an offline alternative. In ERPNext, the Data Import tool can read public Google Sheets, which an enclave cannot reach, so use local CSV or Excel files instead. Ask the partner for a feature inventory that marks each external call and the agreed replacement.
How should we handle security evidence for an isolated ERP?
Start with the controls your regulator or customer requires, then design the ERP to produce evidence for them. The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to log the activity of authorized users, use multi-factor authentication for anyone accessing information systems, adopt change management procedures and encrypt customer information at rest. Penetration testing and vulnerability assessments are also required at least every six months unless continuous monitoring is in place. Ask the partner how access logs, change records and test results are retained inside the enclave, and who reviews them. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the reports.
What should we ask an implementation partner before signing?
Ask for a written scope, a list of deliverables and a clear plan for each phase: discovery, offline mirror build, configuration, migration, testing, cutover and support. Request the upgrade approach for both the platform and custom modules, including how a test database is produced and checked before production. Ask how they verify the integrity and authenticity of every package carried across the boundary, who holds the runbooks, and what training your staff receive. Finally, ask what support looks like after go-live, whether it is a retainer or a separate engagement, and which items are excluded from the fixed scope.
Which evidence an assessor asks for from an isolated ERP
This table maps each item an assessor typically requests from a self-hosted ERP in an isolated network to the control it supports and the component that produces it. Read it as a checklist to set up collection before the assessment, not after. Auditors and certification bodies issue the opinions; DeployOpen prepares the systems, controls and evidence they review.
| Evidence item | Control it supports | Produced by | Where it usually fails |
|---|---|---|---|
| Transfer register and hash checks for every package | NERC CIP-013-2 software integrity and authenticity of vendor software and patches | Transfer log kept by the operator, with checksum or signature verification run before each import across the boundary | Packages are copied in without a recorded hash or signed-off transfer entry |
| Change tickets and test database results for each upgrade | FTC Safeguards Rule change management procedures under 16 CFR 314.4 | Ticketing system, plus the upgraded test database and its test results from Odoo's upgrade process or the ERPNext staging site | Upgrades applied directly to production, or test results not linked to the ticket |
| Role and MFA configuration exports | FTC Safeguards Rule multi-factor authentication for users of information systems under 16 CFR 314.4 | ERP role and permission exports, plus the identity provider or MFA configuration held inside the enclave | MFA covers the portal but not direct API or admin access, or roles are exported without a date |
| Audit log exports of user activity | FTC Safeguards Rule logging of authorized user activity under 16 CFR 314.4 | ERP audit trail, forwarded to a log store inside the enclave and retained under the operator's policy | Logs stay on the application server with no retention rule or tamper protection |
| Encryption settings for data at rest and in transit | FTC Safeguards Rule encryption requirements under 16 CFR 314.4 | Database and disk encryption configuration, plus TLS settings for the reverse proxy and internal services | Backups, attachments or replicas are left unencrypted, or internal traffic is not covered |
| Retention configuration for financial records | SEC Rule 17a-4(b) retention where the firm is a broker-dealer, as applicable | ERP retention settings, backup schedules and archive records kept inside the enclave | Retention is set for live data but not for backups, archives or deleted records |
| Penetration test and vulnerability assessment reports | FTC Safeguards Rule testing cadence under 16 CFR 314.4(d)(2) where continuous monitoring is not in place | Independent testers working inside the enclave, plus vulnerability scan output from the scanner the operator runs | Scans run on schedule but findings are not tracked to closure, or the test is older than six months |
What to ask an implementation partner about enclave delivery
Start with the offline mirror, because every later answer depends on it. Ask how the partner builds the package mirror for Odoo or ERPNext, which artifacts it carries across the boundary (Python dependencies, Node assets, database images, Docker images or the source tree), and how each artifact is hashed and signed before it crosses. Ask who holds the signing keys and how a reviewer confirms that the package in the enclave matches the one that was approved outside it. Ask for the written procedure for verifying packages against the vendor's published checksums, and for the log that records each transfer. This is the control behind software integrity and authenticity under NERC CIP-013-2 if you operate in that sector, and a similar evidence trail will be needed in other regulated settings.
Next, ask how the partner proves an upgrade works without vendor access. For Odoo, ask whether the partner plans to use the upgrade service, which requires an Enterprise subscription and is not available to Community users, and how it will run the upgraded test database inside the enclave if the service cannot reach the enclave. For ERPNext, ask how a new minor or major release is built, tested on a copy of production data with the scheduler and workers switched off, and rolled back. Ask how Enterprise subscription activation with the subscription code is handled in a closed network, and who renews it. Ask which features are disabled or replaced, such as external AI calls, online app stores, mail relays and any module that fetches data from the internet, and who approves each change. Finally, ask who delivers localization and tax content as updates into the enclave, how often, and how the partner tests those updates before they reach production.
How DeployOpen scopes, builds and supports this function in an enclave
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own air-gapped or isolated network. For an ERP in an enclave, that means agreeing the edition, the offline update path and the support model in writing before any package crosses the boundary.
How we scope
- Confirm which edition and plan the enclave needs, since on-premise hosting is tied to the Odoo Custom plan and air-gapped features often sit in paid tiers
- List every module and feature, and flag any that call external services such as online AI, mail relays or license checks
- Agree the written scope, deliverables and timelines with the client before work starts, as engagements are fixed-scope
How we build
- Prepare the offline package set, container images and dependency bundles on a staging side, then verify each item's integrity before transfer
- Configure the ERP, integrations and identity sources inside the enclave, with customizations kept as versioned custom modules
- Test the ERP and its upgrade path against a copy of production data, with external calls disabled and documented
How we hand over
- Deliver the runbooks for installation, offline update delivery, backup, restore and the transfer procedure across the boundary
- Document configuration, access roles and audit logging so the client's assessors can trace changes to approved records
- Train the client's administrators to run the system, apply updates from approved media and recover it without vendor access
How we support
- Offer ongoing support, upgrades and testing as a retainer, scoped separately from the implementation
- Plan each major upgrade as a rehearsal on an isolated copy before any production change is approved
- Confirm with the vendor which support and security patch periods apply to the chosen version, since these differ by release
