Migrate Microsoft SQL Server and Azure SQL to Supabase

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

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:

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_cron or 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.

Sources

• Supabase: migrate from MSSQL to Supabase
• Microsoft: SQL Server data types
• PostgreSQL: data types