While the two sets of tools are generally distinct, I think it can be argued that they both mean the same thing by "migration".
For application code, we generally talk about "deployment" or "release": the new version replaces the old version, usually in one go. We might also talk about patching, but that's still effectively replacing code.
For databases, we don't generally delete the old database and create a new one. Sometimes, we are simply adding new functionality alongside the existing one, but often, we need to transform the schema in some way. This transformation is what is meant by "migration" in both of these contexts:
- When moving from one database engine to another, we generally have to extract the data from the old database, transform it in some way, and then insert it into the new database.
- When changing a live database from the schema required by version N of an application to the schema required by version N+1, we might have to do something similar: take the contents of old table X, populate new table Y, and drop table X.
The two types of "migration" are supported by different specialist tools, but the concept is the same: you give the tool an initial schema and a desired schema, and some hints about how they relate; and the tool generates the necessary SQL and DDL commands to "migrate" your live data from one schema to the other.
As you've observed, one major difference is that tools for managing the schema needed by your application often also include or integrate versioning functionality. That's because in this context you're likely to make frequent small migrations, and need to manage their deployment to different environments at different times. Tools focussed on migrating between wildly differing database engines don't need to focus as much on this feature, but may instead have features like continuous data replication, where you run the two databases in parallel.