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.12 to 1.11 From 9.2 to 9.1

From version 9.1

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

Change comment: There is no comment for this version

To version 1.12

edited by Agnease
on 2026/05/19 03:17

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Title

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

Content

@@ -32,7 +32,6 @@
              <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>
@@ -52,22 +52,6 @@
            <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>
--
--          <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>
--
--          <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>
@@ -87,11 +87,6 @@
              public or private. But staying close to supported versions makes security maintenance more manageable.
            </p>
--          <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>
--
            <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
@@ -106,11 +106,6 @@
              planning an upgrade.
            </p>
--          <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>
--
            <h3>4. Infrastructure requirements evolve</h3>
            <p>
              XWiki upgrades can involve more than the application itself. Java, Tomcat, the database, Docker images,
@@ -124,13 +124,8 @@
              should be part of the validation plan.
            </p>
--          <h2 id="upgrade-checklist">XWiki upgrade planning checklist</h2>
++          <h2 id="upgrade-checklist">Practical checklist before planning an upgrade</h2>
--          <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>
--
            <ul class="resource-checklist">
              <li>Identify the current XWiki version and the target version.</li>
              <li>Check whether intermediate upgrade steps are needed.</li>
@@ -182,51 +182,6 @@
              review, staging validation, production rollout, documentation and follow-up.
            </p>
--          <h2 id="upgrade-faq">XWiki upgrade FAQ</h2>
--
--          <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>
--
--          <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>
--
--          <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>
--
--          <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>
--
--          <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>
--
--          <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>
--
            <div class="resource-cta">
              <h3>Need help planning an XWiki upgrade?</h3>
              <p>
@@ -240,55 +240,5 @@
        </div>
      </div>
    </section>
--
--  <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,1 +1,0 @@
1		-Learn why regular XWiki upgrades matter for security, stability, extension compatibility and long-term maintenance, especially for production XWiki instances.

metaTitle

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