Invision Community and IP.Board migration to XenForo
Invision Community has been renamed, re-versioned and restructured over a long life, which means two installations describing themselves identically can behave completely differently under migration. The version position is established before anything else is planned.
Invision is one product with several eras, and they do not migrate alike
The platform has carried more than one name and more than one architecture across its lifetime. A community on a recent release has a different migration prospect from one running IP.Board from a decade ago, even though both are legitimately described as Invision. Adding to this, the platform's own flexibility means installations diverge: applications enabled, customised templates and bespoke extensions all change what has to be converted. Planning a migration without establishing which era and which configuration you have produces a plan for a different site.
- The community runs an Invision release that is no longer receiving updates
- The installation uses applications or customisations whose status is unclear
- Nobody is certain which major version the community is on
- Renewal or support costs have changed and the platform decision is being revisited
- Migration has been investigated before and the answer depended on the version
- Content lives in areas whose equivalent on the target platform is not obvious
- Search visibility is commercially important and the move is a risk to it
- The community has significant private messaging, galleries or download content
The people who usually bring us this problem
A community owner facing an end-of-life decision
The current platform is no longer a sensible long-term home and you need to understand what moving actually requires before you commit to it.
An operator who has already tried to scope this
You have asked elsewhere and received an answer that depended on assumptions about your version, and you want that established properly first.
Someone with an old IP.Board installation
The community is running an older generation of the platform and you need to know whether migration is possible and what it would take.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
Planning against the wrong version produces a plan for the wrong project
A migration scoped for a supported source and executed against an unsupported one has to be rebuilt mid-project. Establishing the version first is the cheapest step in the whole engagement and the one that protects every other decision.
Feature-rich installations lose more in translation
Platforms that offer galleries, downloads, blogs, clubs and commerce alongside discussion accumulate content in structures the target platform does not share. Those areas need explicit decisions rather than an import that silently drops them.
Search visibility is a commercial asset that moves with the URLs
Every discussion URL changes. Without a complete redirect strategy the community's earned authority points at addresses that return nothing, and the decline is gradual enough to be misattributed.
An uncertain source is an unpriceable project
Without the audit, any estimate carries an unknown. That is uncomfortable for the buyer and misleading when presented as a figure, so we do not present one.
Capabilities
Each of these is work we carry out, not an area we advise on.
Source identification and version position
Establishing exactly which major version and build the community runs, and answering plainly whether it falls inside the target platform's importer coverage or requires custom conversion. This is the first deliverable and everything else is contingent on it.
Application and configuration inventory
Which platform applications are enabled, which customisations exist, and what content each of them holds. On this platform the enabled applications materially change the migration, since they determine what content has to be accounted for.
Content mapping across divergent structures
Deciding what happens to content with no direct target equivalent — galleries, downloads, blogs, clubs, commerce records, custom profile fields. Each is mapped to a target structure, converted approximately, or explicitly excluded with the consequence stated.
Member and permission conversion
Accounts, groups, secondary group memberships, moderator assignments and custom permission configurations reconciled onto the target's model, with the differences identified rather than discovered by members.
Custom conversion where coverage does not reach
Where the source falls outside importer coverage, building the conversion for that schema specifically. This is development work and is scoped as such rather than presented as a configuration change.
URL inventory and redirect strategy
A complete inventory of indexable URLs and a redirect rule for each, so the community's search visibility transfers rather than resetting.
Rehearsed migration with reconciliation
Repeated runs against a copy of the real database, with counts compared per content type between source and destination. Variances are explained or eliminated before the live cutover.
Post-migration verification and support
Discussion, messaging, media, downloads and permissions exercised with real data after the move, with search-engine signals checked and support through the period in which members find the edges.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Establish which Invision this is
The platform has carried different names across different eras and its architecture has changed with them. The version position decides whether this is a supported import or custom conversion, so it is established from the installation rather than from what anyone believes the community runs.
Inventory the applications, not just the discussions
This platform's additional applications hold real content. A migration planned around threads alone will silently drop galleries, downloads or other application content, so the inventory covers every enabled application and what is inside it.
Make an explicit decision for every structure without a target equivalent
The failure mode is not a failed conversion; it is content that quietly does not arrive. Each divergent structure gets a written outcome — converted, approximated with its limits stated, or excluded with the consequence made clear — agreed before any data moves.
Rehearse against the real database, repeatedly
Configuration-dependent divergence means a clean-install test proves very little. The rehearsal uses a copy of the production database with the real extensions and applications enabled, and it is run until the output is stable.
Reconcile by counting every content type
Source against destination, per type, with variances explained. A migration into a community with years of history has to be able to state its own error rate, and counting is how that is done.
Cut over once, with the redirect map already active
The final delta, the DNS change and the redirect activation are one rehearsed sequence. Redirects go live with the new platform rather than after it, because the gap between them is where search visibility is lost.
Support the community through the settling period
Members find the parts testing does not. The engagement includes the first weeks of live use, which is when permission edge cases and unusual attachment types actually appear.
What an engagement produces
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.
Assessment
- Exact source version and build, established from the installation
- Written importer compatibility position for that version
- Enabled applications and the content each holds
- Customisation and template inventory
- Explicit outcome for every structure without a direct target equivalent
- Scope, sequence and risk register
Migration
- Migration executed through iterations against a copy of the real database
- Custom conversion where the source falls outside importer coverage
- Members, groups, permissions and moderator assignments reconciled
- Application content mapped to target structures or explicitly excluded
- Complete URL inventory with redirect rules
- Reconciliation counts per content type
Cutover and after
- Rehearsed cutover sequence with a tested rollback and defined trigger
- Redirects activated with the new platform, not after it
- Discussion, messaging, media and permissions verified with real data
- Search-engine signals monitored after the move
- Support through the first weeks of live community use
Architecture and technology
Version compatibility, stated plainly
- The target platform's importer coverage lists recent Invision Community releases
- Recent releases within that coverage follow a bounded migration path
- Later major versions and older IP.Board generations require a separate assessment
- A source outside coverage is custom conversion work, not a supported import
- We confirm which applies before quoting, and we do not assume from the platform's name
Content with no direct target equivalent
- Galleries and media libraries
- Download and file repositories
- Blogs and article areas
- Clubs, groups and social areas
- Commerce and subscription records
- Custom profile fields and reputation structures
- Each receives a written outcome rather than an import that quietly omits it
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
Your source is vBulletin rather than Invision
A different source schema with a different compatibility position.
vBulletin to XenForo migrationThe community's search visibility is the main risk
Redirects, canonicals and post-migration indexation recovery.
Website migrationsYou need the destination developed as well as the move
Extensions and templates after the migration.
XenForo developmentYou are also changing server as part of the move
The infrastructure cutover is a separate project from the data conversion.
Server migrationFrequently asked
Can our Invision community be migrated?
It depends on the version, and that is a real dependency rather than a sales caveat. Recent releases within the target platform's importer coverage follow a known path. Later major versions and older IP.Board generations fall outside it and need the conversion built for that schema. Both are possible; they are different projects with different scopes, and we establish which one yours is before quoting rather than after.
We have galleries, downloads and blogs. What happens to them?
They are the reason this migration needs planning rather than running. The target platform does not have direct equivalents for every Invision structure, so each one gets an explicit decision: mapped to a target feature, converted into a close approximation with the differences stated, or deliberately left behind with the consequence made clear to you first. What we will not do is run an import and let you discover afterwards which areas did not arrive.
How long will the forum be offline?
A short window at cutover, with everything rehearsed in advance against a copy of the live database. Invision installations with several applications and heavy customisation take longer to rehearse, which is why the assessment precedes the timeline. 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 rather than a claim it will not happen.
What happens to our search rankings?
Every discussion URL changes, so the redirect map is not optional. A complete URL inventory with a rule for each one, activated at the same moment as the new platform, is what carries the community's earned visibility across. Migrations where redirects are added afterwards lose traffic in the gap, and the loss tends to be attributed to the platform change rather than to the sequencing.
Do you have examples of Invision migrations you have done?
Not in a form we can publish, and we would rather say that than show you work that is not comparable. Our published community work is forum migration and large-scale community platform operation, and presenting it as Invision delivery would mislead you about what you are buying. What we can do is describe the method precisely enough for you to judge it, and establish your version position honestly — which is the part that actually determines whether this project is straightforward.
Related capabilities and work
Bring us the problem you have not been able to fix
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.