Case Studies

MeeSeva: How India's Largest
G2C Platform Migrated from
Oracle to PostgreSQL

A mission-critical database migration completed with zero data loss and zero service disruption — moving 1,939 tables, 805 indexes, and 85+ citizen services from Oracle 11g to PostgreSQL 17 on a live platform serving 200 million cumulative transactions.

85+

Critical services migrated

1,939

Tables migrated

~200M

Cumulative transactions

Zero

Data loss

<30 sec

Automatic failover (RTO)

Snapshot

Organisation ESD, ITE&C Dept., Government of Telangana
Platform MeeSeva (meeseva.telangana.gov.in)
Source → Target Oracle Database 11g EE → PostgreSQL 17 on Ubuntu 24.04.3 LTS
Migration Tool Ora2Pg v24, orchestrated via Postgres1st's Migration Methodology
Migration Date 4 Apr 2026
Led By Postgres1st (migration architecture, validation & execution lead)
Supporting Partners OpenSourceDB

Why They Migrated

  • Vendor independence: reduce dependence on a single proprietary database vendor for mission-critical public infrastructure.
  • Scalability & flexibility: PostgreSQL's extensibility and open-source tooling ecosystem for HA, backup, and monitoring.
  • Government open-source policy alignment: in step with GoT and GoI direction on open-source adoption in government IT.
  • Licence cost elimination: Oracle licensing + maintenance ran ~₹10+ Crore/year; one-time migration cost was under ₹1 Crore, with estimated recurring savings of ~₹1.5 Crore/year.

Postgres1st's Migration Methodology

Postgres1st led the migration end-to-end using its own phased methodology Assess, Dual-Write, Validate, Cutover, Hypercare - built around Ora2Pg as the schema-conversion engine and hardened with Postgres1st's home-grown Python validation utilities for row-level and checksum-based data parity:

  • Assessment & Planning to scope effort and classify objects by complexity;
  • Dual-Write of Oracle and PostgreSQL in parallel with daily checksum reconciliation;
  • Schema conversion & PL/pgSQL rewrite (50+ objects converted manually);
  • Incremental integration testing, 5 services at a time, validated against real production endpoints;
  • War-room cutover a ~12-hour war-room cutover on 04 April 2026;
  • Hypercare 72-hour hypercare with zero critical issues.

Architecture: Three Schemas, One Instance

An initial 9-node, three-cluster design was replaced after a 2-node-per-cluster alternative exposed a performance bottleneck: cross-database queries via PostgreSQL Foreign Data Wrappers ran far slower than Oracle's native database links.

Postgres1st's database audit team resolved this with a single architectural call; consolidating all three databases into three schemas within one PostgreSQL instance running Active–Passive–Passive HA (Patroni, etcd, HAProxy, Keepalived).

This eliminated FDW overhead, cut infrastructure to a 3-node cluster plus DR, and avoided further application changes.

Results

Data integrity 100%, checksum validated
Data loss Zero
Post-migration critical issues (72-hr hypercare) Zero
Automatic failover (RTO) < 30 seconds
Data loss on failover (RPO) Zero (synchronous replication)
VIP failover time < 5 seconds
Reports benchmarked for parity 250+

Key Lessons

  • Postgres1st's assessment-first approach (SHOW_REPORT/ESTIMATE_COST plus internal scoping) gave a realistic plan before any code was touched; assess before you migrate.
  • Postgres1st's dual-write methodology with daily checksum reconciliation reduced cutover risk to near zero.
  • Budget 20–30% of total effort for manual PL/SQL rewrite; automation covers 70–80%, the rest needs skilled hands.
  • Map external integrations and negotiate staging access early; lack of staging forced production-based testing.
  • Set up database-native monitoring and backup policies before go-live; storage-level backups aren't a substitute.
back top