How X-Road upgrade and support work changes as X-Road 7 nears the end of feature work
Keeping Central Servers and Security Servers on a supported X-Road 7 release is ongoing operational work. Planning the move to X-Road 8 is a separate decision, with its own budget, owner and test plan. Teams that merge the two often delay routine patching while they wait for the larger project, which can leave production servers on versions that no longer receive the fixes they need. Treat patching as a standing duty, and treat X-Road 8 as a project with a clear go or no-go checkpoint. The sections below describe what triggers work on each track.
Four kinds of event usually start upgrade work. The first is a security patch for the release a server runs, which may arrive as a point release on the 7.8.3, 7.7.4 or 7.6.5 line. The second is a host operating system reaching end of life. Security Servers are supported on Ubuntu Server 22.04 and 24.04 LTS and on Red Hat Enterprise Linux 8 and 9, so check which of those your hosts run and confirm the vendor support dates in your own environment. The third is a decision to plan the X-Road 8 move. The fourth is staff turnover, which often exposes undocumented steps in the upgrade runbook, PostgreSQL maintenance and HSM token handling.
As X-Road 7 nears the end of feature work, the release line itself changes. NIIS has described X-Road 7.8.0 as the last new-feature release of X-Road 7 and intends to keep maintaining the line with bug fixes and security patches beyond 2026, but the length of that period has not been decided. Each 7.x upgrade is now mainly about staying on a patched line, not about picking up new capability. Ask NIIS or your support provider which release lines will receive fixes and for how long, and record the answer in your change calendar. Also inventory every Central Server and Security Server, with its exact version, operating system, PostgreSQL location and HSM setup, because the upgrade order and rollback plan depend on those facts.
X-Road 8 is the other moving part. The project lists 8.0.0 Beta 2 as available for testing, with a production release scheduled for December 2026, and positions it as a data space solution with improved monitoring and cloud compatibility. A beta and a scheduled date are planning inputs and should not set your cutover date. Use a non-production environment to test the features your members depend on, and confirm which integrations, certificates and trust service arrangements carry over. A readiness assessment should list what must change, who approves each change and what would stop the move. Keep 7.x servers patched until the production cutover is complete and your members have agreed the timetable.
For in-house versus partner, most organizations with an existing X-Road team can handle routine patching internally, provided they have a tested runbook, a non-production copy of each server and someone who can restore from backup. Outside help is more commonly used for multi-member upgrades, where several member servers must change in a coordinated order, for cutovers that need a defined rollback window, and for assessments of X-Road 8 readiness. Ask any partner for a written scope that names the versions, servers, environments, testing and handover documents, and for a support arrangement that states response expectations in writing. DeployOpen works on fixed-scope engagements and offers ongoing support as a retainer, with terms agreed before work begins.
What an X-Road upgrade and support engagement includes
An upgrade and support engagement is built as a sequence of work packages, each ending in a named deliverable. The packages start with an accurate inventory of every X-Road component and host, then move through planning, tested execution and verification, and finish with runbooks and an optional retainer. Scope, service levels and response times are set in writing for each engagement and are not implied by this section.
Version and host inventory
Record the version, operating system, host, network zone and database backend of every Central Server, Security Server and Configuration Proxy in the ecosystem. Confirm which members depend on each Security Server and which hosts are shared with other services. The deliverable is an inventory register that becomes the baseline for every later step, and it is the first thing to check before quoting an X-Road 7 to X-Road 8 transition.
Upgrade plan and rollback design
Produce a change plan that sets the target X-Road 7 release, the order in which Central Server and Security Servers are upgraded, and the maintenance windows for each member. Define the rollback point for each host, including database and configuration backups and the conditions that trigger a rollback. The deliverable is a change plan with a tested rollback procedure, and the reader should confirm that the rollback has been exercised in non-production.
Non-production and production execution
Run the upgrade first in a non-production environment that mirrors the production Security Server layout, including the PostgreSQL backend and HSM-backed keys where used. Repeat the same steps in production only after the non-production results are reviewed and signed off. Check that the PKCS#11 configuration, firewall ports 5500, 5577, 4000 and the information system ports still behave as before after each host is changed.
Post-upgrade verification
Test message exchange between member Security Servers, OCSP responses, global configuration download and the admin roles that map to LDAP groups, if that integration exists. Compare the configuration and service registrations against the inventory register so that no member connection is left silently changed. The deliverable is a verification record that lists each check, its result and the person who accepted it.
Operations runbooks and handover
Write runbooks for the routine tasks the client's operators will perform, such as restarting services, rotating credentials, backing up the database, reading logs and applying patches. Walk the client's team through each runbook and record the handover. The deliverable is a handover runbook set that the client can maintain after the engagement ends, with clear owners for each procedure.
Optional support retainer
A retainer can cover patch monitoring for the X-Road 7 releases in use, incident response within agreed hours, and periodic version reviews that assess the upcoming X-Road 8 production release scheduled for December 2026. Confirm in writing the response times, coverage hours, escalation path and what is excluded. The deliverable is a retainer agreement and a periodic version review report.
Which X-Road 7 release line to stay on and why patch level matters
The first decision for any X-Road 7 operator is to confirm that every Central Server and Security Server runs a version in the supported set, which NIIS lists as 7.8.3, 7.7.4 and 7.6.5. The current release is 7.8.3. A server on any older release line is outside that supported set, so it should be scheduled for upgrade even if it is working well today. Inventory each server by its installed package version, not by the version in a change ticket, because Central Servers and Security Servers are often upgraded at different times and drift is common in multi-member environments.
X-Road 7.8.0, released at the beginning of February 2026, is the last new-feature release of the X-Road 7 line. After that, X-Road 7 work is limited to bug fixes and security patches. NIIS intends to maintain X-Road 7 beyond 2026 with those fixes, but it has not decided how long that maintenance period will be. Do not assume an end date that NIIS has not published. Instead, ask NIIS in writing for its current position on X-Road 7 maintenance, and ask your own governance body to record how that position affects your planning horizon for the X-Road 8 move.
When choosing a target release, select the newest version within the supported set that your change window and member coordination allow, and prefer the 7.8.x line for servers that will still be running X-Road 7 for a long period. Within a line, patch level matters most because security patches arrive as later releases. A server that stays on an early patch level of a supported line remains supported in name but misses fixes that its peers already have. Plan upgrades so that Central Server and Security Server versions stay compatible with the other members you exchange data with, and confirm that compatibility in the release notes before you commit to a date.
Before each upgrade step, read the release notes for every version between your current level and the target, not only the final one. Check for changes to database schema steps, required PostgreSQL versions, supported operating system releases, changes to the hardening settings described in the NIIS guidelines, and any change that affects HSM driver packages such as xroad-addon-hwtokens if you use hardware-backed keys. Record the result of each check in your change record, and confirm with the NIIS release page that the target version is still listed as supported on the day you deploy it.
What drives X-Road upgrade cost and duration
This table lists the factors that most change the effort of an X-Road upgrade, why each one matters, and one way to keep it down. Read it before requesting a quote, because the number of Security Servers, the database setup and the connected systems usually move the schedule more than the software itself.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of Security Servers and whether each is a separate host | Each host needs its own backup, upgrade, verification and rollback step, so effort grows with host count rather than with software complexity. | Standardize build images and upgrade in ordered waves, starting with a non-production member, then repeat the same runbook. |
| Central Server and Configuration Proxy in the same window | Upgrading them together means one coordinated change for global configuration, which adds coordination but avoids running mixed versions for longer. | Confirm the version compatibility rules with NIIS release notes before choosing a sequence, and schedule a single window if the change board allows it. |
| Operating system and whether an OS upgrade is bundled | Moving between Ubuntu Server 22.04 and 24.04 LTS on x86-64, or between RHEL 8 and 9, adds package, kernel and driver testing on top of the X-Road change. | Separate the OS upgrade from the X-Road upgrade where possible, and confirm the current OS is on the supported list for the target X-Road release. |
| PostgreSQL location and backup needs | A local database is backed up with the host, while a remote database or managed service such as AWS RDS or Azure Database for PostgreSQL needs its own backup, restore test and network path checks. | Take and test a verified database backup before the change, and confirm the managed service's maintenance window and version support in writing. |
| HSM-backed keys through PKCS#11 and xroad-addon-hwtokens | Hardware token access must be re-tested after the upgrade, and vendor PKCS#11 driver versions may need to match the new packages, which can involve the HSM vendor. | Ask the HSM vendor to confirm driver compatibility in advance and keep a test token or sandbox slot for pre-production checks. |
| Number of connected information systems and services | Every consumer and producer service that exchanges messages through the Security Server should be tested after the change, so more services mean more test cases and more coordination. | Maintain a service inventory with owners and a standard smoke test per service, and prioritize services by business impact. |
| LDAP or PAM admin integration | SSSD and PAM settings, LDAP group-to-role mappings and admin login paths must be checked after the upgrade, and a mistake can lock administrators out. | Keep a local break-glass administrator path documented and tested, and export the current PAM and SSSD configuration before the change. |
| Member organizations to inform or coordinate | Members that rely on your Security Server or on shared services may need notice, test windows or certificate and endpoint checks, which adds scheduling effort outside the technical team. | Agree a notification template and a fixed test window with member contacts early, and name a single coordination owner. |
| Number of environments | Each environment, such as development, test, staging and production, normally repeats the upgrade and verification, so effort scales with the number of environments. | Use the earlier environments to refine the runbook, then reuse the same scripts and checklists in later environments. |
Planning the X-Road 8 move before its production release
X-Road 8 "Spaceship" is available for testing as 8.0.0 Beta 2, and its production release is scheduled for December 2026. NIIS positions it as a data space solution with improved monitoring and cloud compatibility. Those goals justify planning now, but the date is a schedule target, not a commitment you can budget against. Treat the move as its own assessment project, separate from routine X-Road 7 patching. Keep your Central Server and Security Servers on a supported 7.x release while the assessment runs. The X-Road releases page lists 7.8.3, 7.7.4 and 7.6.5 as supported today.
A beta is not a production baseline. Its packaging, configuration, database handling and upgrade path can change before December 2026, so do not assume an in-place upgrade from 7.x. Plan three things. First, a test environment that mirrors your Security Server hosts, PostgreSQL arrangement and HSM setup. Second, a compatibility review of every service you publish or consume, including the certificates, trust anchors and time-stamping arrangements your members depend on. Third, a formal decision point where you choose to migrate, wait or run both versions in parallel. Record every item you cannot test against the beta yet, because those become the open risks in the decision.
Before committing budget, confirm three things with NIIS and in the release notes. First, the supported migration path from 7.x to 8.x, including whether members can migrate in stages. Second, the supported operating systems and PostgreSQL options. The 7.x Security Server runs on Ubuntu Server 22.04 and 24.04 LTS and on Red Hat Enterprise Linux 8 and 9, with local or remote PostgreSQL, but confirm whether that list and the RAM and disk minimums change for 8.x. Third, whether PKCS#11 hardware token support and the RSA and EC key handling carry over unchanged, since key migration affects your trust services. Ask your trust service provider to confirm its side in writing, and keep the migration budget lines open until these answers arrive.
Support on X-Road 7 is what keeps production stable while this assessment runs. The 7.8.0 release, published in early February 2026, is the last new-feature release of X-Road 7. NIIS intends to maintain X-Road 7 with bug fixes and security patches beyond 2026, but it has not decided how long that maintenance period will be. Treat that as an open risk. A support contract should cover X-Road 7 patching, operating system upgrades and incident response. Ask the provider what happens once the end of maintenance is announced, and whether the contract includes help building the 8.x test environment. Also check that your hardening settings still hold after each upgrade.
How an X-Road upgrade runs from inventory to handover
The sequence moves an X-Road estate from its current state to a verified, supported release without breaking member connections, and ends with the team holding the runbooks, checks and calendar to run it afterwards. Each phase closes with a written output that the governance owner can sign off.
Inventory versions, hosts and dependencies
Start by recording what is actually running. For each Central Server, Security Server and Configuration Proxy, capture the X-Road version, host operating system and release, the PostgreSQL setup (local or remote, including any managed service), whether an HSM is in use and through which PKCS#11 driver, who holds admin access and through which account model, and which information systems and member connections depend on the server. The output is a signed inventory that the governance owner and the server operators have both reviewed. Gaps found here, such as undocumented HSM tokens or shared admin accounts, become named items in the plan rather than surprises during the change window.
Agree the target release and rollback plan
Select the target release against the supported version list and the governance decision on X-Road 7 maintenance or the move toward X-Road 8, which is available for testing as 8.0.0 Beta 2 with production planned for December 2026. The plan records the upgrade path for each host, the operating system changes if any, the backup and restore points for databases and key material, and the rollback steps with the conditions that trigger them. Confirm the rollback is written for each server role. The output is an approved upgrade plan with a rollback procedure that the operators have walked through on paper.
Upgrade and test in a non-production environment
Build or refresh a test environment that matches production in version, operating system, database type and HSM configuration as closely as the client allows. Apply the upgrade there first, then run connection tests from a test member or Security Server to confirm that message exchange works, that OCSP responses are served, and that the admin UI and the information system access ports behave as the firewall rules intend. Record each test result and any configuration drift. The output is a test report that lists every failed check, its cause and the fix that was verified before production work was scheduled.
Agree the change window with members and governance
Share the tested plan with the member organizations that connect to the affected servers and with the governance owner, who usually coordinates the change calendar for the ecosystem. Agree the window, the contact points for each member, the escalation path and the criteria for going or not going ahead. Members that depend on specific services may need to confirm their own readiness. The output is a written change approval listing the window, the responsible contacts and the go and no-go conditions. Lengths of this phase and the earlier phases depend on the effort drivers in the next section, and should be fixed in the written scope.
Run the production upgrade and verify
Execute the upgrade in the agreed window, following the plan step by step and logging each action. After the change, verify three things before declaring success: message exchange with at least one connected member succeeds end to end, OCSP responses are reachable on the external port and return valid status, and admin access works for each role through the account model in use, including any PAM or LDAP integration. If a check fails, the rollback criteria from the plan decide the next action. The output is a completion record with timestamps, check results and the sign-off from the governance owner.
Hand over runbooks, checks and the support calendar
Close the engagement by transferring the operating knowledge to the client team. This covers updated runbooks for backup, restore, certificate renewal and rollback; a set of monitoring checks for message exchange, OCSP, database connectivity and HSM availability; and a support calendar that lists upcoming X-Road release and maintenance dates as they are published, plus the client's own renewal and review dates. The handover is complete when the client operators run one check or procedure themselves while the DeployOpen team observes. The output is the signed handover pack and the calendar owner named in writing.
Which X-Road support tasks stay in-house and which go to a partner
This table compares, task by task, what the organization should keep in its own hands and what a partner can carry, with the skills each task needs and whether a retainer or a fixed-scope project usually fits. Read each row as a split of responsibility, not a yes or no, because most tasks are shared. The main takeaway is that governance decisions and the cutover with member organizations stay with the organization, while recurring technical watching and testing are often the best candidates for a retainer.
| Task | Ownership and skills needed | Better fit |
|---|---|---|
| Routine patch watching and release notes | Usually in-house reads the notices and decides priority. Needs Linux administration and a working knowledge of X-Road release notes. | Retainer, for recurring monitoring and summaries |
| Change approval and governance decisions | Stays with the organization. Needs governance and change management, and clear authority over the Central Server and Security Server owners. | Neither. Kept in-house, with partner input as a documented option |
| Test environment maintenance | Shared. A partner can keep a test Security Server aligned with production versions. Needs Linux administration, PostgreSQL and integration testing. | Retainer |
| Upgrade plan and rollback design | Partner drafts the plan and rollback steps, the organization approves them. Needs integration testing, PostgreSQL and Linux administration. | Fixed-scope project for each upgrade |
| Cutover window with member organizations | Stays with the organization, since it owns member relationships. A partner can prepare the runbook and checks. Needs governance and change management. | Fixed-scope project, with the organization leading the coordination |
| PostgreSQL and backup work | Shared. Restore testing is the item most often skipped. Needs PostgreSQL administration and Linux administration, including remote or managed database setups. | Retainer for backups and restore tests, fixed scope for migrations |
| HSM and certificate handling | Shared, with key custody staying with the organization. Needs PKI and certificate management and HSM operations using PKCS#11 drivers. | Fixed-scope project for key or HSM changes, retainer for routine renewals |
| LDAP or PAM admin changes | Usually in-house, because directory groups belong to the identity team. A partner can map roles to groups. Needs Linux administration with SSSD and PAM knowledge. | Fixed-scope project for the initial mapping, then in-house |
| After-hours incident response | Organization owns the on-call decision. A retainer can add partner responders for defined severities. Needs Linux administration, PostgreSQL and integration testing. | Retainer, with the severity levels and response terms written into it |
What goes wrong in X-Road upgrades and how to prevent it
Most X-Road upgrade failures come from changes that touch member connections, databases, hardware tokens and admin access in the same window. Each card names one risk, the component it affects and a check to run before or after the change. Running these checks lets the team confirm connectivity and access before member organizations notice a problem.
Upgrading without checking member connections
A Security Server upgrade can stop message exchange with members if the team does not first confirm that peers can still reach it. Before the change, verify that TCP 5500 for message exchange and TCP 5577 for OCSP are reachable from external networks, and that TCP 4000 and TCP 8080 or 8443 remain available from internal networks. Test OCSP responses from a peer's network path, not only from inside your own, and record the results so you can compare them after the upgrade.
Changing the operating system and X-Road together
When an upgrade changes both the operating system and the X-Road version in one window, a failure leaves no clear point to roll back to. Stage the change so the OS move and the X-Road move happen in separate windows, each with its own snapshot or backup. Confirm that the target OS is on the Security Server support list (Ubuntu Server 22.04 and 24.04 LTS on x86-64, or Red Hat Enterprise Linux 8 and 9) and rehearse restoring the previous state before the production change.
PostgreSQL access after a database move
Moving the Security Server to a remote or managed PostgreSQL service, such as AWS RDS or Azure Database for PostgreSQL, can break connections because of network rules, TLS settings or missing privileges for the X-Road database user. Before cutover, test the connection from the Security Server host using the exact credentials and network path it will use. After cutover, confirm that the application can read and write its schema and that a restore from backup works against the new database.
HSM token access failing after upgrade
An upgrade can leave the Security Server unable to use a hardware security module, even when the HSM itself is healthy, because the PKCS#11 driver, the xroad-addon-hwtokens package or the token permissions no longer match. Record the driver version and the package version that work today, then compare them with the target versions before the change. After the upgrade, confirm that signing operations succeed for both RSA and EC keys, and check that the service account can still open the token without elevated rights.
Admin role mappings broken by SSSD changes
When LDAP groups are linked to X-Road administrative roles through PAM and SSSD, an OS upgrade or SSSD configuration change can silently remove the mapping, so administrators lose access or gain the wrong role. Export the current mapping of directory groups to the five roles (Security Officer, Registration Officer, Service Administrator, System Administrator and Security Server Observer) before the change. After the upgrade, log in with one test account per role and confirm that each role can perform only its intended tasks.
Treating the X-Road 8 beta as production-ready
X-Road 8 "Spaceship" is currently available for testing as 8.0.0 Beta 2, with the production release scheduled for December 2026, so an assessment that treats it as a production target carries unverified assumptions. Plan assessments against the supported X-Road 7 releases (7.8.3, 7.7.4 and 7.6.5) and the published 7.8.0 maintenance intent, and label any X-Road 8 findings as test results. Ask the vendor or NIIS to confirm the production date, migration path and support window before committing budget or member timelines.
What your team must provide before an X-Road upgrade starts
The inputs your team supplies before an X-Road upgrade starts decide whether the upgrade plan can be written in one pass or whether it stalls while questions are answered. Start by confirming administrative access to the Central Server and to each Security Server, and name a Security Officer and a System Administrator for each instance. The Security Officer manages keys, certificates and the trust configuration, and the System Administrator manages the operating system and services. If these two people are not named and available during the window, the plan cannot assign who approves and who executes each step.
Next, record the exact current X-Road version and the operating system release on every server. The supported X-Road 7 releases are 7.8.3, 7.7.4 and 7.6.5, and the Security Server is supported on Ubuntu Server 22.04 and 24.04 LTS (x86-64) and on Red Hat Enterprise Linux 8 and 9. A host outside those combinations changes the upgrade path, and the plan must show that step first. Also provide PostgreSQL connection details for each Security Server, whether the database is local or remote, and the date and result of the latest backup. Ask for a restore test record, not only a backup job status, because a backup that has never been restored is not evidence that the upgrade can be rolled back.
If your keys are held in a hardware security module, provide the HSM model, firmware version and PKCS#11 driver details, and confirm that the xroad-addon-hwtokens package is in use. Key handling is one of the highest-risk steps in an upgrade, so the plan needs to know which keys are HSM-backed and which are stored in software. Provide access to a non-production environment that mirrors production as closely as practical, including the same operating system releases, database engine version, HSM or software key setup and network path. Where a mirror is not possible, state the differences in writing, since each difference becomes a verification gap.
Provide the list of connected information systems, the service owner for each, and the member contacts who must be told when their connections change. Each connected system needs a named contact who can confirm that its service endpoints work after the upgrade. If admin logins are centralized through LDAP or Active Directory with PAM and SSSD, provide the directory server details, the bind account and the group mappings to the five X-Road administrative roles, because a login failure during the window can block administrators from reaching the admin UI. Finally, obtain the change window approved by your governance body and a single named decision owner who makes the go or no-go call, with authority to stop the work if a check fails.
Questions buyers ask before hiring outside help for X-Road upgrades
How is the cost of an X-Road upgrade set?
A fixed-scope quote sets the cost. DeployOpen agrees the scope, deliverables and timeline in writing before work starts, and the quote follows from that written scope.
Ask the quote to separate the one-time project work (assessment, upgrade planning, staging tests, cutover, rollback and documentation) from any recurring retainer for patch monitoring, support and scheduled upgrades. The main cost drivers are the number of Central and Security Servers, the database topology, whether HSMs are involved, how many member connections need regression testing, and whether governance documents must change.
DeployOpen does not publish a price list, so ask for line items, exclusions and assumptions in the same document.
What makes an X-Road upgrade take longer than expected?
The biggest effort drivers are the number of servers and environments, the version gap, and how much else changes during the same window.
Common drivers:
- Operating system upgrades combined with the X-Road upgrade
- Local versus remote PostgreSQL and the backup approach for the database
- HSM-backed keys that must be re-verified through PKCS#11 drivers
- Connected services and members that need regression testing
- Change approval windows and governance sign-off
The plan should name each dependency and the client decision that unblocks it. Delays usually come from waiting on approvals, test data or access, so ask who owns each of those.
How long does an X-Road upgrade take from start to finish?
The duration depends on the agreed scope and plan, so there is no standard figure to quote in advance. Two engagements with the same server count can differ widely if one includes HSM changes, a database move or a larger member test cycle.
Ask for the timeline in writing, with milestones for assessment, staging upgrade, member testing, cutover, and a post-upgrade review. The timeline should show which dates depend on your approvals, test windows and change calendar, and what happens if one of those dates moves. Confirm the cutover window with your trust community or governance body before the plan is fixed.
Can our team upgrade X-Road without outside help?
Yes, if your team has the skills and time to test. The work calls for Linux administration on a supported platform (Ubuntu Server 22.04 or 24.04 LTS, or Red Hat Enterprise Linux 8 or 9), PostgreSQL administration for local or remote databases, and PKI and certificate handling, including HSM integration where it applies.
Governance skills matter too, because member agreements, trust service decisions and communications to other members can change the plan. Most of the risk sits in testing. Your team needs a non-production environment that resembles production, a rollback plan that has been rehearsed, and enough time to check member connections before cutover. Confirm that these needs are covered before you decide.
What do we need to prepare before an X-Road upgrade?
Prepare a written readiness pack before scoping starts. Missing items are a common cause of schedule changes, so gather them early.
- Inventory of Central Servers, Security Servers, versions, operating systems and hosts
- Database topology, backup status and a tested restore procedure
- HSM models, PKCS#11 drivers and key custody arrangements
- Firewall rules for ports 5500, 5577, 4000, 8080 and 8443 where they apply
- Non-production environment and access for testing
- List of connected services and consumers for regression testing
- Named decision makers, change windows and rollback approval
- Certificate and trust service status, plus admin access and directory integration details
Ask the partner to confirm which items are needed for your scope.
Should we upgrade to X-Road 7.8.3 now or wait for X-Road 8?
It depends on your governance decision and the supported-release position, so start with those. The current X-Road release is 7.8.3, and the supported versions are 7.8.3, 7.7.4 and 7.6.5.
X-Road 7.8.0, released at the beginning of February 2026, is the last new-feature release of X-Road 7. NIIS intends to maintain X-Road 7 with bug fixes and security patches beyond 2026, but has not decided how long that period will last. X-Road 8 is available as 8.0.0 Beta 2 for testing, and its production release is scheduled for December 2026.
Your trust community or governance body usually decides timing and member coordination. Confirm the current support position with NIIS before you commit to a date.
What does an X-Road support contract cover and what does it exclude?
A support contract covers the services named in its written scope, typically patch monitoring, incident response and upgrades agreed in advance. It is a recurring retainer, billed separately from a one-time upgrade project.
It does not guarantee outcomes. It cannot promise that a fault will never occur, and it does not guarantee a resolution time unless the contract states a response target. It also does not cover governance decisions, trust service provider terms, member systems outside the agreed scope, or the reports that independent auditors issue.
Check response targets, service hours, named contacts and exclusions in the signed contract before you rely on them.
How DeployOpen scopes, delivers and hands over X-Road upgrade and support
DeployOpen starts with an inventory of your Central Server and Security Servers, then agrees a written scope before any change is made. The work covers in-place upgrades on supported X-Road 7 versions, preparation for X-Road 8, and documented handover to your operations team, with ongoing support available as a retainer.
How we scope
- Inventory each Central Server and Security Server, including operating system, PostgreSQL location and installed X-Road version.
- Map current version against the supported X-Road 7 releases and the planned X-Road 8 timeline, then record the gap in writing.
- Agree a fixed-scope statement listing servers, deliverables, test environments and the upgrade windows your members accept.
How we build
- Rehearse each upgrade on a non-production copy of the Security Server, including its database, keys and HSM connection.
- Verify message exchange on ports 5500 and 5577 and admin UI access before and after each change.
- Review hardening settings, such as account lockout, key-only SSH and allowed-hostnames, against the NIIS security hardening guidelines during each upgrade.
How we hand over
- Deliver a runbook with step-by-step upgrade, rollback and backup procedures for each server role.
- Document configuration, certificate and HSM key locations, and the admin role assignments your staff will use.
- Walk your operations team through the runbook and record which steps they have run themselves before handover is signed off.
How we support
- Offer ongoing support, upgrades and patch review as a retainer agreed separately from the initial scope.
- Track NIIS maintenance releases and security patches for X-Road 7 and report what applies to your environment.
- Confirm with NIIS and your trust service provider the X-Road 8 production date and migration path before scoping the next phase.
