A forum migration is a data reconciliation problem. The software is the easy part. What decides the outcome is whether the source schema maps onto the target cleanly, what happens to the parts that do not, and whether the community's search visibility survives the move.
Whether a vBulletin community can move depends far less on its size than on which vBulletin it is. Modern releases map across through the platform's own importer. Older ones frequently do not, and those become custom work with a fundamentally different scope. Getting this wrong in the wrong direction is expensive: assume it is impossible and you may commission work you did not need; assume it is routine and you may discover mid-project that the source predates the importer's coverage.
You have decided the current platform is not where the community should be in three years and you need the move planned rather than improvised.
The decision has effectively been made for you by a support date, and you need to understand what moving actually involves before committing.
You have taken on a forum with a long history and no documentation, and you need to establish what is there before deciding what to do with it.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
The threads, private messages, attachments and member accounts are the platform. A move that loses a category of them, or leaves them reachable but no longer linked, degrades the asset the migration was meant to protect.
A platform move changes every URL in the community. Without a deliberate redirect and canonical strategy, years of accumulated search authority points at addresses that no longer exist — and the loss is gradual enough to be attributed to something else.
The difference between a source version the platform's importer covers and one it does not is the difference between a bounded project and an open-ended one. Establishing that first is what stops the scope being discovered during execution.
A community will forgive a new interface long before it forgives a lost post, a broken private message thread or a fortnight of downtime. Migration quality is measured by the members, in the first week, against the old platform they remember.
Each of these is work we carry out, not an area we advise on.
Establishing what is actually running: exact source version and build, extensions, customisations made directly to the platform, database size and character set, attachment and avatar storage and its scale, and anything that has diverged from a stock installation.
Determining whether the source version falls within the target platform's own importer coverage, and stating that plainly. Where it does, the migration follows a known path. Where it does not, that is custom importer development and is scoped and priced as such rather than treated as a variation.
Where the source falls outside supported coverage, building the conversion for that specific schema — including the legacy structures a general-purpose importer cannot know about. This is where historic migration work lives, and it is genuinely different work from running a supported import.
Deciding explicitly how each source construct becomes a target construct: forums to nodes, threads to threads, user groups to permission sets, private messages, subscriptions, polls, attachments, and the parts that have no direct equivalent and need a defined outcome.
Accounts, group memberships, moderator and administrator assignments and custom permission sets mapped onto the target's model. Permissions that were maintained through years of source work are the least visible and most disruptive thing to get wrong.
Every migrated URL has a destination on the new platform, expressed as redirect rules that can be verified rather than assumed, because search visibility after the move depends on them being complete.
Repeated runs against a copy of the real database, with counts reconciled between source and destination per content type. A migration is verified by counting, and the counts are the deliverable that turns 'it looks right' into a statement that can be checked.
Search, private messaging, attachment delivery and permission behaviour exercised with real data, and search-engine signals checked after the cutover. The engagement is not finished when the data is across; it is finished when the community works.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
The source version determines whether this is a supported import or custom development. That is established first, in writing, because every downstream estimate depends on it — and because a plan built on the wrong assumption is worse than no plan.
Extensions, direct platform edits and undocumented changes all affect what can be converted. Anything the source has diverged into has to be understood before its content can be mapped, because the mapping depends on what produced it.
The decisions that cause trouble later are the ones nobody made: a private message system with no direct target, a subscription model with different semantics, a reputation system that does not translate. Each gets a defined outcome rather than being discovered in the import output.
The migration is run against a copy of the production database as many times as it takes to be boring. Rehearsal is where the parts that do not convert are found, and finding them there costs nothing beyond time.
Per content type, source against destination. Totals and spot checks, with every variance explained or reduced to zero. A migration without reconciliation has an unknown error rate, which is not a defensible position to take a community into.
The final delta, the DNS change and the redirect activation are performed as a single rehearsed sequence with owned steps and a defined rollback condition. Improvisation during the window is what turns a planned migration into an unplanned incident.
Community problems surface after real members arrive: a permission nobody exercises in testing, a search case that only occurs at scale, an attachment type used by one member. The engagement includes the period in which those appear.
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.
A different source schema with a different compatibility position.
Invision to XenForo migrationThe search consequence of a URL change is its own discipline.
Website migrationsInfrastructure and ongoing operations for a community.
Managed XenForo hostingExtensions, templates and upgrade work.
XenForo developmentEverything that maps, yes — and there is always something that does not. The candidates are usually feature-specific structures: a reputation system, a subscription model, a bespoke gamification extension, private message semantics that differ between platforms. Each of those gets a defined outcome during planning rather than being discovered afterwards: converted, converted approximately, or explicitly not carried. What we will not do is promise 100% transfer, because the honest version of that promise depends on what your source actually contains.
For a short window at cutover, yes. The rehearsal runs happen against a copy while the live forum keeps serving, and the bulk of the data moves before the window; the window handles the changes written since. Prerelease notice, a rehearsed sequence and a tested rollback are what keep that window short. We will not promise zero downtime — the cutover is a real event and claiming otherwise would be a marketing answer to an engineering question.
Usually, but it changes the shape of the project rather than being a barrier. Sources that fall outside the target platform's importer coverage need the conversion built for that schema specifically, which is a development engagement rather than a configuration one. That is more work and more time, and it is knowable from the source version — which is why establishing that version is the first deliverable rather than an assumption.
They are at risk during any platform move, because every URL changes. The mitigation is complete: a full inventory of existing URLs, a redirect rule for each one, and canonical signals that agree with the new structure. Done properly, a migration can hold search visibility and sometimes improve it, because the new platform is faster and structurally cleaner. Done without a redirect strategy, the loss is real and arrives slowly enough that it gets attributed to something else.
It follows the compatibility position and the reconciliation work, not the forum's page views. A supported source version with clean content is bounded and predictable. A source outside supported coverage, or one with years of undocumented customisation, is a development project whose size is established by the audit. We will give you a sequence and an estimate after the assessment, and not before it.
Not if they are planned for, and they are planned for as first-class content rather than as an afterthought — they are frequently the largest part of the database and the part most likely to be mishandled. Private message semantics differ between platforms, and attachments may live on the filesystem rather than in the database, which means they are missed by an import that only reads the database. Both are explicitly in scope, and both are reconciled by counting before cutover.
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.