Case study · Platform migration
146 reports, two engines,zero backlog.
Moving a university's PostgreSQL reporting layer to SQL Server for Power BI, without losing a number or leaving a live object undocumented.
- Role
- Data Analyst & BI Developer, then analytics consultant
- Organization
- Southwestern Adventist University, Institutional Research
- Timeline
- Apr – Sep 2026
- Stack
- PostgreSQL · SQL Server (T-SQL) · Power BI · SSMS · pgAdmin
The problem
What neededto change.
Power BI and the university's future reporting run on SQL Server, but the reporting SQL was written for PostgreSQL. Many objects the queries relied on didn't exist in SQL Server.
The reverse was true too: objects were running live in SQL Server with no source in version control.
The approach
How it was built,step by step.
- 01
Inventory first
Documented every table available in SQL Server and every PostgreSQL-to-SQL Server rename, and checked each translated query against it.
- 02
A conversion checklist
Codified the translations, such as DISTINCT ON to ROW_NUMBER(), NULLS LAST to a sort key, casts, arrays and string aggregation, so every port followed the same rules.
- 03
A tracked migration
Ran the move in about 29 cycles with a status tracker (blocked, ready, verified), deploying view ports to unblock queries as it went.
- 04
Twins, kept in step
Every portable query ships as a PostgreSQL and SQL Server pair, and a CI parity check fails the build if the two drift apart.
- 05
Nothing undocumented
Recovered 33 objects that were live in SQL Server but never committed, then re-verified the whole inventory against a full export of the live schema.
The result
What it delivered.In numbers.
Power BI reads SQL Server with no conversion backlog, and every portable query ships in both dialects. Porting also surfaced real bugs, including a join that could repeat aid award rows and a pay rate that lost its cents.
- reports converted; none blocked or queued
- 131 / 146
- PostgreSQL views ported and deployed
- 39
- query pairs kept in sync by CI
- 276