Commercial Bank: SQL Server → PostgreSQL Migration Program

01 · BUSINESS PROBLEM

The licensing treadmill, plus end-of-support risk

The bank ran core transaction-processing workloads on SQL Server across multiple application portfolios. Two pressures converged: enterprise licensing renewals kept repricing a platform the bank didn't strategically need, and aging versions were drifting toward end-of-support — which in banking means either forced upgrades on someone else's schedule or paid extended support with a clock on it.

Leadership didn't want a cheaper database. They wanted optionality: an estate they could evolve on their own cadence, with licensing economics that didn't punish growth. PostgreSQL was the target because the team's workloads — relational, transactional, reporting-adjacent — mapped to it cleanly, and the managed-PostgreSQL market had matured enough for regulated workloads.

02 · INDUSTRY

Anonymized

Industry

A national commercial bank — retail and commercial banking operations.

Anonymization

Client name, brands, and identifying details withheld. The engagement described is practitioner experience; it is presented as experience informing AnovaCloud's methodology, not as an AnovaCloud delivery claim.

03 · SCALE

Orders of magnitude that shaped the design

Workloads

Business-critical, always-on transaction processing plus reporting and operational analytics — the workloads a bank cannot afford to get wrong.

Estate shape

Multiple line-of-business application portfolios, each with its own databases, integrations, and release cadence — a program, not a project.

Recovery bar

Strict recovery expectations: cutovers had to be rehearsed and reversible, because "rollback" is not a strategy in production banking.

04 · CONSTRAINTS

The non-negotiables

• Zero data loss: every migrated database had to reconcile row-for-row against the source before cutover — sampling was not acceptable for the core portfolios.
• Cutover windows: dictated by banking hours and change-freeze calendars, not by engineering convenience.
• Regulatory audit: the migration itself had to be auditable — who converted what, what was tested, who signed off.
• T-SQL gravity: years of stored procedures, functions, and reporting logic written in T-SQL idioms that don't translate mechanically.
• Team skills: the operating team's deep expertise was SQL Server; PostgreSQL operations had to be learned during the program, not before it.

05 · BASELINE

What the estate looked like before

SQL Server across several versions and editions, grown organically over years: transactional databases per application, reporting extracts, SQL Agent jobs, SSIS packages, and linked-server integrations that nobody fully mapped. Licensing was managed at renewal time — a periodic negotiation, not a strategy. Monitoring and backup were solid but SQL Server-specific, which meant the operational muscle for PostgreSQL didn't exist yet.

06 · TARGET ARCHITECTURE

The migration factory

The design treated the migration itself as the system to engineer. A migration factory ran every database through the same stages: discovery and inventory (census, versions, feature usage), compatibility assessment (conversion-effort scoring per object), an automated conversion pipeline (schema, T-SQL, test data), and a replication-plus-parallel-run stage where the PostgreSQL target ran alongside the source under change data capture until dual-run comparison reconciled. Cutover was a rehearsed gate — practiced, timed, reversible — not a leap of faith.

The target was a managed PostgreSQL fleet with high availability, automated backups, and observability (metrics, slow-query analysis, alerting) built from day one — because the operations team was learning PostgreSQL in production, and production is a bad classroom without instrumentation.

07 · KEY DECISIONS

The tradeoffs that mattered

08 · IMPLEMENTATION

Phased by risk reduction

09 · GOVERNANCE

Who decided what

• A wave review board — application owners, DBAs, security, and program leadership — approved each wave's scope, cutover plan, and rollback criteria.
• Change control treated migrations as production changes: documented, approved, and scheduled inside the bank's existing process, not around it.
• Runbooks for every cutover, versioned and rehearsed; sign-off required from application owners before traffic moved.
• Capability transfer was a tracked deliverable: the bank's engineers operated the factory in later waves, so the methodology stayed when the program ended.

10 · SECURITY

Controls for a regulated estate

• Encryption in transit and at rest for both the migration pipeline and the target fleet; secrets managed centrally, never in scripts or runbooks.
• Least-privilege service accounts for replication and conversion tooling — scoped per wave, rotated on schedule.
• Full audit trail of the migration itself: what was converted, what was tested, who approved the cutover — the evidence a regulator or internal audit would ask for.
• Target hardening baselines applied before first production data landed, including network segmentation consistent with the bank's existing zones.

11 · CHALLENGES

What was actually hard

• T-SQL hotspots: a minority of objects — complex procedures, dynamic SQL, proprietary functions — consumed a majority of conversion effort. Scoring them early kept wave plans honest.
• Application compatibility: some applications assumed SQL Server behaviors (locking semantics, date handling, error codes). These surfaced in parallel run, not in code review — which is why parallel run existed.
• Stakeholder fatigue: multi-wave programs outlast attention spans. The wave board and a visible decommission schedule kept momentum when the novelty wore off.
• Rollback readiness: maintaining a credible rollback path through the final waves required discipline — replication lag monitoring, not optimism.

12 · RESULTS

Outcomes, described without invented metrics

• The migration factory moved from a pilot wave to progressively larger waves as conversion artifacts accumulated — each wave banked reusable conversion rules, test data, and runbooks, so later waves drew on earlier ones instead of starting over.
• Cutovers ran under rehearsed runbooks with practiced rollback drills; the cutover gate became routine rather than exceptional.
• The bank's own engineers operated the factory in the later waves — capability transfer was the design goal, and the program was structured so the methodology outlasted it.
• Source instances were decommissioned on a tracked schedule with license true-up, so the economic case was realized in the estate, not just in the business case.

13 · LESSONS LEARNED

What generalizes

• The factory is the deliverable. Any single database can be migrated with heroics; a program needs a repeatable machine. Build the machine first, on the easiest real work.
• Score before you schedule. Compatibility scoring is the difference between a wave plan and a wish. The databases that surprise you are the ones you didn't score.
• Parallel run is the truth serum. Code review and unit tests catch conversion errors you anticipate; dual-run comparison catches the behaviors applications actually depend on.
• Rehearse the rollback, not just the cutover. A rollback plan nobody has practiced is a hope. Drills are cheap; production incidents are not.
• Decommission on a schedule. Migrations that end at cutover leave the old estate — and the old licenses — running. The program isn't done until the source is gone.

14 · RELATED

Pattern, toolkit, service