Changes for page Why You Should Upgrade XWiki Regularly for Security and Stability

Last modified by Agnease on 2026/05/26 10:58

Manage
- Copy
Actions
- Export
- Print Preview
Viewers
- Source
- Siblings
- Content
- Comments
- Attachments
- History
- Information
- Likes

From 1.2 to 1.3 From 9.2 to 9.3

From version 1.3

edited by Agnease
on 2026/05/01 11:42

Change comment: There is no comment for this version

To version 9.2

edited by Agnease
on 2026/05/26 10:45

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (2 modified, 0 added, 0 removed)
Objects (0 modified, 1 added, 0 removed)
- Agnease.Code.SEODetailsClass[0]

Details

Page properties

Title

...	...	@@ -1,0 +1,1 @@
	1	+Why You Should Upgrade XWiki Regularly for Security and Stability

Content

@@ -1,121 +1,303 @@
--= Why Upgrade Your XWiki Instance to the Latest LTS Version? =
++{{velocity}}
++#set ($discard = $xwiki.ssx.use('PublicWebSite.WebHome'))
++{{html clean="false"}}
--Your XWiki instance may be working well today, but if it is running an older version, it may already be missing important security fixes, stability improvements, compatibility updates, and platform enhancements.
++  <section class="resource-header" aria-labelledby="hero-title">
++    <div class="container">
++      <div class="text-center">
++        <div class="hero-kicker">
++          <i class="fa fa-refresh" aria-hidden="true"></i>
++          XWiki upgrade guidance
++        </div>
++      </div>
--Keeping XWiki aligned with the latest Long Term Support (LTS) version is not only a maintenance task. It is a practical way to reduce operational risk and keep your knowledge platform secure, reliable, and ready for future needs.
++      <h1 id="hero-title">Why upgrading your XWiki instance should be a regular priority</h1>
--{{toc start=2 /}}
++      <p class="resource-summary">
++        A working XWiki instance can still become outdated, harder to maintain and exposed to avoidable risks
++        when upgrades are postponed for too long.
++      </p>
++    </div>
++  </section>
--== Why regular XWiki upgrades matter ==
++  <section class="resource-page">
++    <div class="container">
++      <div class="resource-layout">
--XWiki is actively maintained. With each release cycle, the platform receives bug fixes, security fixes, usability improvements, performance enhancements, and compatibility updates.
++        <aside class="resource-sidebar" aria-label="Page summary">
++          <h4>In this guide</h4>
++          <ul>
++            <li><a href="#why-it-matters">Why upgrades matter</a></li>
++            <li><a href="#upgrade-checklist">Upgrade checklist</a></li>
++            <li><a href="#safe-process">Safe process</a></li>
++            <li><a href="#common-mistakes">Common mistakes</a></li>
++            <li><a href="#upgrade-rhythm">Upgrade rhythm</a></li>
++            <li><a href="#upgrade-faq">FAQ</a></li>
++          </ul>
++        </aside>
--When an instance remains on an older version for too long, the upgrade gap becomes larger. This can make future upgrades more complex, increase the risk of incompatibilities, and leave the platform exposed to issues that have already been fixed in newer versions.
++        <article class="resource-content">
--A regular upgrade strategy helps keep your platform predictable and easier to maintain.
++          <p>
++            Many XWiki instances continue to run for years with only small visible problems. This can create the
++            impression that upgrades are optional, especially when users can still log in, search, edit pages and
++            access the content they need.
++          </p>
--== Security should be a priority ==
++          <p>
++            The real risk is that technical debt accumulates quietly. Security fixes, extension compatibility,
++            authentication behavior, infrastructure requirements and custom code assumptions continue to evolve.
++            The longer an instance remains behind, the more difficult the next upgrade becomes.
++          </p>
--Older XWiki versions may be affected by security vulnerabilities that have already been corrected in later releases.
++          <div class="resource-note">
++            <p>
++              <strong>In practice:</strong> an XWiki upgrade should review the current version, target version,
++              required intermediate steps, installed extensions, custom code, authentication setup, infrastructure,
++              backups, rollback expectations and the business-critical features that must be validated before
++              production is touched.
++            </p>
++          </div>
--Once security advisories and fixes become public, attackers can analyze the disclosed information and use it to target systems that are still running vulnerable versions.
++          <p>
++            An XWiki upgrade is the process of moving an existing instance to a newer XWiki version while preserving
++            content, configuration, extensions, customizations, access rights and business-critical behavior. A safe
++            upgrade is not only a software installation task. It is a controlled maintenance process with preparation,
++            staging validation, production rollout and follow-up notes.
++          </p>
--This means that delaying upgrades can increase the window of exposure.
++          <div class="resource-note">
++            <p>
++              <strong>The main point:</strong> regular upgrades are not only about new features. They reduce security
++              exposure, compatibility risk and long-term maintenance cost.
++            </p>
++          </div>
--Upgrading to the latest LTS version helps reduce this risk by applying the latest available fixes in a stable, production-oriented release line.
++          <h2 id="why-it-matters">Why regular XWiki upgrades matter</h2>
--== Stability and compatibility improvements ==
++          <h3>1. Security fixes accumulate over time</h3>
++          <p>
++            Older versions may miss security-related fixes already available in newer releases. Once security issues
++            become publicly known, running an old version can become a more predictable risk.
++          </p>
--Security is not the only reason to upgrade.
++          <p>
++            This does not mean every old instance is immediately exposed in the same way. The real impact depends on
++            your configuration, installed extensions, access model, authentication setup and whether the instance is
++            public or private. But staying close to supported versions makes security maintenance more manageable.
++          </p>
--Newer XWiki LTS versions also include important improvements related to:
++          <p>
++            For a broader view of security-related checks, see
++            <a href="$xwiki.getURL('resources.xwiki-security-review')">what an XWiki security review should actually include</a>.
++          </p>
--* platform stability
--* extension compatibility
--* authentication and integration support
--* user interface improvements
--* performance and reliability
--* bug fixes accumulated across multiple releases
--* better support for modern Java and application server environments
++          <h3>2. Large upgrade gaps are harder to control</h3>
++          <p>
++            A small, regular upgrade is usually easier to validate than a large jump after several years. Large gaps
++            mean more release notes, more compatibility changes, more extension checks and more uncertainty around
++            custom code.
++          </p>
--These improvements are especially important for organizations that rely on XWiki as a central knowledge base, intranet, documentation portal, or business process platform.
++          <h3>3. Extensions and customizations can become fragile</h3>
++          <p>
++            XWiki instances often include installed extensions, custom Velocity scripts, macros, templates, sheets,
++            UI extensions, Java components or business-specific applications. These elements need to be reviewed when
++            planning an upgrade.
++          </p>
--== Major platform transitions require planning ==
++          <p>
++            For more details on organizing custom work, see
++            <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
++          </p>
--Some upgrades are more significant than others.
++          <h3>4. Infrastructure requirements evolve</h3>
++          <p>
++            XWiki upgrades can involve more than the application itself. Java, Tomcat, the database, Docker images,
++            reverse proxy configuration, PDF export services and authentication integrations may also need attention.
++          </p>
--For example, the move from XWiki 16.x to XWiki 17.x introduced an important platform change: the migration to Jakarta EE. This also affects the application server layer, requiring environments such as Tomcat 10+ instead of Tomcat 9.
++          <h3>5. Business-critical features need validation</h3>
++          <p>
++            A successful upgrade is not only one where the server starts. Users usually depend on login, permissions,
++            search, dashboards, PDF exports, workflows, notifications, custom applications and important pages. These
++            should be part of the validation plan.
++          </p>
--This type of upgrade should not be treated as a simple file replacement. It requires careful planning, compatibility checks, and proper validation.
++          <div class="resource-inline-cta">
++            <p>
++              <strong>Not sure how risky your current XWiki version is?</strong>
++              A short technical review can clarify the upgrade path, extension compatibility,
++              custom code risks and validation needs before production is touched.
++            </p>
++            <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a quick review</a>
++          </div>
--== A safe upgrade process ==
++          <h2 id="upgrade-checklist">XWiki upgrade planning checklist</h2>
--At Agnease, XWiki upgrades are approached as controlled technical operations.
++          <p>
++            A practical XWiki upgrade plan should cover both the application and the environment around it.
++            The following checklist can be used as a starting point before upgrading a production instance.
++          </p>
--A typical upgrade process may include:
++          <ul class="resource-checklist">
++            <li>Identify the current XWiki version and the target version.</li>
++            <li>Check whether intermediate upgrade steps are needed.</li>
++            <li>List installed extensions and verify compatibility with the target version.</li>
++            <li>Identify custom code: Velocity scripts, macros, sheets, templates, UI extensions and Java components.</li>
++            <li>Review authentication: LDAP, Active Directory, SSO, OIDC, SAML or MFA.</li>
++            <li>Prepare a staging environment or temporary clone of production.</li>
++            <li>Validate backups and clarify rollback expectations.</li>
++            <li>Test important pages, dashboards, permissions, search, jobs, exports and custom workflows.</li>
++            <li>Document the steps, issues found and follow-up recommendations.</li>
++          </ul>
--* reviewing the current XWiki version and infrastructure
--* identifying the recommended target LTS version
--* checking installed extensions and custom developments
--* reviewing authentication and integration dependencies
--* preparing a staging environment when needed
--* testing the upgrade before production
--* planning downtime and rollback options
--* executing the production upgrade
--* performing post-upgrade checks
++          <h2 id="safe-process">A safer upgrade process</h2>
--The goal is to minimize risk while keeping the platform secure, stable, and maintainable.
++          <p>
++            Production should not be the first place where the upgrade is tested. The safest approach is to rehearse
++            the upgrade on staging or a temporary clone, resolve compatibility issues there, then perform the production
++            upgrade with a clear plan.
++          </p>
--== What happens if upgrades are postponed? ==
++          <ol>
++            <li><strong>Prepare a clone:</strong> copy the relevant database, filesystem and configuration.</li>
++            <li><strong>Run the upgrade outside production:</strong> record the steps and issues found.</li>
++            <li><strong>Validate critical features:</strong> login, rights, search, PDFs, workflows, dashboards and integrations.</li>
++            <li><strong>Plan the production window:</strong> backups, downtime, rollback and communication.</li>
++            <li><strong>Document the result:</strong> keep notes for the next upgrade cycle.</li>
++          </ol>
--Postponing upgrades for too long can lead to:
++          <h2 id="common-mistakes">Common mistakes to avoid</h2>
--* increased exposure to known vulnerabilities
--* more difficult future upgrades
--* outdated dependencies
--* compatibility problems with newer integrations
--* unsupported or harder-to-maintain infrastructure
--* higher troubleshooting costs
--* increased risk during emergency upgrades
++          <ul>
++            <li><strong>Upgrading directly in production.</strong> Compatibility issues should be discovered before users are affected.</li>
++            <li><strong>Checking only public pages.</strong> Authentication, restricted spaces and admin features also need validation.</li>
++            <li><strong>Ignoring custom code.</strong> Custom scripts and extensions often create the real upgrade complexity.</li>
++            <li><strong>Skipping backup validation.</strong> A backup is useful only if restore expectations are understood.</li>
++            <li><strong>Keeping no upgrade notes.</strong> Without notes, the next maintenance cycle starts again from uncertainty.</li>
++          </ul>
--Regular upgrades are usually easier, safer, and more cost-effective than large delayed migrations.
++          <h2 id="upgrade-rhythm">How often should XWiki be upgraded?</h2>
--== Who should consider an upgrade? ==
++          <p>
++            For many organizations, a practical rhythm is to stay aligned with the current Long Term Support version
++            and plan upgrades regularly rather than waiting for a major problem. Some environments can upgrade more
++            frequently, while heavily customized instances may require more planning.
++          </p>
--You should consider planning an upgrade if:
++          <p>
++            The important part is not only the exact frequency. It is having an upgrade process that is repeatable:
++            review, staging validation, production rollout, documentation and follow-up.
++          </p>
--* your XWiki instance is not running the latest LTS version
--* your current version is more than one year old
--* your instance contains sensitive or business-critical information
--* you use custom extensions or integrations
--* authentication is connected to LDAP, Active Directory, SSO, OpenID Connect, or SAML
--* your platform is used as an intranet, knowledge base, documentation portal, or workflow system
--* you want to reduce long-term maintenance risks
++          <h2 id="upgrade-faq">XWiki upgrade FAQ</h2>
--== Request an XWiki upgrade assessment ==
++          <h3>Why should XWiki be upgraded regularly?</h3>
++          <p>
++            XWiki should be upgraded regularly to reduce security exposure, keep extensions compatible, avoid large
++            upgrade gaps and make long-term maintenance easier. Regular upgrades are easier to plan and validate than
++            major jumps after several years.
++          </p>
--If you are unsure where your XWiki instance stands, Agnease can help with a concise upgrade assessment.
++          <h3>Is a working XWiki instance safe to leave unchanged?</h3>
++          <p>
++            Not necessarily. An XWiki instance can continue to work from a user perspective while becoming outdated,
++            harder to upgrade and exposed to avoidable risks. Visible functionality is not the same as long-term
++            maintainability.
++          </p>
--The assessment can include:
++          <h3>What should be checked before upgrading XWiki?</h3>
++          <p>
++            Before upgrading XWiki, review the current version, target version, intermediate upgrade steps, installed
++            extensions, custom code, authentication setup, infrastructure, backups, rollback expectations and
++            business-critical features.
++          </p>
--* current version review
--* recommended target version
--* estimated upgrade effort
--* key security and stability reasons to upgrade
--* infrastructure considerations
--* extension and customization risks
--* recommended next steps
++          <h3>Should an XWiki upgrade be tested outside production?</h3>
++          <p>
++            Yes. The safest approach is to rehearse the upgrade on a staging environment or temporary clone, fix
++            compatibility issues there, then perform the production upgrade with a clear plan and rollback expectations.
++          </p>
--Contact Agnease to review your current XWiki setup and plan a safe upgrade to the latest LTS version.
++          <h3>What makes an XWiki upgrade difficult?</h3>
++          <p>
++            XWiki upgrades become more difficult when the version gap is large, extensions are outdated, custom code is
++            undocumented, authentication is complex, infrastructure dependencies changed or critical workflows were not
++            included in the validation plan.
++          </p>
--{{html}}
--<p>
--  <a class="btn btn-primary" href="/xwiki/bin/view/Contact/">Request an upgrade assessment</a>
--</p>
--{{/html}}
++          <div class="resource-note">
++            <p>
++              Related resources:
++              <a href="$xwiki.getURL('resources.xwiki-security-review')">what an XWiki security review should actually include</a>
++              and
++              <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
++            </p>
++          </div>
--== About Agnease ==
++          <div class="resource-cta">
++            <h3>Need help planning an XWiki upgrade?</h3>
++            <p>
++              If your XWiki instance is outdated, customized or business-critical, the safest next step is to review
++              the current version, extensions, infrastructure and validation needs before planning the production upgrade.
++            </p>
++            <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request an upgrade review</a>
++          </div>
--Agnease provides professional XWiki services for organizations that rely on XWiki as a secure and long-term knowledge management platform.
++        </article>
++      </div>
++    </div>
++  </section>
--Services include XWiki upgrades, maintenance, troubleshooting, custom development, integrations, security-aware consulting, and long-term platform support.
++  <script type="application/ld+json">
++  {
++    "@context": "https://schema.org",
++    "@type": "FAQPage",
++    "mainEntity": [
++      {
++        "@type": "Question",
++        "name": "Why should XWiki be upgraded regularly?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "text": "XWiki should be upgraded regularly to reduce security exposure, keep extensions compatible, avoid large upgrade gaps and make long-term maintenance easier. Regular upgrades are easier to plan and validate than major jumps after several years."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "Is a working XWiki instance safe to leave unchanged?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "text": "Not necessarily. An XWiki instance can continue to work from a user perspective while becoming outdated, harder to upgrade and exposed to avoidable risks. Visible functionality is not the same as long-term maintainability."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "What should be checked before upgrading XWiki?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "text": "Before upgrading XWiki, review the current version, target version, intermediate upgrade steps, installed extensions, custom code, authentication setup, infrastructure, backups, rollback expectations and business-critical features."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "Should an XWiki upgrade be tested outside production?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "text": "Yes. The safest approach is to rehearse the upgrade on a staging environment or temporary clone, fix compatibility issues there, then perform the production upgrade with a clear plan and rollback expectations."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "What makes an XWiki upgrade difficult?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "text": "XWiki upgrades become more difficult when the version gap is large, extensions are outdated, custom code is undocumented, authentication is complex, infrastructure dependencies changed or critical workflows were not included in the validation plan."
++        }
++      }
++    ]
++  }
++  </script>
++
++{{/html}}
++{{/velocity}}

Agnease.Code.SEODetailsClass[0]

metaDescription

...	...	@@ -1,0 +1,1 @@
	1	+Learn why regular XWiki upgrades matter for security, stability, extension compatibility and long-term maintenance, especially for production XWiki instances.

metaTitle

...	...	@@ -1,0 +1,1 @@
	1	+Why You Should Upgrade XWiki Regularly for Security and Stability \| Agnease