From ruTorrent to qBittorrent: A Migration Guide for Long-Time Users

I ran rTorrent with the ruTorrent UI for over a decade. It is fast, light, and proven. In 2026, qBittorrent has caught up and surpassed it for most use cases: better Web UI, more robust scheduling, native search, and a development team that ships consistently.

Whether you should migrate depends on what you are using ruTorrent's strengths for. This is the honest comparison plus the actual safe migration path on QuickBox Pro.

Stay on ruTorrent if:

• ●You have decade-old custom scripts wired into rTorrent's event.download_xxx hooks
• ●You rely on a specific ruTorrent plugin (RSS-Manager, Tracklabels, theme work) that has no qBittorrent equivalent
• ●You manage hundreds of torrents with category-based ratios and have invested heavily in rtorrent.rc tuning
• ●Your private trackers explicitly require an rTorrent client signature

Migrate to qBittorrent if:

• ●You want a modern Web UI that does not look like 2008
• ●You want native search engines, RSS-with-rules, and IP filtering without plugins
• ●You hit ruTorrent's HTTP wall with very large queue counts (1000+ torrents)
• ●You want better mobile Web UI rendering without nginx hacks

The migration sequence below is built around this fact: install and verify qBittorrent FIRST, while rTorrent is still running, then remove rTorrent only after everything is confirmed working in the new client.

The full state of an rTorrent install lives in five places:

1. ●The session directory (~/torrents/rtorrent/.sessions/), containing one <infohash>.torrent, .rtorrent, and .libtorrent_resume per torrent
2. ●The actual download files inside ~/torrents/rtorrent/
3. ●The trackers list and per-torrent metadata baked into those session files
4. ●Your ~/.rtorrent.rc tuning (which you do not need on the qBittorrent side)
5. ●Your ruTorrent settings, plugins, and themes (which you do not migrate)

The data is the easy part. qBittorrent rehashes existing files in place. The state (ratio, upload total, tracker history) is what requires manual work.

There is no qb migrate command. The migration is a manual six-step process. Both clients can run in parallel on QuickBox Pro since they use different ports and separate config directories, so you can verify everything in qBittorrent before destroying the rTorrent state.

This is the only way to preserve your .torrent files and resume state across the migration. Do this from a shell:

cp -r ~/torrents/rtorrent/.sessions/ ~/rtorrent-sessions-backup/
ls ~/rtorrent-sessions-backup/ | head

You should see .torrent files and per-torrent resume files in the listing. Do not skip this step. If you skip it and run a remove later, the data is gone.

Removing ruTorrent is safe. The script removes only the web app at /srv/rutorrent/, the PHP-FPM pool, and the nginx include. It does NOT touch your torrent data or rTorrent itself.

Via the App Management dashboard: find ruTorrent in the catalog and click Remove. Or via CLI:

qb remove rutorrent -u username

rTorrent keeps running in the background after this step.

Both can coexist on the same box. qBittorrent installs to ~/.local/share/qBittorrent/ for data with config at ~/.config/qBittorrent/ and a watch folder at ~/torrents/qbittorrent/watch/. It starts with an empty torrent list.

Via the App Management dashboard: find qBittorrent in the catalog and click Install. Or via CLI:

qb install qbittorrent -u username

See the qBittorrent documentation for Web UI access, port assignment, and initial setup.

qBittorrent does not read rTorrent's .libtorrent_resume format. You re-add the .torrent files from your backup and point qBittorrent at the existing data so it can rehash and resume seeding.

For each torrent you want to keep:

1. ●In the qBittorrent Web UI, click Add Torrent
2. ●Select the .torrent file from ~/rtorrent-sessions-backup/
3. ●Set the save path to where the actual data lives (typically ~/torrents/rtorrent/ while rTorrent is still running, since that is where the files physically sit at this point)
4. ●Check "Skip hash check" only if you are certain the data is byte-complete; otherwise let qBittorrent rehash

Per-torrent upload statistics reset to zero on the qBittorrent side. Private trackers compute your ratio from announces, not from your local client counter, so your tracker standing is unaffected by the local reset.

In the qBittorrent Web UI, confirm:

• ●All trackers report "Working" status after one announce cycle (typically 30 minutes)
• ●Download or upload activity appears on torrents that have peers
• ●Re-hashing has finished for every torrent if you did not skip it
• ●Disk usage looks correct (you have not accidentally double-downloaded into a different path)

Force a manual re-announce on any tracker showing errors. Some private trackers throttle simultaneous announces from the same IP and recover on the next cycle.

Only after Step 5 passes. Removing rTorrent deletes ~/torrents/rtorrent/ entirely, automatically cascades to remove ruTorrent (already gone from Step 2), and stops the systemd unit.

Via the App Management dashboard: find rTorrent in the catalog and click Remove. Or via CLI:

qb remove rtorrent -u username

If your qBittorrent torrents had their save path set to ~/torrents/rtorrent/, the data files there will be gone after this step. Either move the data files to a path qBittorrent owns BEFORE running this remove, or accept that qBittorrent will need to re-download once rTorrent's directory is gone. The cleanest approach is to set qBittorrent's save path to a directory outside ~/torrents/rtorrent/ before Step 6 (qBittorrent has a "move data" option in the right-click menu per torrent).

Once everything is running cleanly in qBittorrent and you have confirmed no data was lost:

rm -rf ~/rtorrent-sessions-backup/

Most private trackers do not care which BitTorrent client you use. A handful explicitly require rTorrent. Read your tracker's rules before migrating. If you migrate against tracker policy, expect a warning at minimum.

Some trackers compute peer reputation by client. A migration that changes your reported user-agent can theoretically affect peering on the first announce. In practice, qBittorrent peers with everyone fine.

See the rTorrent documentation and ruTorrent documentation for reference while you are transitioning.

My personal seedbox ran both clients in parallel for a full week during my migration. ruTorrent handled a small set of torrents with long tracker history. qBittorrent took over everything else, then took over those last holdouts once I was confident in the new client. The whole transition takes one evening of focused work for a typical seedbox, plus a week of soak time before pulling the rTorrent rip cord.

Your mileage will depend on how many torrents you have and how many trackers you care about. Back up the session directory first, install qBittorrent alongside rTorrent, verify everything, then run the removal last. The order matters because the removal is irreversible.