SQL Server to PostgreSQL Migration Checklist
A pre-flight checklist for SQL Server to PostgreSQL migrations covering object inventory, data-type and collation gaps, T-SQL rewrite scope, and reconciliation. It surfaces SQL Server-specific risks like case-insensitive collation early. Use it before any build work begins.
When to Use This Checklist
Use this checklist before migrating a Microsoft SQL Server database to PostgreSQL. Teams make this move to cut licensing cost or consolidate on open-source infrastructure. SQL Server and PostgreSQL both speak SQL, but they diverge on data types, procedural language (T-SQL versus PL/pgSQL), default collation behavior, and proprietary features. Surfacing these gaps before the build phase keeps estimates honest.
How to Use This Checklist
Start with discovery: inventory every schema object and the application SQL that touches it, including ORM dialect settings. Then plan, giving each SQL Server-specific construct a documented decision to keep, rewrite, or redesign. Pay particular attention to collation, since SQL Server's common case-insensitive default does not carry over to PostgreSQL and can change query results. Treat reconciliation and a rollback plan as required gates before cutover.
What Good Looks Like
A strong pre-flight yields a complete object inventory, a data-type mapping table with no unresolved lossy conversions, and a list of every T-SQL unit slated for rewrite. Collation and case-sensitivity differences are explicitly handled, SQL Server Agent jobs are rescheduled, and character-set conversion to UTF-8 is planned. A migration method sized to the data, a per-table validation plan, and a tested rollback complete the picture. The team can estimate effort with confidence.
Common Pitfalls
The subtle trap is collation: queries that worked under SQL Server's case-insensitive default return different results on PostgreSQL. Teams underestimate the T-SQL to PL/pgSQL rewrite effort and overlook behavior gaps in IDENTITY, MERGE, and CTE handling. ORM dialect settings left on SQL Server cause silent query failures. Skipping reconciliation lets dropped or mis-converted rows reach production. Finally, no rollback plan turns a parity failure into an outage.
Related Resources
Ground schema work in schema-evolution-schema-registry and design parity checks with data-quality-management. Migrate incrementally with the expand-and-contract-migration-pattern and frame the effort using the continuous-modernization-playbook.