Overview
This is a typical engagement for a SaaS platform team running SQL Server 2016 after its extended support date, with a stack of services and a vendor package that all speak T-SQL. Staying means paying for Extended Security Updates. Moving means deciding how much of the code can change before the deadline that matters to the business.
Challenge
A full conversion to native PostgreSQL means rewriting T-SQL procedures and every caller, while a bridge such as Babelfish promises few code changes but does not cover every feature. The team needs to know which constructs Babelfish will not take, what lives outside the engine, such as Agent jobs and linked servers, and how to keep SQL Server writable until the switch.
Environment
SQL Server 2016 with stored procedures, SQL Agent jobs and linked servers, an application tier using ADO.NET and JDBC, and a target of PostgreSQL on AWS.
Approach
The engagement inventories objects and what sits outside the engine, runs Babelfish Compass over the DDL and captured application SQL, and compares the result with the AWS Schema Conversion Tool assessment for native conversion. It then recommends Babelfish, native, or a staged move, designs the change capture with its prerequisites, and defines validation and rollback before the first load.
Solution
- Inventory procedures, functions, triggers, Agent jobs, linked servers and reporting dependencies
- Run Babelfish Compass over the DDL and captured application SQL and list the unsupported constructs
- Compare Babelfish, full conversion and a staged move against the deadline and the rewrite capacity
- Specify source prerequisites for AWS DMS or Debezium change capture: recovery model, backups, CDC jobs, primary keys
- Map types and collation decisions, including case-insensitive uniqueness and timestamp time zone handling
- Define the validation suite, the cutover runbook and the rollback with its point of no return
Outcome
The engagement delivers a Babelfish compatibility report, a recommended path with the reasoning, a replacement plan for every job and linked server, a change-capture design with its source prerequisites, and a cutover and rollback runbook. The risk of finding unsupported features late is removed, and the choice between a bridge and a rewrite is made on the team's own code.
Technologies
PostgreSQLSQL ServerBabelfishAWS DMS
Kubernetes
Snowflake
Debezium
MySQL
Kafka
Amazon RDS
Kong
