However, during the dB export, we need to update all the entries to reflect the local URLs. How does this work with Craft? do dB entries need to be updated to reflect the new URLs?
Sounds like you might be coming from something like WP where it hardcodes URL and links in the database? You'll be happy to know that is not the case in Craft.
Craft generally uses Reference tags when it needs to store links to assets, entries, etc. in the database. This neatly sidesteps around the problem of having to do a find/replace every time you move environments since those URLs are "built up" on-the-fly.
However, this only works for new content the you create in the CMS. On the off-chance that you're moving legacy content from another CMS to Craft, you can use Craft's built-in find/replace tool inside Utilities to do the find/replace.
Is there no other way to have a single large migration (contents, settings, fields, etc.) happening at once?
Generally you want your migration to go one-way.
You'll want to read up on Project Config but in general, you start on local then push your project config to staging or production. This prompts Craft to update the structural items in the CMS (added sections, fields, etc.)
Moving actual content from staging to production itself is more of a challenge. The Migration Assistant you linked up does lets you export content as well as structure, but usually you want to keep those sorts of changes as narrowly defined as possible.
Databases are highly structured beasts. When you start adding content on production then try to push an update from staging, that's a recipe for all sorts of breakage.
As an example, say you have an entry on staging that relates to a bunch of different categories, assets, and entries. Unless those entries, categories, and assets are already created on production, how does Craft know what to do with all of it?
On a technical level, primary and foreign keys could be different, for example. Some systems get around this with GUIDs, but in general, it's still a hard problem to solve unless the two are kept in sync somehow—which is what enterprise systems generally do.
WP for example has more tools to deal with this sort of thing but they're still more simplistic in this sense because it doesn't have all the relational capabilities of Craft.