Data Migration Strategy & Execution

February 2026 · 18 min

Why Data Migration Is the Riskiest Phase

Data migration is where most ERP implementations fail silently. The system works perfectly in testing with clean test data, but collapses on go-live day when real-world dirty data flows in.

Common data quality issues in Indian hospitals:

• Patient records with no phone number or invalid phone numbers
• Duplicate patients (same person registered multiple times with different MRNs)
• Drug names with inconsistent spelling (Paracetamol vs Paracetmol vs PCM)
• Service charges with no department mapping
• Insurance panels with expired agreements
• Employee records with missing joining dates or role assignments

Migration Scope Assessment

First, decide what gets migrated and what starts fresh:

Key principle: Migrate the minimum data needed for the new system to function on day one. Legacy data can remain accessible in the old system (read-only) for reference.

The 5-Step Migration Process

Follow this systematic process:

1. Extract -- Pull data from the source system (old ERP database, Excel files, paper registers that need manual entry). Export as CSV/Excel
2. Cleanse -- Fix data quality issues: remove duplicates, fill missing mandatory fields, standardize formats, validate against reference data
3. Transform -- Map source fields to Bio Ecko target fields. Convert data types, units, codes. Generate any derived fields
4. Load -- Import into Bio Ecko staging environment using the admin import tools or database scripts
5. Validate -- Compare source record counts with loaded counts. Spot-check 10% of records for accuracy. Get stakeholder sign-off

Each step should be documented with:

• Input (source file/table)
• Transformation rules applied
• Output (target table in Bio Ecko)
• Record counts (source vs loaded vs rejected)
• Rejection reasons and resolution

Patient Data Cleansing Rules

Patient master is usually the messiest dataset. Apply these cleansing rules:

• Phone Number: Must be 10 digits (Indian mobile). Remove +91 prefix, spaces, dashes. If missing, flag for manual update
• Name Standardization: Title case (Rajesh Kumar, not RAJESH KUMAR). Remove extra spaces. Split first/last name correctly
• Aadhaar: Validate 12-digit format with Verhoeff checksum. Mask in storage (show only last 4 digits)
• Date of Birth: Standardize to YYYY-MM-DD. Flag impossible dates (future dates, age > 120). For unknown DOB, use estimated year of birth
• Gender: Map to M/F/O (Other). Resolve inconsistencies
• Duplicate Detection: Match on Phone + Name (fuzzy) + DOB. Flag potential duplicates for manual review by hospital staff
• Address: Standardize pincode (6 digits). City and state should come from pincode lookup

Approach for duplicate resolution:

• Export potential duplicate pairs with similarity score
• Hospital's MRD (Medical Records Department) reviews and decides which to merge
• Merge operation preserves all visit history under the surviving MRN
• Deprecated MRN redirects to surviving MRN (alias mapping)

Drug Master Migration

The drug master requires special attention because errors here directly impact patient safety:

1. Source Data: Export from old system or compile from hospital's formulary book
2. Standardization: Map every drug to its INN (International Nonproprietary Name) generic name. Use the WHO INN database as reference
3. Strength Validation: Ensure numeric consistency -- 500mg, not 500 mg, not 0.5g, not 500MG
4. Schedule Assignment: Cross-reference with DDA (Drug and Drug Administration) schedule classification. Every drug must have the correct H/H1/X/G schedule
5. Formulation Coding: Standardize to a fixed list: Tablet, Capsule, Syrup, Injection, Cream, Ointment, Drops, Inhaler, Suppository, Patch, etc.
6. Reorder Levels: If not available from old system, use consumption-based calculation: average monthly consumption x 1.5 as reorder level
7. Batch and Expiry: For opening stock, every item must have batch number and expiry date. Items without expiry data cannot be loaded

Opening Stock Migration

For pharmacy and central store, opening stock must be loaded with:

• Drug/Item reference (must already exist in drug master)
• Batch number
• Expiry date
• Quantity on hand
• Purchase price per unit
• MRP (Maximum Retail Price)
• Storage location (which pharmacy/store)

The FC must coordinate a physical stock count at the hospital before cutover:

1. Schedule the count on a weekend or low-volume day
2. Hospital pharmacy staff counts all items physically
3. Compare physical count with old system balance
4. Resolve variances (stock adjustments in old system)
5. Use the verified count as the opening stock for Bio Ecko
6. Load into Bio Ecko staging, verify totals match
7. On go-live day, any stock movement between count date and go-live must be manually adjusted

This is non-negotiable. Going live with inaccurate opening stock means every subsequent stock report will be wrong.

Migration Testing & Validation

Never trust the data just because the import succeeded. Validate at multiple levels:

1. Record Count Validation -- Source count == Loaded count + Rejected count. No records lost
2. Field-Level Spot Check -- Randomly pick 50 patient records, 30 drug records, 20 service records. Compare every field between source and Bio Ecko. Flag discrepancies
3. Referential Integrity -- Every patient should have a valid branch. Every drug should have a valid category. Every user should have a valid role
4. Business Logic Validation -- Run key reports in Bio Ecko with migrated data:

• Patient count by registration year should match historical trends
• Drug master should have no orphan entries (items with no category)
• Service charge total should match hospital's published tariff book

5. User Validation -- Ask 2-3 hospital staff to look up their known patients, verify the data is correct
6. Sign-Off -- Formal sign-off from the hospital's data owner (MRD Head for patients, Chief Pharmacist for drugs, Finance Head for financial data)

Cutover Planning

The cutover is the critical window between stopping the old system and starting Bio Ecko:

Always have a rollback plan: If the Go/No-Go decision is No-Go, the old system continues as before. Bio Ecko data is wiped and re-migrated in the next window. This is why you never decommission the old system until after hypercare.

Notes

Related topics