Skip to Content
Last modified by Agnease on 2026/05/26 10:58
From version 5.1
edited by Agnease
on 2026/05/22 06:11
Change comment: There is no comment for this version
To version 9.4
edited by Agnease
on 2026/05/26 10:47
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Why Upgrade XWiki Regularly | Security, Stability and LTS Updates
1 +Why You Should Upgrade XWiki Regularly for Security and Stability
Content
... ... @@ -32,6 +32,7 @@
32 32   <li><a href="#safe-process">Safe process</a></li>
33 33   <li><a href="#common-mistakes">Common mistakes</a></li>
34 34   <li><a href="#upgrade-rhythm">Upgrade rhythm</a></li>
35 + <li><a href="#upgrade-faq">FAQ</a></li>
35 35   </ul>
36 36   </aside>
37 37  
... ... @@ -51,6 +51,22 @@
51 51  
52 52   <div class="resource-note">
53 53   <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>
54 54   <strong>The main point:</strong> regular upgrades are not only about new features. They reduce security
55 55   exposure, compatibility risk and long-term maintenance cost.
56 56   </p>
... ... @@ -70,6 +70,11 @@
70 70   public or private. But staying close to supported versions makes security maintenance more manageable.
71 71   </p>
72 72  
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 +
73 73   <h3>2. Large upgrade gaps are harder to control</h3>
74 74   <p>
75 75   A small, regular upgrade is usually easier to validate than a large jump after several years. Large gaps
... ... @@ -84,6 +84,11 @@
84 84   planning an upgrade.
85 85   </p>
86 86  
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 +
87 87   <h3>4. Infrastructure requirements evolve</h3>
88 88   <p>
89 89   XWiki upgrades can involve more than the application itself. Java, Tomcat, the database, Docker images,
... ... @@ -97,8 +97,22 @@
97 97   should be part of the validation plan.
98 98   </p>
99 99  
100 - <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>
101 101  
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 +
102 102   <ul class="resource-checklist">
103 103   <li>Identify the current XWiki version and the target version.</li>
104 104   <li>Check whether intermediate upgrade steps are needed.</li>
... ... @@ -150,6 +150,51 @@
150 150   review, staging validation, production rollout, documentation and follow-up.
151 151   </p>
152 152  
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 +
153 153   <div class="resource-cta">
154 154   <h3>Need help planning an XWiki upgrade?</h3>
155 155   <p>
... ... @@ -163,5 +163,55 @@
163 163   </div>
164 164   </div>
165 165   </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 +
166 166  {{/html}}
167 167  {{/velocity}}
Agnease.Code.SEODetailsClass[0]
metaTitle
... ... @@ -1,1 +1,1 @@
1 -Why Upgrade XWiki Regularly | Security, Stability and LTS Updates
1 +Why You Should Upgrade XWiki Regularly for Security and Stability | Agnease