Moving from Joomla, Drupal or another CMS to WordPress is a content migration with a structural decision attached: the old system's URLs almost certainly do not match anything WordPress produces, and every one of them is either redirected or lost.
Export what you can, expect gaps
Most systems export content in some form, and importer plugins exist for the common ones.
What transfers reliably: article titles, bodies, dates, and usually categories. What does not: the layout, anything held in custom fields the importer does not know about, module or block content that sat beside the article, and user passwords, which are hashed and cannot be moved.
So plan for users to reset their passwords, and plan to rebuild anything that was not in the article body itself. How to Move from a Website Builder to Your Own Hosting walks through the same problem from a hosted platform.
Inventory the URLs first
Before importing anything, list every address on the old site with its traffic.
That list is what you will redirect from, and it is far easier to collect while the old site is running. Note which pages actually get visitors: on most sites a small number carry nearly all of it, and those are the redirects that must be right.
Decide the new URL structure deliberately
Two approaches, and the trade is real.
Reproduce the old structure where WordPress can, matching the path means no redirect for that page and no risk. Permalinks and a category base can get you close for many sites.
Adopt a clean WordPress structure and redirect everything. Tidier, and every page depends on a rule being correct.
Reproduce where it is cheap, redirect where it is not. There is more on what WordPress can express in WordPress Permalinks and .htaccess.
Redirect by pattern, then by exception
Old systems usually produce systematic URLs. A numeric id, a fixed prefix, an index file with parameters. That means one rule can cover thousands of pages.
Write the pattern rules first, then handle the handful that do not fit individually. A page-by-page list for a large site is a maintenance burden nobody will keep. How to Redirect a Domain or Page explains writing them.
Send each old address to its equivalent, not to the homepage. And check for chains: several stacked rules easily produce three hops where one would do.
Images are the part that breaks quietly
An importer brings the article text across with image tags pointing at the old system's paths.
If the old site is switched off, those images stop loading, and the page still renders, so nobody notices until someone looks. A good importer downloads the images into the media library and rewrites the references; check that it did rather than assuming.
Then run a database search and replace for any remaining old paths, using a tool that understands serialised data. How to Change Your WordPress Site URL goes over why a plain replace corrupts things.
Rebuild the functionality, do not import it
Forms, galleries, member areas and shops were extensions in the old system, and they do not transfer.
List them before starting, because that list is the actual project. A content import is a day; replacing five modules with WordPress equivalents is not, and it is where migrations overrun.
Choose the replacements deliberately rather than installing whatever appears first. Each one is code you will maintain. For judging them, see How to Choose and Vet WordPress Plugins.
Build on a temporary address
Set the new site up somewhere the public cannot reach while the old one keeps serving.
Keep it out of search results until launch, and remove that block on the day, because it is the most common launch mistake there is. How to Prepare a Website Launch Checklist goes into the rest of the switch.
Do not switch off the old system immediately
Keep it running, on its own address, for a few weeks after launch.
It is where you check what a page used to look like, and where you find the content the importer missed. Once it is gone, "what was on that page" has no answer.
Take a full backup of it before it goes, including its database, and keep that for a year.
Watch the crawl errors, not the traffic
Traffic moves for a few weeks after any migration and that is expected. What is not expected is a stream of 404s.
Check the search console's crawl errors weekly for the first month. Each one is a redirect you missed, and they are cheap to fix while the move is recent. How to Find and Fix Broken Links on Your Site walks through reading them from your own logs too.
Keep the redirects permanently. Links on other sites are never updated, and a rule removed after "traffic recovered" breaks them silently years later.
Keep the old site reachable until the new one is proven
A migration between systems changes both the content and the addresses, and the mapping between them is the part that is wrong in ways nobody notices for weeks. Keep the previous site running, unindexed, for at least a month. It is the only reference for what a page used to contain when somebody reports that something is missing, and it is the fastest way to check whether a formatting problem was introduced by the import or existed already. Cancelling immediately saves one month of hosting and removes the only evidence.