Start with the application, not a feature checklist
Choose an application with a real migration path and routine workload. Identify the ORM, the SQL dialect it emits, how it obtains generated IDs, and how it handles transactions, catalog inspection, and schema changes.
A compatibility target should be small enough to understand but rich enough to reveal the queries that matter. Gogs and Vikunja are valuable because they reach different parts of the SQL surface.
Build the narrowest bridge
Add a database/sql driver or dialect adapter only where the application needs one. Keep the application's SQL generation intact when that gives the clearest migration path, and make placeholder binding, generated IDs, and connection ownership explicit.
At the proxy boundary, classify every statement conservatively. Allow the read-only catalog operations and scoped DDL the application truly needs; leave unknown statements denied until there is a reviewed reason to support them.
- Exercise migrations first: they reveal catalog, DDL, index, and constraint requirements.
- Exercise the normal application flow next: creation, listing, updates, permissions, and background work.
- Add engine behaviour with focused tests, then rerun the application integration through the proxy.
Document limits as part of the port
A successful port includes its limits: unsupported backup paths, storage-format assumptions, TLS boundaries, connection-pool budgets, and unverified SQL features. Recording those constraints keeps an experimental integration useful without turning it into an overbroad compatibility claim.