Big vBulletin forum migration project

Hello,

I am in the process of finding a future to a huge (12M+ posts, 100K users) vBulletin 4 forum.

I am currently studying discourse as an option, but multiple questions come to mind, and I don’t seem to be finding satisfying answers at this stage, so maybe I could have a better understanding by asking the questions directly.

This forum belongs to a company, and despite the fact that it doesn’t bring revenue, it’s still an important place for its community.

1/ I don’t understand the philosophy behind the “single container does all”. To me docker is all about the separation of micro services, and interconnecting them through docker network. I’m used to running multi-container projects (up to 10/12 containers with redis, postgresql and so on) using only docker tools.
I read the topic here : Can Discourse ship frequent Docker images that do not need to be bootstrapped? but I’m not sure about the justification. When I see all the exec & files in the compose files that are available, I find there is a misunderstanding between what a compose file is supposed to be doing compared to what a Dockerfile is supposed to be doing.
Code updates should trigger new builds of docker images that would be pulled and then run with compose and env variables.
I see that someone started to do that in a github project, but I assume it’s not supported officially.
Can someone give me a clear explanation on the “why” of the current philosophy and if there is any plan to run it as so many projects exist on the Internet in 2023.

2/ The company that owns the project uses Google Workspace for the emails. I used Google’s smtp relay setup for other projects, and I don’t plan on using something else to be able to work. I’ve read different things about this on this forum. Is there a clear way of making sure it’ll work or is there a chance that it won’t (that would be a showstopper for us)

3/ I saw that there are scripts to run migration from vBulletin (here : Migrate a vBulletin 4 forum to Discourse), but this gives contradictory instructions, such as using the guide, but customizes the container with Gem files. How much impact does this have on maintainability or support? Is the image still supported in case something goes wrong?

4/ Integration with other tools (Discord mainly). AT this stage, the vBulletin forum has its own user database. Is there a way to transition “smoothly” from local DB users to discord users for example, where we could match users to their discord login at some stage?

5/ Is there a simple guide to themes that would allow for a smooth transition, as I have many users who will be lost, and I’d like to get the minimum possible noise from the migration itself…

I will come back with probably another cluster of questions, but these are the main ones I have so far.

Thank you for everyone who will answer this all inputs are highly appreciated.

That’s for people who don’t know what system administration is who need support in making it work. For a large forum you’ll want at least a 2 container install, or maybe RDS and Elasticache instead of rolling your own.

If you want to launch with a Dockerfile you’ll need to use launcher to build your container and figure out a way to manage database migrations and precompiling assets.

If you know how to use Google for transational email, that’s fine. Most people don’t and we don’t want to teach them.

A large scale migration for an old forum typically needs lots of customization. Whether to run your migration in a development instance or in a production instance inside of docker is a matter of taste. I used to do it in a development instance but run all of my migrations in docker these days. Figuring out how to get all of the various pieces installed can be frustrating.

Do you mean “discord” or “Discourse?” Or maybe you want Configure Discord Login for Discourse?

Whatever you do, people hate change. I don’t think that trying to make Discourse be like vBulletin helps. If you want your forum to behave like vBulletin, then just keep using it. There are lots of themes that do lots of things. There isn’t really a guide except Search results for '#theme-component' - Discourse Meta. You can wade and search there.

One thing that I think someone missed is that though the first time you run the script it will take days, subsequent runs are faster because they skip the already imported data, so the final run won’t take too long.

Welcome

I’ll only answer this as I’m not competent in the other fields. I speak about the smooth transition later in my post.

In terms of customization, you can edit the CSS from an in-built editor, as well as add Javascript and use Discourse-specific JS API. Visually speaking, if you don’t like something, just hide or change it.

The official theme guide is here, Beginner's guide to developing Discourse Themes.

It may not be completely up-to-date as we’re currently upgrading some JS stuff on the long run.

About 100% of the themes, theme components and plugins published here are open source, so you can always have a look at their code to build your own solutions.

A theme is basically a skin with or without added features.
A theme component usually adds features.
A plugin adds more in-depth server-side features.

For my own communities, I try using only official customizations or others from trusted and well-established authors or companies like pavilion. And also personal ones, of course, as I can maintain them myself.

Themes and theme-components can be added and removed at runtime, while installing and uninstalling a plugin needs a command-line app rebuild (10-15 min downtime).

As for a smooth transition for a community that would alleviate user confusion or angriness, that is sometimes tricky. Obviously, a 100% happiness score is close to impossible.
Plus, some communities are definitively more conservative or louder than others and will react accordingly.

From a user perspective, I’d say the most recurrent criticisms that have been made are:

• No more pagination
  It’s replaced with an interactive timeline. Both have their pros and cons. I’ve occasionally heard people not able to adjust to this change.
  My own experience from 3 migrations of small and mid-sized forums is that no one in my communities had a negative experience with the timeline thing.

• The interface is complicated
  The interface has more elements than in the past, as features were added over time. The notification menu has grown larger, the sidebar was introduced, and a chat feature was added (which may not be needed if you have a Discord server).
  We’re very aware of the complexity of the interface, and we’d definitely like to have more streamlined parts.
  There’s definitively a learning curve with Discourse. While being a forum having the same features as any other forum software (post topics, post replies/PMs, that’s it…), it diverges from here in terms of interface and added features. I’d say most people have no particular issue with that, but this forum’s community might be biased as most people here know Discourse.
  When you’re used to the interface, you don’t see noise anymore and focus on the features you actually use, but I understand that’s not exactly your concern here as you focus on the migration/transition.

There are two in-built tools that helps people understand the interface and features.

1. @discobot. It’s an interactive bot user that we can interact with, and it teaches us how to use some discussion features.

2. New user tips. When you register, tooltips will appear in the interface to explain different parts. You can disable it at any time from any tooltip and opt-in again from your user preferences.

From an admin perspective, it would be:

• There are too many settings
  Yes, there are many options in Discourse. Carefully configuring the forum will take hours and probably need adjustments until satisfied. The good thing is that when it’s done, you rarely go back to tweaking the settings.
  We know many settings can be intimidating and sometimes make finding something difficult. There’s room for improvement.

Finally, you can use the user sandbox at try.discourse.org.
There’s no admin sandbox. When I want to experiment with things at an admin level, I usually set up a low-specs Hetzner server (billed per hour) on which I install Discourse for a few hours or days.