A move from SQL Server to PostgreSQL needs an explicit target model. WZ-IT provides a Supabase migration from €3,490 after reviewing the database, T-SQL and application.
A Microsoft SQL Server or Azure SQL to Supabase migration is a heterogeneous database move. Supabase uses PostgreSQL. Data can be transferred, but T-SQL, types, stored procedures, jobs and permissions need deliberate translation.
Success is therefore not defined by an import process reaching the end. Data, application behaviour and operating workflows must work correctly on PostgreSQL.
Identify the SQL Server source
Determine the actual starting point:
- SQL Server on Windows or Linux
- SQL Server in a virtual machine
- Azure SQL Database
- Azure SQL Managed Instance
- SQL Server on AWS RDS
- multiple databases with cross-database queries
- Always On Availability Groups or replication
Edition and platform affect network access, export options, authentication and available features.
Assess schema and application
| Area | Capture |
|---|---|
| Version and edition | SQL Server version, compatibility level and used features |
| Data model | Databases, schemas, tables, keys and partitions |
| Data types | uniqueidentifier, datetimeoffset, money, bit, XML and spatial types |
| T-SQL | Procedures, functions, triggers, views and dynamic SQL |
| Jobs | SQL Server Agent, SSIS, ETL and scheduled work |
| Identity | SQL logins, Windows Auth, Entra ID, roles and grants |
| Application | Drivers, ORM, raw T-SQL and reporting |
Cross-database queries and linked servers require particular attention because one Supabase database does not reproduce the same server layout automatically.
Map data types deliberately
Example decisions include:
| SQL Server | Possible PostgreSQL target |
|---|---|
IDENTITY |
Identity column or sequence |
uniqueidentifier |
uuid |
bit |
boolean |
datetimeoffset |
timestamptz after timezone review |
nvarchar |
text or varchar in UTF-8 |
money |
numeric with defined precision |
rowversion |
Custom version or timestamp model |
hierarchyid |
Adapted relational model or extension |
Collations and case sensitivity can also change search, sort and uniqueness behaviour. Test them with real data.
T-SQL, procedures and jobs
Reassign T-SQL based on purpose:
- database logic as SQL or PL/pgSQL
- scheduled work through
pg_cronor an external scheduler - integration logic as a worker or workflow
- HTTP and application code as an Edge Function or service
- reporting queries rewritten in PostgreSQL syntax
SQL Server Agent, SSIS packages and CLR code are not portable database objects. Each requires a target decision.
Transfer method
The official Supabase guide references a guided migration route and pgloader. For complex databases, controlled ETL may be easier to validate because transformations and errors can be recorded per table.
The rehearsal validates:
- table and row counts
- Unicode and special characters
- decimal values and rounding
- date, time and time zones
- UUIDs, binary data and large objects
- primary and foreign keys
- identity values and sequences
- views and replacements for routines
Adapt application and authentication
Changing the database driver is often not sufficient. Review:
- T-SQL in repositories and reporting tools
- ORM provider and migration history
- transaction isolation, locks and error codes
- pagination, full-text search and JSON handling
- connection pooling and TLS
- SQL logins, Windows Auth and Entra connections
Introducing Supabase Auth is a separate user migration. Database logins and end-user identities are different concerns.
Accept business behaviour, not only the schema
A technically successful transfer does not prove that the application behaves identically. Define a reproducible acceptance case for every business-critical function, including creates, updates, deletion behaviour, search, filters, exports, reports and concurrent access. Queries that rely on implicit type conversion, NULL handling, string comparison or database-specific ordering can return different results after the move.
Test failure and load paths as well. The application must handle an interrupted write, a unique constraint, a lock and exhausted connections predictably. The T-SQL-to-PostgreSQL move is ready only when both the data state and real user journeys have passed acceptance.
Plan cutover
The final switch may use a maintenance window or a separately designed delta process. Accept data, application, jobs and integrations in staging before release.
Use the Supabase migration checklist for the sequence. The PostgreSQL-to-Supabase guide covers the target database in more detail.
WZ-IT can operate the result as managed Supabase after cutover.
