Replacing a 20-year-old beneficiary system: build, buy or stabilise first
A district rural development office runs a beneficiary registration system written in 2004 in Visual Basic 6, with an Access 2003 database on a shared folder. Forty clerks across four blocks enter muster rolls and generate 11 statutory reports whose formats the state revises almost every year. The database holds 300,000 beneficiary records and about 2 million transaction rows; the Access file is 1.6 GB and corrupts roughly once a month. Two block offices have only 4 Mbps links with several outages a day, and all four must keep working offline and sync later. The office has two IT staff who know basic .NET, a capital budget of 15 lakh rupees, and a rule that all beneficiary data must stay on servers in India. One vendor offers a SaaS product at 8 lakh per year with per-user pricing and says migration is included. Another offers an on-premise rewrite in nine months for 40 lakh.
1. Recommend a course of action for the next twelve months, with reasons, and state explicitly which options you reject and why.
Read the worked answer
Run three parallel tracks.
Track A (months 0–2) - stabilise. 1.6 GB with 2 million rows is close to the Access 2 GB ceiling, which explains monthly corruption. Move the backend to PostgreSQL on an office Linux server in India and keep the VB6 front end alive through ODBC, or keep Access only as a reporting cache. Add nightly verified backups with 30-day offsite rotation. Cost under 2 lakh, and it removes the corruption risk that could destroy the only copy of beneficiary data.
Track B (months 2–8) - rewrite only what hurts. Build the data-entry screens and the 11 reports as a LAN-hosted web application on PostgreSQL. For the two poor-connectivity blocks, add an offline data-entry module: local SQLite or IndexedDB queue with idempotent sync keys, so a retried muster entry is rejected on merge instead of double-counted. Train the two IT staff on deployment and reporting, not just usage.
Track C - contract for changeability. The state changes report formats annually, so the office must own the reporting layer: source-code and schema escrow, an open database, and a documented report-template mechanism that makes an annual format change a five-day task.
Reject the SaaS - at 40 users over five years it exceeds 40 lakh before customisation, creates per-user lock-in, and puts beneficiary data on a platform whose India residency must be contractually guaranteed and evidenced. Reject the 40 lakh rewrite as the sole plan - it consumes the whole capital budget, leaving nothing for hardware, training or next year's format change.
2. List the three risks you would put before the approving authority, each with a mitigation and an early-warning indicator.
Read the worked answer
1. Data migration integrity (highest). Two million transaction rows with 20 years of legacy validation and no foreign keys. Mitigation: freeze a read-only copy; migrate with a reconciliation report (row counts, sums by block and month, orphan checks); run both systems in parallel for two full monthly cycles; sign-off by the accounts officer, not by IT. Early warning: reconciliation gaps that grow month on month, or a rising count of rejected rows.
2. Vendor lock-in and scope creep. Mitigation: fixed-price contract with a written requirement baseline, a change-control board, source code plus schema plus deployment scripts in escrow, and an exit/transition clause. Early warning: more than 10% of effort consumed by small changes before user acceptance testing, or refusal to hand over the schema.
3. Staff capacity and dual running. Two IT staff cannot support a new stack and the legacy system at once. Mitigation: twelve months of named vendor support, hands-on training, a written runbook, and a rule that the legacy system is retired only after two clean parallel months. Early warning: P1 tickets unresolved beyond 48 hours, or staff unable to restore a backup unaided during a drill.
Presenting these with indicators matters because the authority is approving a plan, not a purchase - each indicator should be reviewed monthly by the same committee that approves the next release.
3. Define measurable acceptance criteria and a cut-over plan with a rollback trigger.
Read the worked answer
Acceptance criteria (measurable, not aspirational):
- Functional: all 11 statutory reports generated in the state-approved format; 100% of migrated beneficiaries reconciled with zero unexplained differences; offline entry accepts 200 records per block and syncs with zero duplicates on replay.
- Performance: muster entry screen responds in under 2 s with 40 concurrent users on the office LAN; nightly batch completes in under 30 minutes.
- Security and operations: role-based access for clerk, supervisor and administrator; audit trail on every edit; an encrypted backup restored successfully in a drill; India-resident hosting evidenced by a certificate from the provider.
- Usability: at least 90% of clerks complete a muster entry unaided after one day of training.
Cut-over: pilot in the block with the lowest transaction volume for one month. Then migrate block by block. Freeze legacy writes at 18:00 on a Friday, run the final delta sync, obtain reconciliation sign-off, and leave the old system read-only for three months.
Rollback trigger, defined before go-live: if reconciliation fails, or more than five P1 defects occur in the first week, revert to the legacy system for data entry and continue using the new system for reporting only. Publish a helpline and run daily defect triage for the first month.
Why: a cut-over without a pre-agreed numeric trigger becomes an argument about blame while clerks are unable to work.