Summary

Add database migrations to support any changes that may need to be applied to production databases.

Acceptance Criteria

• Clear and testable conditions for the completion of the task.
• Another condition that defines task completion.

Details / Tasks

At the very least, migrations must support SQL Server, but in all likelihood we should support all 4 databases to make development workflows easy. Take the following into consideration

• Can the system fallback to using just SQL for migrations when necessary
• Can new setups (eg onboarding a new developer) make use of the create_all syntax and skip migrations
• When a new build is deployed, how do we prevent N instances of the container from applying the migrations to the same database (eg the deployment setup is running multiple containers to handle load)
• Can we simultaneously support "offline-mode" so users can choose to have migrations automatically applied or manually have a SQL script generated for manual application.

Background / Context

The project previously used database migrations, however they were removed due to the number of schema changes required in the early days of the project. The project is mature enough now, and close enough to needing to support a production database that it's a good idea to re-introduce migrations in case we need to make future schema and/or data changes.