A lot of Khoros teams are looking at Discourse. I understand why. It is a mature discussion platform, it has a public price list, and its migration team has handled large Khoros communities. Those are good reasons to put it on a shortlist. They are not reasons to sign before you have looked at your content and your members.
There is also a clock. Khoros says it is moving Classic customers to Aurora AI at no cost through the end of 2026. If you are on Classic, ask your account team what that offer means for your contract and data. You can take the upgrade, leave, or use the deadline to compare both paths properly.
I have run communities for about twenty years, starting with CrazyEngineers in 2005, on vBulletin, then XenForo, then Discourse. I have not pulled data out of Khoros myself. The extraction advice below comes from Khoros and Discourse documentation and from teams who have done it. I have linked the sources so you can check the details against your own account.
I don't offer Discourse migration services. If you do choose Discourse, this guide should help you ask better questions of the people who will run the move.
Before you migrate
Most of the work in a Khoros exit happens before any data moves. Start by deciding what sort of community you are trying to keep.
Decide whether Discourse fits before paying for the move
Take twenty pages that matter: your busiest discussions, your best accepted answers, a few knowledge articles, an idea with a long status history, an event, and a private conversation. Ask each vendor to show where those pages would live after migration. Do it on a test site with your content, not a slide deck full of somebody else's community.
If the community is mainly a place for conversations and peer answers, Discourse deserves a serious look. If your support team publishes a large knowledge base, runs idea status workflows, or treats articles as a separate editorial product, check the compromises before you commit. A plugin can cover a feature without preserving the way your members use it.
Include Aurora in that exercise if you are already on Khoros. Staying may be cheaper and less disruptive if the problems that prompted the review are fixable. Ask what happens to your URLs, custom components, integrations and contract terms in a Classic-to-Aurora move. If you are comparing Jatra too, hold it to the same sample content and the same questions. I would rather lose a fair comparison than win a migration that makes your community worse.
Find out what Khoros will actually give you
Everything downstream depends on the export, so settle this first.
Do not assume there is a button that gives you a complete, import-ready copy of your community. Khoros has member reports and APIs; Classic uses REST, while Aurora's new development is centred on GraphQL. An API extraction may need custom work. Confirm what your contract and account team will actually give you before you choose an importer.
Discourse's open-source Lithium importer reads Lithium database tables directly. That does not mean every Khoros customer can get those tables. Ask your Khoros account team, in writing: can we receive a full database copy, what exactly is in it, how will media be delivered, how long will access remain open, and what will each export cost? Ask Discourse which format it will accept for your site. Put the two answers side by side.
Expect the answer to vary. In a 2024 thread on the Gainsight community, a Khoros customer described one destination vendor saying it could get the data dump for them while another said it couldn't, and old content that took several passes to restore. FeverBee's Millington also reports customers saying full exports were harder to get than they should be, with some describing charges for extra exports. That is reported, not verified, so ask your own account team and get the reply on record.
While you're at it, pull out your contract and find the renewal date and the cancellation notice period. The export question and the notice deadline need to be answered together. Missing the notice window may mean paying for another term of a platform you're leaving.
Get a small sample export before you commit. It should include a discussion with replies, an accepted solution, an article, an attachment, a private area and a member with custom fields. Check the files themselves. A row count does not tell you whether an image, a permission or a piece of history can make the trip.
Take an SEO baseline while Khoros is still running
Khoros gets SEO mostly right, and that works in your favour. Aurora discussion URLs commonly use a slug plus a numeric ID, like /discussions/{board}/{post-slug}/1234. Classic discussion URLs often carry the thread title and an ID in the /t5/{Board}/{Title}/td-p/{id} pattern. Those IDs make much of the redirect map possible, but you still need to inventory the URLs your own site has produced.
Before anything changes, save four things:
- The full list of URLs from your Khoros sitemap. On Aurora, Khoros documents sitemap generation as something Support enables, so open that ticket early if yours is off.
- A Search Console export of your top pages by clicks, going back as far as it allows.
- The indexed page count from Search Console's page indexing report.
- A list of every URL family in use, with a sample of each. Discussions, articles and blog posts each have their own pattern. Tag pages and user profiles do too.
Also check for custom canonical tags. Aurora lets authors set a canonical URL per post, and some posts point their canonical somewhere else entirely. Find those before you map anything, because they tell you which pages Google is already being told to ignore.
Keep your hostname if you can. If the community lives at community.yourbrand.com today, launch Discourse there too. Redirects within the same host are the easiest move you can hand Google.
Discourse has strong search foundations, including public topic pages and sitemaps. The thing to test is what happens to your pages during the move: which ones remain public, what their new URLs are, and whether the old links reach them.
Map every content type before you map a single post
Khoros Aurora covers a lot of ground. Forums and Q&A with accepted solutions sit alongside knowledge base articles and blogs, and ideas and events have boards of their own. Discourse is built around discussion, and most other content types arrive through plugins or theme components. Here is where each one usually lands.
Swipe sideways to see the full comparison.
| Khoros content | Usual Discourse home | What to check |
|---|---|---|
| Forum discussions | Topics inside categories | How deep your board tree is, and how much to flatten it |
| Accepted solutions | The Solved plugin | Markers can be mapped during import if the plugin is active while the import runs |
| Knowledge base articles | Doc Categories plugin, or wiki posts | Article layout and navigation feel lighter than a dedicated KB |
| Blogs | A category styled with a blog theme component | Discourse has no native blog |
| Ideas | Topic Voting plugin | Voting works; status workflows are simpler than Khoros ideas |
| Events | Events and calendar plugins on qualifying hosted plans | Check your actual registration, ticketing and check-in needs |
| Ranks and kudos | Trust levels, badges and groups; kudos become likes | Nothing maps one to one |
| Private messages | Private messages | Decide how many years are worth importing |
Plugin availability varies by hosted plan. Check the current plan table against the exact features in your sample, and ask about any custom plugin you depend on.
Now open the Search Console export from the last step. Group your top pages by URL family and see where the clicks actually land. If most of your search traffic lands on discussions and accepted solutions, Discourse will feel like home almost immediately. If a big share lands on knowledge base articles, blog posts or ideas, the rows for those content types are where your SEO risk lives, and they deserve the most testing time.
Decide what stays behind
A few things will not survive the move, and it is better to decide that on purpose.
Plan for passwords not to migrate. If members use local Khoros credentials, test Discourse's first-login and password-reset flow. If you use SSO, test the identity mapping with real accounts before launch. An existing SSO setup does not, by itself, prove that every member will land in the right account.
Ranks need a new meaning. In Discourse's write-up of an anonymized enterprise Khoros migration, ranks like Platinum and Gold ended up spread across trust levels, badges and group memberships. Discourse describes the aim as keeping the status members had earned in a form that fits how Discourse works.
Themes and custom components need rebuilding. So do Salesforce connector settings and automation rules. Make a list of what each integration does, who owns it, and what failure would look like on launch day. A green connection status does not prove a case or lead reaches the right team.
And some content should stay behind. Discourse's migration checklist warns you to look for spam that came across. Dead boards, auto-generated notices and years of old private messages are all candidates for trimming. Decide with your legal and community teams before an engineer silently excludes them.
Treat private data as a separate migration
Public SEO pages are only one part of the job. Inventory staff-only boards, customer groups, private messages, deleted posts, custom profile fields, bans and suspensions. Map each permission to a named Discourse group and test it with an account that should get in and one that should not. A private thread appearing in search or in the wrong member account is a much bigger problem than a broken heading.
Agree how long exported member data will sit in staging, who can download it, and when copies will be removed. The Discourse pre-launch checklist explicitly calls for testing restricted categories, private messages and suspended accounts. Put those checks in your sign-off, not in an afterthought after DNS changes.
Budget for the real costs
On the Khoros side, the direct costs are engineering time if you end up extracting through the API, any export fees your account team quotes, and overlapping contract months if the timing is tight.
On the Discourse side, hosted plans are public. As of September 2026, Pro is listed at $100 a month, with five staff seats and 500,000 monthly browser page views. Business is listed at $500 a month, with standard migration services, more plugins and fifteen staff seats. Enterprise is custom-priced. The list price is a starting point, not a quote for moving a complex Khoros community.
Read the migration terms closely. Discourse states that its migration service requires a year of hosting paid in advance. At Business list price, that is $6,000 before any extra scope or tax. Its published Business and Enterprise migration descriptions each include 24 project hours; Enterprise covers more tailored work. Ask what happens when your content, redirects or integrations need more than the included time. Get the answer before the purchase order.
One billing detail matters if you're coming from Khoros. Discourse says its published page-view allowance counts browser visits, not bots and crawlers. Check what your current Khoros contract counts before treating the two bills as comparable. Storage, email volume, staff seats, custom work and any overlap between vendors belong in the same spreadsheet.
Self-hosting is the other route. The software is free, but the server bill is only one line. Someone owns upgrades, Postgres, security fixes, outbound email, backups and restore tests. Someone also has to adapt and run the importer against the data Khoros actually gives you. If you are weighing self-hosting, price the people and the on-call work as carefully as the machine.
Budget people as well as money. Your community lead, support lead, security reviewer and whoever owns DNS and identity will all have decisions to make. Discourse can run an import, but only your team can say whether a top answer, a private board or a moderator's permissions came across correctly.
Tell your members early, starting with your superusers
The social side of a migration fails quietly, so plan it with the same care as the data.
Brief your most active members privately, weeks before any public announcement. They know which threads matter and which old answers still get linked from other sites. Give them access to the review site once it exists. They'll catch problems your team won't, and when launch day comes they'll be answering "where did my post go?" questions before your staff are.
Then announce publicly with a date, a reason and a plain list of what changes for members. Pin it. Repeat it in the community newsletter and again a week before the read-only window.
Say the password reset out loud, more than once. Most launch-day confusion is about logging in. If members know in advance that a reset email is coming, the first morning goes much better.
Explain what happens to status. A member who held a top rank on Khoros and arrives on Discourse looking like everyone else will feel demoted, even if the data is technically correct. Tell them how ranks will map and grant the badges and groups at import time, not two weeks later.
During the migration
Work in three environments
Discourse describes three sites for enterprise migrations. A sandbox holds your theme, settings, plugins and SSO and stays empty of imported content. A review site holds imported data and gets wiped and re-imported as the mapping changes. Production is where the final configuration and the final data meet at launch.
If you are on a different service tier or self-hosting, ask what review environment you will actually have. You still need somewhere to test a full import without exposing member data to the public.
The important habit is re-importing rather than patching. When the review site shows a problem, fix the mapping and run the whole import again. Hand-edited fixes on an imported site are lost the next time anyone runs the import.
The first review pass on Discourse's anonymized Khoros project turned up three problems worth putting on your own checklist. Archive categories were too visible to everyday members. Some high-value tags were missing because they hadn't made the allow-list. And category moderators had more power to delete than the customer's legal team was comfortable with.
Rebuild categories and tags on purpose
Khoros communities that have run for years tend to grow deep board trees. Use the move to flatten them. Map every Khoros board to a Discourse category or a tag, and mark the sections that should become read-only archives.
Treat tags the same way. Build an allow-list of the tags that mean something, grouped by type such as product or region, and let the rest go. Importing every tag you've ever had brings the noise with it. But keep a record of what you dropped. The first person asking for an old product tag should get an answer, not a shrug.
Build the redirect map
Discourse redirects old URLs through its permalinks table. Each entry matches an old path and sends it to a topic, post, category or user. Permalink normalizations let you match whole URL patterns instead of listing every path, and importers can write permalinks as they create each topic.
For discussion pages with stable numeric IDs, much of the map is mechanical. Old ID in, new topic out. A few details decide whether it works in practice.
If you upgraded from Classic to Aurora earlier, Khoros is currently redirecting your old /t5/ URLs to their Aurora versions. Once Khoros is switched off, nobody is doing that any more. Classic URLs still earning links from other sites need their own entries in your map, pointing straight at the new Discourse topic.
Comment permalinks need mapping too. Aurora gives replies their own URLs under the parent post, and those should land on the matching reply inside the Discourse topic, not just the top of the thread.
Watch for path collisions. An admin on Discourse Meta found that his old URLs never reached the permalinks table because Discourse's own router claimed those paths first. Discourse uses some path prefixes that Khoros also uses. Aurora tag pages live under /tag/, for example, and so do Discourse's. Test every URL family, not just discussions.
Then test the map properly. Take the top 200 URLs from your Search Console export, plus samples from every URL family, and request each one against the review site. Every mapped page should reach its intended page in one permanent redirect. Do not send missing articles, replies and user profiles to the homepage just to make a crawler see a 200.
Protect content fidelity
Khoros content carries years of platform-specific markup. The conversion to Markdown will need cleanup, and the review site is where you find out how much.
Check mentions and code blocks on a sample from every board, then embedded video and spoilers. Check attachments and inline images most carefully of all. Download every file and image into the import rather than leaving posts pointing at images hosted on Khoros. Those links stop resolving when the contract ends, and a thread full of broken images is often the first thing a returning member notices.
Run the same checks on old and new content side by side. Compare authors, timestamps, reply order, accepted answers, quoted text, uploads and internal links. Include posts in other languages and posts with deleted or hidden replies. A migration can hit its total post count and still put the wrong author on the answer people trust.
Agree what counts as done
Before the final export, write down what your team will sign off on. I would want counts for users, topics, replies, uploads and private messages, with an explanation for every material difference. I would want the top search pages and every URL family checked, restricted spaces tested with the wrong account, SSO and email tested, and the integrations exercised end to end. Discourse has a detailed pre-launch checklist; use it as a starting point and add the things peculiar to your Khoros site.
Give each check an owner and a result. "Looks fine" is difficult to revisit when a customer reports a missing answer on day three.
Cut over with a read-only window
The usual cutover sequence is to make Khoros read-only, take the final export, run the final import, check the result, and then change DNS and email. Agree the exact sequence with the team doing your migration. Custom identity or integration work can change it.
The read-only window is a community decision as much as a technical one. Agree its length with your community team based on what members will tolerate, and announce it with a banner on Khoros. While it runs, keep your engineering and community leads on call, with support ready for login questions.
Set a go or no-go time. Keep the old site and DNS configuration available until the new site passes the checks you agreed on. If the final import fails, know who can extend the read-only window, what you will tell members, and whether you can safely return to the old site. Once members start writing on Discourse, switching back creates a second data problem. Decide that point of no return before launch, not during an outage.
After launch
Watch the first 72 hours closely
Discourse treats the weeks after launch as a project phase of their own. In their Khoros example, it caught usernames that needed Unicode support switched on, a few category redirects still pointing at the staging structure, and a set of intentionally closed topics that members wanted reopened.
Start with the counts. Compare user and topic totals on Discourse against your final Khoros export, then posts and uploads. Then work the 404s. Every missing redirect you find in the first week is a permalink entry to add. Check old inbound links and the top pages from Search Console first, then work through the rest of the logs.
Open a pinned topic where members can report broken links and missing content, and answer every report within a day. It turns your most engaged members into testers, and it tells everyone else the team is paying attention.
Track search against your baseline
Submit the new sitemap in Search Console on launch day. Then compare indexed pages and clicks against the baseline you saved, once a week, for at least two months. Some movement right after a platform change is normal. If a particular URL family keeps losing traffic, inspect its redirects, canonical tags, public access and page quality before deciding the platform itself is the cause.
Follow up with members
Two weeks after launch, check how many members have signed in on Discourse. Email the ones who haven't, with the reset link and a short note on what's new. Some of your quietest long-time members will only come back if someone asks.
Then check in with your superusers. Ask what feels worse than Khoros and what feels better. The first list is your next month of work.
Close Khoros last
Keep the complete Khoros export archived somewhere you control. Don't let the Khoros contract end until the counts match, the redirects are verified and your team has signed off on the migrated content. Once the platform is gone, so is your chance to re-export anything you missed.
If you're still deciding
If you've read this far and Discourse still fits, it is a strong choice for a discussion-led community. It has a public record of very large migrations. I would take that seriously if scale and complex permissions are the deciding factors.
If the content-type table worried you, or most of your search traffic lands on articles and knowledge content rather than threads, compare the destinations with a sample of your own pages before you sign a year upfront. You can book a 30-minute call with me, read how different forum platforms handle SEO, or compare Discourse and Jatra directly. Bring the awkward content and the contract questions. Those are more useful than a polished demo.
