RFP: How do we deprecate super-legacy database migrations?

> [!NOTE]
> Migrated from [augurlabs/augur#3542](https://github.com/augurlabs/augur/issues/3542)
> Originally opened by `@MoralCode` on 2026-01-10

---

**This is a request for proposals. Do NOT submit a pull request for this issue. It requires extensive discussion and planning and is intended for the long-term future of Augur.**

Lets start the discussion about when and how we can enable ourselves to delete what im going to call the "super-legacy" migrations (.sql files and basically anything that serves the purpose of a mgration, but predates our use of alembic).

I would like to not have to maintain these files in the repo forever.

My short to medium term future plans include making augur less reliant on migrations for any day to day operations (like DB initialization) except for migrating the DB, I plan to do this by:
- initializing the DB directly from the current models when the user wants a fresh DB (i.e. on first startup, in unit tests, etc)
- rolling out this method of initializing db schemas for use in the unit tests only as a pilot
- possibly rolling this out to the main repo if it is reliable

As augurs version numbers approach a nice round 100, I think that may be a good time to remove these older migrations. If a user is on a version of augur that is so old that it would still rely on these super-legacy migrations to get up to date with the current version of augur, then I think requiring them to upgrade to a version of augur pre-100 (to get them into alembic territory) before they can upgrade the rest of the way seems like a reasonable trade-off for still supporting these users without requiring us to keep those migration files around forever.

Thoughts, comments, alternatives?