Skip to Content
Last modified by Agnease on 2026/05/26 10:58
From version 8.3
edited by Agnease
on 2026/05/26 09:14
Change comment: There is no comment for this version
To version 9.1
edited by Agnease
on 2026/05/26 10:39
Change comment: There is no comment for this version

Summary

Details

Page properties
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,13 @@
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 + <h2 id="upgrade-checklist">XWiki upgrade planning checklist</h2>
101 101  
129 + <p>
130 + A practical XWiki upgrade plan should cover both the application and the environment around it.
131 + The following checklist can be used as a starting point before upgrading a production instance.
132 + </p>
133 +
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,42 @@
150 150   review, staging validation, production rollout, documentation and follow-up.
151 151   </p>
152 152  
185 + <h2 id="upgrade-faq">XWiki upgrade FAQ</h2>
186 +
187 + <h3>Why should XWiki be upgraded regularly?</h3>
188 + <p>
189 + XWiki should be upgraded regularly to reduce security exposure, keep extensions compatible, avoid large
190 + upgrade gaps and make long-term maintenance easier. Regular upgrades are easier to plan and validate than
191 + major jumps after several years.
192 + </p>
193 +
194 + <h3>Is a working XWiki instance safe to leave unchanged?</h3>
195 + <p>
196 + Not necessarily. An XWiki instance can continue to work from a user perspective while becoming outdated,
197 + harder to upgrade and exposed to avoidable risks. Visible functionality is not the same as long-term
198 + maintainability.
199 + </p>
200 +
201 + <h3>What should be checked before upgrading XWiki?</h3>
202 + <p>
203 + Before upgrading XWiki, review the current version, target version, intermediate upgrade steps, installed
204 + extensions, custom code, authentication setup, infrastructure, backups, rollback expectations and
205 + business-critical features.
206 + </p>
207 +
208 + <h3>Should an XWiki upgrade be tested outside production?</h3>
209 + <p>
210 + Yes. The safest approach is to rehearse the upgrade on a staging environment or temporary clone, fix
211 + compatibility issues there, then perform the production upgrade with a clear plan and rollback expectations.
212 + </p>
213 +
214 + <h3>What makes an XWiki upgrade difficult?</h3>
215 + <p>
216 + XWiki upgrades become more difficult when the version gap is large, extensions are outdated, custom code is
217 + undocumented, authentication is complex, infrastructure dependencies changed or critical workflows were not
218 + included in the validation plan.
219 + </p>
220 +
153 153   <div class="resource-note">
154 154   <p>
155 155   Related resources:
... ... @@ -172,5 +172,55 @@
172 172   </div>
173 173   </div>
174 174   </section>
243 +
244 + <script type="application/ld+json">
245 + {
246 + "@context": "https://schema.org",
247 + "@type": "FAQPage",
248 + "mainEntity": [
249 + {
250 + "@type": "Question",
251 + "name": "Why should XWiki be upgraded regularly?",
252 + "acceptedAnswer": {
253 + "@type": "Answer",
254 + "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."
255 + }
256 + },
257 + {
258 + "@type": "Question",
259 + "name": "Is a working XWiki instance safe to leave unchanged?",
260 + "acceptedAnswer": {
261 + "@type": "Answer",
262 + "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."
263 + }
264 + },
265 + {
266 + "@type": "Question",
267 + "name": "What should be checked before upgrading XWiki?",
268 + "acceptedAnswer": {
269 + "@type": "Answer",
270 + "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."
271 + }
272 + },
273 + {
274 + "@type": "Question",
275 + "name": "Should an XWiki upgrade be tested outside production?",
276 + "acceptedAnswer": {
277 + "@type": "Answer",
278 + "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."
279 + }
280 + },
281 + {
282 + "@type": "Question",
283 + "name": "What makes an XWiki upgrade difficult?",
284 + "acceptedAnswer": {
285 + "@type": "Answer",
286 + "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."
287 + }
288 + }
289 + ]
290 + }
291 + </script>
292 +
175 175  {{/html}}
176 176  {{/velocity}}