I believe the “unique snowflake” problem should be dealt with via “feature requests” for each source (phpBB, vBulletin, bbPress etc.) being imported.
Basically it comes down to a missing “feature” or a “bug” .
The best way to surface these “feature” or “bug” reports / requests is to have an interface which:
- sets expectations
- allows the user to make informed decisions
- informs the user if an “known” unsupported feature is currently in use:
- if it won’t be imported
- where do go to get more info
- preventing the user from continuing until they have “agreed”.
So for example one of the things the phpBB importer doesn’t do is set security permissions on categories.
This would be a critical warning, you wouldn’t want a site importing “private” data and displaying it publically on the Discourse install.
In this case one answer would be to make the install private until the group / category permissions could be manually setup by a user.
But then again, if this was a common element – then the phpBB importer could be improved to either:
- add the functionality for creating these group / category permissions
OR: detecting if there are actually any categories using “special permissions” and if not don’t bother displaying the warning. Improving the process flow for that importer.
Again specifically thinking of phpBB how much of “unique snowfake” is complex understand, but there are small things that can be done:
- check for actually listed plugins
- warn the user the functionality provided by these won’t be imported or is an unknown factor.
(But as a side note, consider a “complete source code comparison” for phpBB installs - so many “mod” installs - they will make you cry ).
Yes the above includes more of those bullet points with many man hours behind each.
Currently these decisions are made mostly by “someone in the know” because that person is having to:
- run an import from a command line shell
- make coding changes to get it to start
- most likely install additional software on Linux (MySQL for phpBB)
- and more…
Because the level of entry for this process is quite high, I believe the level of early abandonment will be too.
The vision I have outlined is just that a “vision” what could be.
It also specifically allows:
- for users with zero command line skills to complete an import.
- for users to be kept informed of progress.
- expectations to be clearly set.
- clear messaging on where to perhaps request a missing importer feature for a specific platform.
- clear separation of old and new
- no need to setup a new MySQL install
- open up ports
- upload a backup data via some SSH method users probably haven’t heard of.
- Discourse server requirements to be kept minimal during import (i.e. the same as the final server requirements)
- installing an additional service (MySQL) would push the server requirements up for the import locally.
Feel free to pick from this what you will to consider “minimum requirements” for improvements on the existing solution.
Sometimes it’s good to have a bigger picture in mind.
Just sharing, hope it helps.