Post Phase of Migrating from On-Prem Oracle to MongoDB on Azure VM

AFTER Migration — Banking Systems, Compliance, HADR, Backup & Monitoring

Now you have completed the hardest part—moving data.

But in banking systems, the real work starts after migration.

If you stop here, your system may:

Lose data
Fail audits
Perform poorly
Violate regulations

This part will make your system production-ready, audit-ready, and disaster-ready.

1. Immediate Post-Migration Checklist (First 24 Hours)

Right after cutover:

1.1 Verify System Stability

Check:

Application connectivity
Query performance
Error logs

MongoDB check:

db.runCommand({ connectionStatus: 1 })

1.2 Reconcile Financial Data (CRITICAL)

You MUST confirm:

Total balances match Oracle
Total transactions match Oracle

db.transactions.aggregate([
  { $group: { _id: null, total: { $sum: "$amount" } } }
])

If mismatch → STOP system immediately

1.3 Monitor for Silent Failures

Silent failures are dangerous in banking:

Missing transactions
Partial inserts
Delayed writes

Check logs:

tail -f /var/log/mongodb/mongod.log

2. Backup Strategy

If you don’t have backup, you don’t have a system.

2.1 Types of Backups

You must implement:

Full backup (weekly)
Incremental backup (daily)
Point-in-time recovery (critical)

2.2 MongoDB Backup (mongodump)

mongodump \
--host rs0/primary:27017 \
--out /backup/full_$(date +%F)

2.3 Restore (mongorestore)

mongorestore \
--host rs0/primary:27017 \
/backup/full_2026-05-01

2.4 Automate Backup (Cron Job)

crontab -e

Add:

0 2 * * * mongodump --out /backup/daily

2.5 Azure Backup Integration (Free Tier Options)

Use Azure Blob Storage
Upload backups:

az storage blob upload-batch \
--destination backups \
--source /backup

Always store backups:

On different disk
In different region (disaster recovery)

3. High Availability & Disaster Recovery (HADR Advanced)

3.1 Replica Set Review

You already created:

Primary
Secondary nodes

Check status:

rs.status()

3.2 Add Arbiter (Optional but Useful)

rs.addArb("arbiter:27017")

Helps in elections without extra storage

3.3 Cross-Region Disaster Recovery

For banking systems:

Region 1 → Primary
Region 2 → Secondary

If region fails:

System continues automatically

3.4 Sharding (For 100TB Databases)

Replica set is not enough for huge banking systems.

You must use sharding.

Enable sharding:

sh.enableSharding("banking")
sh.shardCollection("banking.transactions", { "account_id": 1 })

Benefits:

Horizontal scaling
Faster queries
Handles 100TB+ data

4. Performance Tuning (Banking Workloads)

4.1 Create Indexes (Very Important)

db.transactions.createIndex({ account_id: 1 })
db.transactions.createIndex({ txn_date: 1 })

Without indexes:

Queries become extremely slow

4.2 Query Optimization

Bad query:

db.transactions.find({ amount: { $gt: 1000 } })

Better:

db.transactions.find(
  { amount: { $gt: 1000 } },
  { account_id: 1, amount: 1 }
)

4.3 Connection Pooling

In application:

Use connection pools
Avoid opening new connections per request

5. Monitoring & Alerting (Must Have)

5.1 Basic Monitoring Commands

db.serverStatus()

5.2 Key Metrics to Monitor

CPU usage
Memory usage
Disk I/O
Replication lag
Query latency

5.3 Free Monitoring Tools

MongoDB built-in tools
Azure Monitor (free tier)
Log Analytics

5.4 Alert Example

Trigger alert if:

Disk > 80%
Replication lag > 5 seconds

6. Security Hardening (Banking Grade)

6.1 Enable Authentication

use admin
db.createUser({
  user: "secureAdmin",
  pwd: "StrongPassword123!",
  roles: ["root"]
})

6.2 Enable Encryption at Rest

Use:

Azure Disk Encryption

6.3 Enable TLS Encryption

net:
  tls:
    mode: requireTLS

7. US Central Banking Regulatory Compliance Checklist

This is simplified but practical.

7.1 Key Regulatory Bodies

Federal Reserve (Fed)
OCC (Office of the Comptroller of the Currency)
FDIC

7.2 Core Requirements

Data Integrity

✔ No data loss
✔ Accurate transaction records

Auditability

✔ Full audit logs
✔ Trace every transaction

Data Retention

✔ Keep financial data for 5–7 years

Access Control

✔ Role-based access (RBAC)

db.createRole({
  role: "readOnlyAuditor",
  privileges: [],
  roles: [{ role: "read", db: "banking" }]
})

Incident Response

✔ Documented recovery procedures
✔ Breach reporting process

8. PCI-DSS Compliance (VERY IMPORTANT)

If your system handles card payments, this is mandatory.

8.1 PCI-DSS Key Requirements

Requirement 1: Secure Network

✔ Firewall enabled
✔ No public DB access

Requirement 2: Protect Card Data

✔ Mask card numbers

{ "card": "XXXX-XXXX-XXXX-1234" }

Requirement 3: Encryption

✔ Encrypt data at rest
✔ Encrypt data in transit

Requirement 4: Access Control

✔ Unique user IDs
✔ No shared accounts

Requirement 5: Logging & Monitoring

✔ Log every access

db.setProfilingLevel(2)

Requirement 6: Vulnerability Management

✔ Regular patching
✔ Security scans

Requirement 7: Restrict Access

✔ Least privilege principle

9. Cost Optimization on Azure

9.1 Reduce Storage Costs

Use tiered storage
Archive old data

9.2 Auto Shutdown (Non-Production)

az vm auto-shutdown

10. Real Production Runbook

10.1 Daily Tasks

Check logs
Verify backups
Monitor performance

10.2 Weekly Tasks

Full backup
Index optimization
Security review

10.3 Monthly Tasks

Disaster recovery test
Compliance audit
Cost review

11. Real Disaster Scenario (Banking Example)

Scenario:

Primary node crashes during peak transactions

What Happens:

Secondary becomes primary automatically

Your Action:

rs.status()

✔ Verify failover
✔ Check data consistency

12. Final Advice (Very Important)

For banking systems:

Always assume failure will happen
Always design for recovery
Always validate financial data

Wednesday, May 13, 2026