Leave a comment at the end of this page or email contact@krishagni.com
OpenSpecimen Migration Strategy & Cutover Plan Document
Introduction
Krishagni will work with the customer’s team to migrate legacy data into OpenSpecimen. This document outlines the migration strategy, environment setup, testing workflow, and cutover procedures.
The process involves the following key steps:
Mapping legacy data to OpenSpecimen fields
Creating new fields and forms as needed
Writing and executing scripts to migrate data into the Test environment
Data validation and bug fixes
Customer sign-off
Final migration of data into the Production environment
This document outlines the detailed execution steps and project deliverables for each phase.
Roles and Responsibilities
Role | Owner | Description |
Project Manager | Krishagni & Customer | Oversees project timeline, coordinates resource allocation, tracks milestones, and manages overall execution across both teams. |
Data Manager | Customer | Serves as the primary SME with in-depth knowledge of the legacy database structure; assists Krishagni with field mapping, business rules, and data validation. |
OpenSpecimen Product Expert | Krishagni | Leads data mapping to OpenSpecimen models, configures custom forms/fields, designs test plans, and performs baseline validation. |
ETL Developer | Krishagni | Writes, tests, and executes data extraction, transformation, and loading (ETL) scripts for both Test and Production environments. |
System Administrator | Customer / Krishagni | Ensures database access, server provisioning, environment availability, and security compliance for target instances. |
Lead Validator / UAT Lead | Customer | Conducts end-user acceptance testing, verifies data fidelity in the Test environment, and signs off on production readiness. |
Note: Same team members may fulfill multiple roles depending on project allocation.
Environments Used
Environment | Purpose & Scope |
Non-Production
| Used for initial ETL script testing, data mapping verification, user acceptance testing (UAT), bug fixes, and dry-run cutover timing. Customer sign-off is conducted in this environment prior to production execution. |
Production | The live, secure environment designated for final cutover migration, post-migration verification, and operational handoff. |
Migration Approach
Krishagni manages the data migration using a “staged snapshot strategy” to ensure minimal disruption to clinical or laboratory operations.
The staged snapshot strategy executes data migration in two rounds to maintain uninterrupted laboratory operations:
Test Migration: A complete snapshot of the legacy production database is extracted to build, refine, and validate ETL scripts in a non-production environment while day-to-day operations continue on the live legacy system.
Final Migration: Once test data is validated and signed off, a fresh full snapshot is taken during a scheduled cutover window for final go-live loading into Production.
Execution Plan
Initial Snapshot & Test Migration
A full snapshot of the legacy production database is extracted at project kickoff.
Krishagni develops and executes the ETL scripts to transform and load this snapshot into the Non-Production (Test) environment.
Data Validation
Krishagni and Customer stakeholders audit and validate the transformed data in the Test environment.
During this review period, day-to-day operations continue without interruption on the legacy system.
Customer Sign-Off
Once all data discrepancies and bug fixes are resolved in the Test environment, the customer provides written acceptance and sign-off to authorize production cutover.
Production Cutover & Legacy Freeze
At the agreed cutover time, the customer halts all data entry and transitions the legacy system to read-only status (or shuts it down) to prevent stray or duplicate entries.
A final, full production snapshot (or delta extract) is pulled from the legacy database for go-live loading.
Production Migration & Go-Live
Krishagni loads the final dataset into the Production OpenSpecimen instance and performs automated record verification.
Following post-migration spot-checks, OpenSpecimen is opened for primary live operations.
Downtime & Cutover Scheduling
To minimize impact on customer operations, production cutover is typically scheduled over a weekend. Depending on database size and complexity, an additional day (Friday or Monday, per customer preference) may be requested to allow sufficient buffer for final data loading and verification.
Data Migration Activities & Deliverables
Activity | Deliverables & Prerequisites | Timeframe |
Data Dictionary Mapping | Deliverable: Excel mapping document linking legacy database attributes to OpenSpecimen standard and custom fields. Prerequisite: Customer provides data dictionary (column names, descriptions) and legacy production database in CSV format. | 1–2 weeks |
Data Mapping Sign-Off | Deliverable: Formal written sign-off on field mapping specifications from the customer. | 1 week |
ETL Scripting & Iterative Testing | Deliverable: Automated ETL migration scripts. Execution: Performed in logical phases (e.g., Freezers/Storage, Containers, Participants/Patients, Specimens, Events). Script refinement is managed iteratively with periodic sample data updates available for intermediate review. | 4–8 weeks |
System Configurations | Deliverable: Configured custom fields, forms, biobank workflows, and container/freezer hierarchies built in parallel with ETL scripting. | 1–2 weeks |
Full Test Migration (Dry Run) | Deliverable: Full historical data load into the Test/Staging environment, serving as a rehearsal to validate script accuracy and estimate go-live execution time. | 2–3 weeks |
Test Data Validation & Sign-Off | Deliverable: Completed UAT feedback log and formal customer sign-off authorizing production cutover. | 1–2 weeks |
Go-Live: Production Configurations | Deliverable: Migration and verification of all approved configurations, custom forms, and workflows to the Production server prior to the cutover window. | Pre-Cutover |
Go-Live: Legacy Data Freeze & Snapshot | Deliverable: Final, clean extract of legacy database; customer transitions legacy system to read-only/shutdown status to prevent new data entry. | Cutover Weekend |
Go-Live: Production Data Ingestion | Deliverable: Full production data load, accompanied by reconciliation reports (Record Count Match Report, Failure/Exception Log, and Smoke Testing Results). | Cutover Weekend |
Go-Live: Handover & Verification | Deliverable: Production environment handed over to the customer for final spot-checks and operational go-live authorization. | Cutover Weekend |
Validation Scope & Test Cases
Data validation is a joint responsibility between Krishagni and the customer team to ensure complete data fidelity, structural integrity, and system readiness.
Both teams will create, execute, and document structured Test Cases (TCs)—each tagged with unique TC IDs, step-by-step instructions, and expected results—in close collaboration with Krishagni.
Validation Category | Focus Areas & Objectives | Responsible Party |
Count-Based / Completeness | Verification of overall record totals (e.g., total participants, visits, specimens, containers) comparing source legacy counts against OpenSpecimen database counts using Krishagni-generated reconciliation reports. | Joint (Krishagni report / Customer sign-off) |
Field-Level Integrity | Verification that field mapping, data types, mandatory vs. optional rules, and field formatting (e.g., date formats, barcode strings) are correctly enforced in target forms. | Customer Lead |
Value & Data Comparison | Spot-checks and systematic comparisons of critical legacy attributes against target records, specifically focused on specimen labels, specimen types, quantities, collection dates, and physical storage coordinates. | Customer Lead |
Functional & Operational | Operational testing of day-to-day biobanking workflows in OpenSpecimen using migrated records (e.g., specimen search, query builder reports, specimen check-in/check-out, derivative creation). | Customer Lead |
User Access & Security | Verification that user roles, site-level restrictions, collection protocol privileges, and administrative permissions are correctly applied. | Joint (Krishagni config / Customer testing) |
Bug Reporting & Remediation Cycle
Any discrepancies, failed test cases, or data anomalies identified during testing are logged with the corresponding TC ID, description, and example records.
Krishagni investigates, updates ETL scripts or form configurations, and re-migrates affected record sets into the Test environment.
The customer re-executes the failed test cases to verify remediation prior to final sign-off.
Cutover Plan
The production cutover represents the final transition phase. To minimize disruption to the biobank’s operations, cutover execution is conducted over a scheduled weekend window following formal UAT sign-off.
Final Extraction & Lock: Customer extracts final legacy snapshot and sets the legacy system to read-only.
Data Load: Krishagni runs validated ETL scripts to load historical and delta records into Production.
Production Verification:
Krishagni: Performs record-count matching, exception log review, and application smoke testing.
Customer: Conducts spot-checks on critical records, storage hierarchies, and workflows.
Post-Cutover Support: Krishagni provides dedicated monitoring during the initial go-live window. Minor display/configuration fixes are applied in-place; critical issues trigger escalation.
Formal Go-Live: Customer leadership provides written acceptance confirming successful deployment.
Rollback Strategy
Scope: Applies only to OpenSpecimen Production. Legacy customer systems remain intact in read-only/backup status.
Triggers: Unresolved high-severity issues (data corruption, missing entities, script failures) that cannot be patched within the cutover window.
Execution:
Existing OpenSpecimen Deployments: Production database is restored to the pre-migration backup taken immediately before cutover.
New OpenSpecimen Deployments: Database schema is wiped and re-initialized to a clean state.
Next Steps: Legacy read-only locks are released if needed for ongoing operations. Issues are fixed and re-tested in DEV before rescheduling the production cutover.