Whether a forum can be migrated is a question about its source schema, not its size. Some sources are covered by the target platform's own importer and some are not, and that single fact decides whether this is a bounded project or a development one.
A community's history lives in a schema that was designed for a different piece of software, and every platform has made different decisions about how threads, permissions, messages and attachments are stored. Some of those decisions map cleanly onto the target; others have no equivalent at all. The migration is therefore not one process applied to different inputs — it is a different project per source, and establishing which one you have is the first piece of work.
The current platform is not where the community should be, and you need the move scoped honestly rather than quoted optimistically.
A support date has made the decision for you, and you need to know what moving actually requires 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 anything.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
A source within the target platform's importer coverage follows a known, bounded path. One outside it needs the conversion built for that schema. Assuming the wrong one produces an estimate that is wrong in the direction that hurts.
Threads, private messages, attachments and member accounts are what the community is. Losing a category of them, or leaving them reachable but unlinked, degrades the thing the migration existed to protect.
Every discussion address changes. Without a complete redirect strategy the community's accumulated authority points at addresses that return nothing, and the decline is gradual enough to be attributed to something else.
A new interface is forgiven quickly. A lost post, a broken private message thread or a fortnight of disruption is not. Migration quality is assessed by the community, in the first week, against the platform they remember.
Each of these is work we carry out, not an area we advise on.
Establishing which platform and which version, from the installation rather than from what anyone believes. Extensions, direct modifications and undocumented customisations are catalogued, because they determine what can be converted and what has to be decided.
Determining plainly whether the source falls inside the target platform's own importer coverage. That answer is given in writing before anything is scoped, because it is the difference between a supported import and custom conversion work.
Where the source falls outside coverage, building the conversion for that schema — including the legacy structures a general-purpose importer cannot know about. This is genuinely different work from running a supported import, and it is priced and sequenced as such.
A written decision for each source construct: forums to nodes, threads to threads, groups to permission sets, private messages, subscriptions, polls, attachments — and an explicit outcome for the structures with no direct equivalent.
Accounts, primary and secondary group memberships, moderator assignments and custom permission sets mapped onto the target's model. Years of permission configuration are the least visible thing to get wrong and the most disruptive when it is.
A complete inventory of indexable URLs and a rule for each, activated with the new platform rather than after it. The gap between the two is where search visibility is lost.
Repeated runs against a copy of the real database, with counts compared per content type between source and destination. A migration without reconciliation has an unknown error rate, which is not a defensible position to take a community into.
A rehearsed single cutover with a tested rollback and a defined trigger, followed by discussion, messaging, attachments and permissions exercised with real data — plus search signals monitored after the move.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Before scope, before timeline, before anything is promised. Every downstream estimate depends on whether this is a supported import or custom development, and a plan built on the wrong assumption is worse than no plan.
Extensions and undocumented modifications change what can be converted and how. Anything the source has drifted into has to be understood before its content can be mapped, because the mapping depends on what produced it.
The failures that surface late are the decisions nobody made — a reputation system with no equivalent, message semantics that differ, an attachment model that lives on the filesystem rather than in the database. Each gets a written outcome: converted, approximated with the limits stated, or excluded with the consequence made clear.
The migration runs against a copy of the production database repeatedly. Rehearsal is where the parts that do not convert are found, and finding them there costs nothing but time.
Source against destination, per content type. Totals, spot checks, and each discrepancy either resolved or explicitly accounted for. Counting is what turns 'it looks right' into a statement that can be checked.
The final delta, the DNS change and the redirect activation are one rehearsed sequence. Afterwards, the engagement continues through the weeks in which real members find the edges that testing did not.
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 source with its own importer coverage position and its own version constraints.
vBulletin to XenForo migrationOne page covers Invision, IPS and IP.Board; the version position differs.
Invision to XenForo migrationA conversion built for a schema nothing covers off the shelf.
Custom forum importersRedirects, canonicals and indexation recovery as a project in itself.
Website migrationsAlmost always, and the honest qualification is that the answer depends on the source. Sources inside the target platform's importer coverage follow a known path. Sources outside it need the conversion built specifically, which is development work rather than configuration. Both are achievable; they are different projects with different scopes, and establishing which one yours is comes before we quote anything.
No, and we would rather say that plainly than imply otherwise. The target platform's own importer covers a defined set of sources and versions; anything outside that set is custom work. If your source is one we have built for before we will say so, and if it is one we have not we will scope it as the development project it is rather than discovering that part-way through.
They are at risk in any platform move, because every URL changes. The mitigation is completeness: a full inventory of existing addresses, a redirect rule for each, and canonical signals that agree with the new structure. Done properly a migration can hold 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 to be misattributed.
A short window at cutover, with everything rehearsed in advance against a copy of the live database. The rehearsal runs happen while the forum keeps serving, and the bulk of the data moves before the window; the window handles what changed since. We will not promise zero downtime — the cutover is a real event, and the honest measure of its quality is preparation and a tested rollback.
Yes, if they are planned for, and they are treated 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. Attachments may live on the filesystem rather than in the database, which means an import that reads only the database will silently omit them. 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.