Migrating from SQL Server to PostgreSQL without stalling the business

Migrating the database engine of a production system is one of those decisions that sound simple on a slide and get complicated the moment you touch the first stored procedure with business logic hidden inside.

The real problem

It wasn’t just “swap the engine.” It was:

• Holding availability SLAs while migrating.
• Coexisting with third-party integrations that assumed specific T-SQL behavior.
• Keeping the team shipping new features in parallel.

Strategy

We worked in phases, not a big-bang cutover:

1. Dependency inventory: everything touching the database — stored procedures, jobs, reports, integrations.
2. Data access abstraction layer: introduced a data access pattern that let us target both engines during the transition.
3. Incremental migration by domain: started with the least coupled, least business-critical modules.
4. Dual-write with verification: during the transition window, we wrote to both engines and compared results before the final cutover.

What we learned

The real cost of a migration like this isn’t in the ALTER TABLE. It’s in the logic you assumed was implicit in the old engine — locking behavior, data types, proprietary functions — that has to be made explicit before it can move.

If you’re about to take this on: spend time on the inventory before touching code. It’s the least glamorous part and the one that prevents expensive surprises.