Migrating a forum without losing its URLs

Every forum platform numbers its topics differently, and every one of them puts those numbers in the address. Move from one to another and the addresses change, which means every link anyone ever made to a thread now points at nothing. The content survives the move; the reason people could find it does not.

This is avoidable and it is not difficult. It is simply work that has to happen before the cutover rather than after, because after the cutover the mapping information is gone.

What you are actually protecting

Three separate things point at the old addresses, and they fail differently.

External links. Somebody answered a question on your board in 2016 and eleven other sites linked to it. Those links are the reason the thread ranks. They cannot be updated because they are not yours.

Search results. A search engine holds an index of your old addresses. If they return a not-found page, the entries disappear over the following weeks and the traffic goes with them. If they redirect, the index transfers.

Your own members. People have bookmarks, and threads link to each other. Internal links are the one category you can rewrite, and they are also the category most often forgotten, because they are inside post bodies rather than in a template.

Build the inventory before you touch anything

You need a list of every address the old board serves. Not the ones in the navigation — all of them. There are three sources and you want all three, because each one knows about pages the others do not.

Crawl the running board with any site crawler and export the list. Export the addresses your analytics recorded over the last year or two, which catches pages the crawler cannot reach. And export whatever list of externally-linked pages you can get, because those are the ones that matter most and they include addresses that no longer resolve even on the current board.

Union the three. Deduplicate. The result is usually larger than anybody expected, and the surprise is normally in the archives: paginated category listings, per-user pages, tag pages, date archives, and attachment addresses.

Understand the two schemes you are moving between

Forum addresses come in a few recognisable families. Query-string schemes such as viewtopic.php?t=1234 put the identifier in a parameter. Path schemes such as /t/some-topic-title/1234 put it in the path, often with the title alongside it. Some platforms use both, one redirecting to the other.

The distinction matters because it decides what your redirect rules can match on. A rule that keys on the path alone will not see a query string at all, so a query-string scheme needs rules that read the parameter. This is the single most common reason a migration's redirects appear to work in testing and fail in production: the tester typed a clean address, and the real inbound links carry parameters.

Map old to new, by identifier

The mapping has to be built from the database, not guessed from the titles. When the importer runs it creates a correspondence between old topic identifiers and new ones — most importers record this, and if yours does not, capture it yourself before the old database is retired. Titles are not a safe key: they are edited, duplicated, and sometimes differ only by punctuation.

With that correspondence you can generate the redirect list mechanically. Generate it; do not write it by hand. A board with four thousand topics produces four thousand rules, and the hand-written subset always turns out to be the popular ones rather than the linked ones.

Some addresses have no counterpart. A category that no longer exists, a user profile for an account that was deleted, a tag page the new platform does not have. Those still need a destination — the nearest surviving page, usually the parent category or the board index. What they must not do is return not-found.

Write the redirects, and generate both forms

Use permanent redirects. A temporary one tells search engines to keep the old address in the index and keep asking, which is precisely wrong when the old address is never coming back.

Generate every rule in both slash forms. A rule written for /t/topic/1234/ will not fire for /t/topic/1234, and inbound links exist in both shapes because people copy addresses from different places. This costs nothing at generation time and is tedious to retrofit once the pattern is spread across thousands of rules.

Watch what the rule keys on if the old scheme used query strings. A parameter that arrives with extra tracking arguments appended — and it will — has to still match. Rules that key on the whole request line break the moment somebody shares a link from a client that appends its own parameters.

Prove it, one address at a time

A redirect that fires is not the same as a redirect that works. The only acceptable test is to take every address in the inventory, follow it through however many hops it makes, and confirm it lands on a page that returns success and is the right page.

Two failures hide from a casual check. A chain that ends in a redirect loop looks fine in the rules file and never terminates in a browser. And a rule that lands correctly but on the board index rather than the thread will pass a status check while having thrown away everything the redirect was for. Check the destination, not only the status.

Run the check against the real server configuration, not a development one. Rewrite behaviour differs between servers and between configurations of the same server, and a rule that works in one is quite capable of doing nothing in the other.

Sometimes the answer is not to redirect at all

A redirect is the standard tool, and there is a case where it is the wrong one: when the old addresses are cited by name somewhere that matters. Academic references, documentation, long-lived answers on other sites — these read as citations of a specific address, and a citation that resolves through a hop is weaker than one that resolves directly.

Where that applies, the alternative is to keep serving the old scheme as its own set of real addresses, rewriting internally to the new content rather than redirecting the visitor. The address stays exactly what it was; the content behind it is the new platform's. It is more configuration to carry, so it is worth doing for a small set of heavily-cited addresses rather than for the whole board.

If you do this, set the canonical link on the page to one of the two forms and be consistent about which. Two addresses serving identical content with no canonical between them is a duplicate, and the search engine picks the winner rather than you.

What to tell search engines, and what not to

Submit a sitemap of the new addresses. That is genuinely all the proactive work worth doing. Search engines find redirects by crawling the old addresses they already know, which they do without being asked.

Resist the temptation to remove the old addresses from the index deliberately. A removal request cancels the transfer you spent the day arranging — the redirect can only pass the value if the old entry is still being followed. The correct behaviour is to leave them alone and let the redirects do their work over the following weeks.

Expect a dip. Rankings wobble for a few weeks after any address change, even a clean one, and the mistake at that point is to start changing things. Give it a month before concluding anything, and when you do investigate, start with the inventory check rather than the theory.

Attachments, images and the things inside posts

Attachment addresses move too, and they are usually forgotten because they are not pages. People hot-link images from forums constantly; those links are traffic and they are also the reason another site's page still renders correctly. Redirect them like anything else.

Inside post bodies there will be absolute links to the board's own threads, written by members over years. The importer will not rewrite them. Left alone they still work, because the redirects catch them — which is a good argument for keeping the redirects permanently rather than for a year.

Accounts, and the part you cannot fix

Password hashes rarely transfer between platforms, which means most migrations end with every member resetting a password. A proportion of them will not, and that proportion is the real cost of the move.

What reduces it is warning people before rather than after, keeping usernames identical so the reset is recognisable, and making sure the reset email is not the first thing the new installation has ever sent — a fresh domain reputation plus a mass password-reset send is how a migration ends up in spam folders on its first day.

The order on cutover day

Import into the new platform and keep it private. Generate the redirect map from the correspondence the import produced. Load the rules. Point the domain at the new installation with the old one still running somewhere reachable, so anything you missed can be looked up rather than reconstructed.

Then run the inventory check against production and fix what fails, that day, while the old database is still available. Everything gets harder once it is not.