A new installation is a build. An upgrade that has been deferred for several versions is a project, and the two are different enough that they belong on the same page only to make the distinction clear.
Each version step skipped makes the next one less tested against your configuration. Extensions fall behind the platform's own interface, template modifications drift from templates that have since changed, and the gap between what is running and what is supported widens. Eventually the platform reaches a release that is no longer receiving security fixes, and the upgrade acquires a deadline that somebody else set.
You need it installed on a sound footing, with the decisions that make later upgrades ordinary taken at the beginning.
The upgrade has been avoided for long enough that it is now a project rather than maintenance, and you need it staged.
A security notice or an end-of-support date has made the position urgent and you need to know what the path looks like.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
This is the consequence with a clock on it. Once a release leaves support, a vulnerability discovered afterwards is not patched at all — the only remedy is the upgrade that was deferred.
Each step is smaller than the whole, but each also has less documentation and less community experience behind it. Long-deferred upgrades are typically applied as a sequence of smaller jumps for that reason.
A template modification may appear to work after an upgrade and break on a page nobody visits for a week. Without rehearsal against a copy of the real installation, those failures are found by members.
Unlike a marketing site, a forum's audience is present daily and notices immediately. The cost of an upgrade that goes wrong is measured in participation, not only in downtime.
Each of these is work we carry out, not an area we advise on.
A clean install with the decisions that determine whether later upgrades are routine: extension choices that respect the platform's own boundaries, a staging environment that mirrors production, backups verified by restore rather than by schedule, and a documented configuration.
Establishing exactly what is running, how far behind it is, and the path to a supported release expressed as a sequence of steps rather than as one jump — with what each step affects identified in advance.
Reviewing every extension and template modification against the target release, and stating which will need updating, which will break, and which are no longer used at all. A modification nothing depends on is not worth preserving, and finding that out before the upgrade is considerably cheaper than afterwards.
Running each step against a copy of the production database with the real extensions and customisations in place. A clean-install test proves very little about a community with years of accumulated configuration.
Each version step applied and verified in turn, with a rollback available per step rather than one rollback for the whole sequence. This is what makes a long-deferred upgrade tractable.
Where a customisation fails, rebuilding it on a supported mechanism rather than patching the failure — so the next upgrade does not reproduce the same problem.
Permissions, discussion, search, attachments and the front end exercised after each step, because failures at this layer surface in places a smoke test does not reach.
A written upgrade procedure, a documented boundary between platform and customisation, and a stated position on keeping the installation current — so the next upgrade is scheduled work rather than an avoided one.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Not from what anyone remembers, and not from the last release note anybody read. The exact version determines the path, and on long-neglected installations it is frequently not what the owner believes.
Long-deferred platforms usually cannot be brought current in one jump. The path is decomposed into version steps, each with what it affects and whether it can be applied independently, so the work has visible progress and a rollback at every point.
A community's installation carries years of configuration that a fresh install does not. Every rehearsal uses a copy of the production database with the extensions present, because that is the only test that reflects what the upgrade will actually meet.
Extensions and modifications that nothing depends on are removed rather than carried forward. This reduces what each step has to survive and is frequently the cheapest part of the whole project.
Where a step can be applied without taking the forum offline, it is. Where it cannot, the window is short, announced and rehearsed, because on a community the audience's presence is the reason the platform exists.
Every engagement ends with a written record of what is platform and what is customisation, and an upgrade procedure. A platform whose customisation boundary is undocumented will repeat this exact situation on the next version.
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Engagements where this capability was the substance of the work rather than a line item.
Since 2019, Soludome has managed infrastructure and platform operations for one of Spain's largest online communities. The work covers server and performance optimisation, CDN architecture, load balancing and site security under sustained traffic.
An established community platform had accumulated three separate problems that compounded each other: page loads that had degraded with growth, search visibility that had not kept pace with the community's authority, and a security posture that had not been revisited as the platform's profile grew. The engagement addressed all three concurrently.
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
Source-schema conversion from another forum platform.
Forum migration to XenForoExtensions, templates and custom functionality built to survive upgrades.
XenForo developmentInfrastructure, capacity and ongoing operational ownership.
Managed XenForo hostingExtensions and add-ons built at the platform's own extension points.
Custom XenForo add-on developmentWith the version position, established from the installation rather than from memory. Everything else depends on it: which steps the path contains, which extensions each step affects, and whether any intermediate version is itself unsupported in a way that changes the sequence. The first deliverable is the path as a sequence, so you can see how many steps there are before committing to any of them.
Some of them, most likely, and the assessment will say which. That is the point of the review: a modification nothing depends on is not worth carrying forward, and finding out before the upgrade is much cheaper than after. Where a customisation matters, the durable fix is to re-establish it at a supported extension point so the next upgrade does not repeat the problem.
For short windows at specific steps, and the sequence is arranged to minimise how many. Where a step can be applied while the forum serves members, it is. The upgrade path is decomposed partly for this reason — a single jump from a badly outdated release would need a much longer window than the same work applied as stages.
Two things, and the second matters more. Applying upgrades at intervals rather than accumulating them is the obvious one. The structural one is keeping customisation at the platform's own extension points, because that is what makes an upgrade a routine maintenance step rather than an archaeological exercise. The engagement ends with that boundary documented so it can be maintained.
That is the normal situation and it is why the rehearsal happens against a copy rather than against production. The replica is a snapshot of the real database with the real extensions, tested while the community keeps serving. Where a step genuinely cannot be rehearsed — a change that depends on live traffic, for instance — that is identified in the assessment rather than discovered during the window.
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.