refactor: apply review suggestions

Co-authored-by: Johan Haals <johan.haals@gmail.com>
Co-authored-by: Fredrik Adelöw <freben@gmail.com>
Signed-off-by: Camila Belo <camilaibs@gmail.com>

docs/backend-system/building-plugins-and-modules/01-index.md

@@ -159,8 +159,7 @@ The same applies for modules that perform their own migrations and interact with
 the database. They will run on the same logical database instance as the target
 plugin, so care must be taken to choose table names that do not risk colliding
 with those of the plugin. A recommended naming pattern is `<package
-name>__<table name>`, for example the `Scheduler Service` package creates
-tables named `backstage_backend_tasks__<table>`. If you use the default [`Knex` migration facilities](https://knexjs.org/guide/migrations.html), you will also
+name>__<table name>`, for example the scheduler core service creates tables named `backstage_backend_tasks__<table>`, because it used to be the case that the service lived in a package named `@backstage/backend-tasks`. Things have since moved around a bit, but the effects of the rule are still visible. If you use the default [`Knex` migration facilities](https://knexjs.org/guide/migrations.html), you will also
 want to make sure that it uses similarly prefixed migration state tables for its
 internal bookkeeping needs, so they do not collide with the main ones used by
 the plugin itself. You can do this as follows: