Skip to Content
Last modified by Agnease on 2026/05/26 10:58
From version 1.11
edited by Agnease
on 2026/05/18 19:01
Change comment: There is no comment for this version
To version 9.5
edited by Agnease
on 2026/05/26 10:58
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,0 +1,1 @@
1 +Why You Should Upgrade XWiki Regularly for Security and Stability
Content
... ... @@ -24,6 +24,18 @@
24 24   <div class="container">
25 25   <div class="resource-layout">
26 26  
27 + <aside class="resource-sidebar" aria-label="Page summary">
28 + <h4>In this guide</h4>
29 + <ul>
30 + <li><a href="#why-it-matters">Why upgrades matter</a></li>
31 + <li><a href="#upgrade-checklist">Upgrade checklist</a></li>
32 + <li><a href="#safe-process">Safe process</a></li>
33 + <li><a href="#common-mistakes">Common mistakes</a></li>
34 + <li><a href="#upgrade-rhythm">Upgrade rhythm</a></li>
35 + <li><a href="#upgrade-faq">FAQ</a></li>
36 + </ul>
37 + </aside>
38 +
27 27   <article class="resource-content">
28 28  
29 29   <p>
... ... @@ -40,6 +40,22 @@
40 40  
41 41   <div class="resource-note">
42 42   <p>
55 + <strong>In practice:</strong> an XWiki upgrade should review the current version, target version,
56 + required intermediate steps, installed extensions, custom code, authentication setup, infrastructure,
57 + backups, rollback expectations and the business-critical features that must be validated before
58 + production is touched.
59 + </p>
60 + </div>
61 +
62 + <p>
63 + An XWiki upgrade is the process of moving an existing instance to a newer XWiki version while preserving
64 + content, configuration, extensions, customizations, access rights and business-critical behavior. A safe
65 + upgrade is not only a software installation task. It is a controlled maintenance process with preparation,
66 + staging validation, production rollout and follow-up notes.
67 + </p>
68 +
69 + <div class="resource-note">
70 + <p>
43 43   <strong>The main point:</strong> regular upgrades are not only about new features. They reduce security
44 44   exposure, compatibility risk and long-term maintenance cost.
45 45   </p>
... ... @@ -59,6 +59,11 @@
59 59   public or private. But staying close to supported versions makes security maintenance more manageable.
60 60   </p>
61 61  
90 + <p>
91 + For a broader view of security-related checks, see
92 + <a href="$xwiki.getURL('resources.xwiki-security-review')">what an XWiki security review should actually include</a>.
93 + </p>
94 +
62 62   <h3>2. Large upgrade gaps are harder to control</h3>
63 63   <p>
64 64   A small, regular upgrade is usually easier to validate than a large jump after several years. Large gaps
... ... @@ -73,6 +73,11 @@
73 73   planning an upgrade.
74 74   </p>
75 75  
109 + <p>
110 + For more details on organizing custom work, see
111 + <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
112 + </p>
113 +
76 76   <h3>4. Infrastructure requirements evolve</h3>
77 77   <p>
78 78   XWiki upgrades can involve more than the application itself. Java, Tomcat, the database, Docker images,
... ... @@ -86,8 +86,22 @@
86 86   should be part of the validation plan.
87 87   </p>
88 88  
89 - <h2 id="upgrade-checklist">Practical checklist before planning an upgrade</h2>
127 + <div class="resource-inline-cta">
128 + <p>
129 + <strong>Not sure how risky your current XWiki version is?</strong>
130 + A short technical review can clarify the upgrade path, extension compatibility,
131 + custom code risks and validation needs before production is touched.
132 + </p>
133 + <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a quick review</a>
134 + </div>
90 90  
136 + <h2 id="upgrade-checklist">XWiki upgrade planning checklist</h2>
137 +
138 + <p>
139 + A practical XWiki upgrade plan should cover both the application and the environment around it.
140 + The following checklist can be used as a starting point before upgrading a production instance.
141 + </p>
142 +
91 91   <ul class="resource-checklist">
92 92   <li>Identify the current XWiki version and the target version.</li>
93 93   <li>Check whether intermediate upgrade steps are needed.</li>
... ... @@ -139,6 +139,51 @@
139 139   review, staging validation, production rollout, documentation and follow-up.
140 140   </p>
141 141  
194 + <h2 id="upgrade-faq">XWiki upgrade FAQ</h2>
195 +
196 + <h3>Why should XWiki be upgraded regularly?</h3>
197 + <p>
198 + XWiki should be upgraded regularly to reduce security exposure, keep extensions compatible, avoid large
199 + upgrade gaps and make long-term maintenance easier. Regular upgrades are easier to plan and validate than
200 + major jumps after several years.
201 + </p>
202 +
203 + <h3>Is a working XWiki instance safe to leave unchanged?</h3>
204 + <p>
205 + Not necessarily. An XWiki instance can continue to work from a user perspective while becoming outdated,
206 + harder to upgrade and exposed to avoidable risks. Visible functionality is not the same as long-term
207 + maintainability.
208 + </p>
209 +
210 + <h3>What should be checked before upgrading XWiki?</h3>
211 + <p>
212 + Before upgrading XWiki, review the current version, target version, intermediate upgrade steps, installed
213 + extensions, custom code, authentication setup, infrastructure, backups, rollback expectations and
214 + business-critical features.
215 + </p>
216 +
217 + <h3>Should an XWiki upgrade be tested outside production?</h3>
218 + <p>
219 + Yes. The safest approach is to rehearse the upgrade on a staging environment or temporary clone, fix
220 + compatibility issues there, then perform the production upgrade with a clear plan and rollback expectations.
221 + </p>
222 +
223 + <h3>What makes an XWiki upgrade difficult?</h3>
224 + <p>
225 + XWiki upgrades become more difficult when the version gap is large, extensions are outdated, custom code is
226 + undocumented, authentication is complex, infrastructure dependencies changed or critical workflows were not
227 + included in the validation plan.
228 + </p>
229 +
230 + <div class="resource-note">
231 + <p>
232 + Related resources:
233 + <a href="$xwiki.getURL('resources.xwiki-security-review')">what an XWiki security review should actually include</a>
234 + and
235 + <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
236 + </p>
237 + </div>
238 +
142 142   <div class="resource-cta">
143 143   <h3>Need help planning an XWiki upgrade?</h3>
144 144   <p>
... ... @@ -149,20 +149,58 @@
149 149   </div>
150 150  
151 151   </article>
152 -
153 - <aside class="resource-sidebar" aria-label="Page summary">
154 - <h4>In this guide</h4>
155 - <ul>
156 - <li><a href="#why-it-matters">Why upgrades matter</a></li>
157 - <li><a href="#upgrade-checklist">Upgrade checklist</a></li>
158 - <li><a href="#safe-process">Safe process</a></li>
159 - <li><a href="#common-mistakes">Common mistakes</a></li>
160 - <li><a href="#upgrade-rhythm">Upgrade rhythm</a></li>
161 - </ul>
162 - </aside>
163 -
164 164   </div>
165 165   </div>
166 166   </section>
252 +
253 + <script type="application/ld+json">
254 + {
255 + "@context": "https://schema.org",
256 + "@type": "FAQPage",
257 + "mainEntity": [
258 + {
259 + "@type": "Question",
260 + "name": "Why should XWiki be upgraded regularly?",
261 + "acceptedAnswer": {
262 + "@type": "Answer",
263 + "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."
264 + }
265 + },
266 + {
267 + "@type": "Question",
268 + "name": "Is a working XWiki instance safe to leave unchanged?",
269 + "acceptedAnswer": {
270 + "@type": "Answer",
271 + "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."
272 + }
273 + },
274 + {
275 + "@type": "Question",
276 + "name": "What should be checked before upgrading XWiki?",
277 + "acceptedAnswer": {
278 + "@type": "Answer",
279 + "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."
280 + }
281 + },
282 + {
283 + "@type": "Question",
284 + "name": "Should an XWiki upgrade be tested outside production?",
285 + "acceptedAnswer": {
286 + "@type": "Answer",
287 + "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."
288 + }
289 + },
290 + {
291 + "@type": "Question",
292 + "name": "What makes an XWiki upgrade difficult?",
293 + "acceptedAnswer": {
294 + "@type": "Answer",
295 + "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."
296 + }
297 + }
298 + ]
299 + }
300 + </script>
301 +
167 167  {{/html}}
168 168  {{/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