At a glance
2–6 weeks
Typical timeline. 8+ weeks for complex multi-system migrations.
2–4 hours/week
Your time commitment. We tell you upfront if yours requires more.
4–8 hour cutover
Typically a weekend. You choose when.
Your data is verified at every step. Nothing moves forward until verification passes and you approve. If something isn’t right, we fix it before proceeding.
What we can migrate from
We migrate data from scientific platforms including LIMS, ELN, QMS, eBR/MES, and document management systems—as well as spreadsheets, databases, and paper-based processes. During assessment, we evaluate your source system, identify the best extraction method, and document the full migration approach.What we migrate
Records and fields
All records with complete field values, exactly as stored in your source system.
Relationships
Links between records preserved—sample to study, result to sample, document to batch.
Audit trails
Complete change history with timestamps, users, and previous values for every modification.
Electronic signatures
Signer identity, timestamp, and meaning (approved, reviewed, witnessed) all preserved.
Files and attachments
Documents, images, raw data files—everything attached to your records.
User attributions
Who created, modified, or approved each record—including historical users.
How it works
Data migration is part of your Seal implementation. Before migration begins, we configure Seal with your entity types, fields, and workflows — this defines the target structure your data maps into. Configuration and migration planning happen in parallel. See Implementation for the full picture.
- Your system — where your data lives today
- Your data — extracted and permanently retained by Seal in its original form (no action required from you)
- Seal — your data transformed and loaded, goes live when approved
| Step | What happens | What we verify |
|---|---|---|
| Assessment | We profile your data and create the migration plan | Scope, mappings, acceptance criteria agreed |
| Extract | We pull your data and verify completeness | All data captured — record counts, field completeness, file checksums |
| Transform + Load | We transform and load into Seal | Accurate transformation — records, fields, audit trails, signatures |
| UAT + Training | Your team validates and trains on real data in Seal | Your sign-off required to proceed |
| Cutover | Seal goes live | Both stages re-verified |
Every stage is verified before we proceed. If any check doesn’t pass, we resolve it together before moving forward. All migrations use the Seal Migration Tool — qualified, validated tooling with built-in integrity checks, automated reconciliation, and full audit logging.
Assessment and planning (1 week)
We evaluate your source system and profile your data. Together, we define:
- Migration scope — which entities, records, and date ranges to migrate
- Data ownership — who owns the data and approves the migration
- Data mapping — how source fields map to Seal fields
- Transformation rules — any data conversions or restructuring required
- Acceptance criteria — what success looks like for your migration
- Risk mitigations — how we address risks to patient safety, product quality, and data integrity
Extract and verify (3–5 days)
We extract data from your source system in its raw format. Depending on your system, extraction uses:
- API integration — for systems with available APIs (preferred)
- Database export — direct export from your database
- File export — CSV, XML, or vendor-specific export formats
Transform + Load to Seal (3–5 days)
Using the Seal Migration Tool, we transform your extracted data according to your documented data mappings and load it into Seal. Transformations may include:
- Field mapping to Seal schema
- Data type conversions
- Relationship reconstruction
- User and role mapping
User Acceptance Testing and training (1–2 weeks)
Your team reviews the migrated data in Seal. You verify:
- Data completeness and accuracy
- Relationships and hierarchies
- Audit trail integrity
- Business-specific acceptance criteria
Cutover and go-live (4–8 hours)
On the agreed cutover date, we re-run the complete migration process:
- Freeze source system — users stop entering data in the old system
- Delta extraction — capture any new or modified records since the test migration
- Merge and reconcile — combine delta with validated test migration data
- Transform and load — apply the same validated transformation rules and data mappings
- Final verification — run all verification checks
- Cutover — Seal goes live, users switch over
What you provide
We handle the technical work. Your involvement is focused on review and approval.| Your input | Time |
|---|---|
| System access (read-only) | One-time setup |
| Review Data Migration Plan and data mappings | 1–2 hours |
| Define acceptance criteria | 1–2 hours |
| Subject matter expert availability | 2–4 hours/week |
| Review Extraction Verification Report | 30 minutes |
| Review Migration Verification Report | 1 hour |
| User Acceptance Testing and training | 1–2 weeks (a few hours/day) |
| Approval to proceed with cutover | When you’re ready |
Verification and testing
The Seal Migration Tool generates verification reports at each stage, confirming data completeness and integrity before proceeding.Extraction Verification Report
After extraction, we verify that all data has been successfully captured from your source system.| Verification check | How we verify |
|---|---|
| Record counts | Exact match per entity type — source count vs extracted count |
| Field completeness | Every required field present, no truncation or encoding issues |
| File inventory | Every file captured, SHA-256 checksums match source |
| Date range coverage | First and last records match expected scope boundaries |
| Relationship integrity | Foreign keys and links preserved exactly as in source |
How extraction verification works
How extraction verification works
Establishing the baseline: Before extraction begins, we work with you to obtain authoritative record counts and data exports from your source system:
- Database record counts per entity type (samples, results, batches, etc.)
- Complete file/attachment inventory with checksums
- Date range boundaries for the migration scope
- Relationship counts (e.g., “12,000 samples linked to 450 studies”)
Migration Verification Report
After loading into Seal, the Seal Migration Tool runs comprehensive validation comparing your extracted data against Seal—record by record, field by field.| What we verify | What this means |
|---|---|
| Records | Counts match exactly, every record exists, nothing extra |
| Field values | Exact match including nulls, decimals, special characters, dates |
| Relationships | All links preserved (sample→study, result→sample), hierarchies intact |
| Files | Counts match, checksums verified, attached to correct records |
| Audit trails | Complete history, correct order, right users, previous values preserved |
| Signatures | Signer, timestamp, meaning, and record linking all verified |
See detailed validation checks
See detailed validation checks
| What we check | What this means | How we verify it |
|---|---|---|
| Record counts | Total records per entity type match exactly | Count extracted, count Seal, compare |
| Record existence | Every extracted record exists in Seal | Hash all source IDs, verify all present |
| No extra records | Nothing added by mistake | Reverse-check from Seal back to extracted data |
| Field values | Every value matches exactly | Field-by-field comparison, exact string matching for critical fields |
| Null handling | Empty stays empty, null stays null | Explicit null vs empty check |
| Numeric precision | Decimals preserved exactly (3.14159 stays 3.14159) | Compare numbers as strings |
| Text integrity | No truncation or encoding corruption | Length check, character-by-character comparison |
| Date accuracy | Timestamps match to the second | ISO 8601 comparison with timezone |
| Relationships | All links between records preserved | Look up every foreign key |
| Hierarchies | Folder structures and trees intact | Traverse and compare structure |
| File counts | Same files per record | Count attachments, flag differences |
| File integrity | No corruption | SHA-256 checksum comparison |
| File associations | Attached to correct records | Verify parent record IDs |
| Audit entries | Complete history preserved | Count entries per record |
| Audit chronology | Correct order | Timestamp ordering check |
| Audit attribution | Right user for each action | User ID comparison |
| Previous values | Historical values preserved | Verify “changed from X to Y” entries |
| Signature identity | Correct signer | User ID comparison |
| Signature timestamp | Exact time preserved | Timestamp comparison |
| Signature meaning | Approved/reviewed/witnessed preserved | Meaning code comparison |
| Signature linking | Attached to correct records | Record ID verification |
Your acceptance criteria
In addition to our standard checks, we work with you to define custom acceptance criteria specific to your data and business rules—things only you would know to check.Example acceptance criteria
Example acceptance criteria
- “All batch records from 2023 should have a linked deviation or explicit ‘no deviation’ flag”
- “Sample IDs starting with ‘QC-’ must have a corresponding calibration record”
- “Every approved SOP should have at least one training record associated”
- “Stability study samples must have temperature records within ±2°C of target”
- “All released products must have complete analytical COA data”
Final Migration Report
After go-live, we provide a complete Final Migration Report documenting:- Full re-execution of the migration process
- Delta extraction results (new/modified records since test migration)
- Data mappings applied during transformation
- All verification checks repeated against production
- Summary of any data quality observations
- Confirmation that acceptance criteria are met
Sample verification output
Sample verification output
GxP compliance
Our migration process meets the requirements of GMP, GLP, and GCP environments, including 21 CFR Part 11 and EU Annex 11. Locked records stay locked—approved or released records in your source system remain locked in Seal. All user attributions preserved, original timestamps maintained, and complete source data retained in secure cloud storage.Source data preserved
Complete copy retained in secure cloud storage for the duration of our relationship.
You stay in control
You decide when to go live. Your current system keeps running until you approve.
Dedicated support
Priority access to our migration team after go-live for any questions.
Supporting your validation process
Our migration deliverables are designed to support your internal validation and change management processes.Details for your QA team
Details for your QA team
Documentation we provide
| Your requirement | Our deliverable |
|---|---|
| Data Requirement Specification (DRS) | Data Migration Plan — includes data scope, field mappings, transformation rules, data ownership, and acceptance criteria |
| Data Migration Strategy | Data Migration Plan — includes objectives, technical approach, extraction method, tools, and timeline |
| Data Migration Test Plan | Test Plan section within Data Migration Plan — describes verification checks, test data, and pass/fail criteria |
| Data Migration Test Report | Extraction Verification Report + Migration Verification Report + Final Migration Report — documents all test execution and results |
Risk assessment
Our migration process addresses risks to:- Patient safety — data integrity checks ensure no corruption or loss of safety-critical data
- Product quality — complete audit trails and electronic signatures preserved
- Data integrity — ALCOA+ principles (Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, Available) maintained, verified through automated reconciliation
Traceability
All migration requirements are traceable from definition through to test execution and results. The Data Migration Plan defines requirements and test criteria; verification reports document execution and confirm requirements are met.Leveraging supplier documentation
Our documentation can be leveraged to support your validation activities, subject to your supplier quality assessment. We provide:- Seal Migration Tool qualification documentation
- Standard Operating Procedures for migration execution
- Evidence of tool validation and change control
Change management
Data migration is typically managed through your change control system. We support this by providing documentation suitable for your change request, including:- Impact assessment inputs
- Risk assessment inputs
- Test protocols and results
- Approval checkpoints aligned with your workflow
Common questions
What if our data has quality issues?
What if our data has quality issues?
We profile your data during assessment and identify quality issues upfront. You decide how to handle them—clean before migration, document and migrate as-is, or exclude. All decisions are documented.
What about data entered during the migration period?
What about data entered during the migration period?
We capture it. The cutover migration includes a delta extraction that captures all new and modified records since the test migration. Nothing is lost.
What happens during cutover?
What happens during cutover?
On cutover day, users stop entering data in your old system. We extract any data entered since the test migration (the delta), backfill it into Seal, run final verification, and switch you over—typically within 4–8 hours. Your old system stays available read-only for reference.
Can we train users before go-live?
Can we train users before go-live?
Yes—this is the recommended approach. During UAT, your team uses Seal with your real migrated data. Training on familiar data is far more effective than dummy examples. Any data entered in your source system during training is captured in the delta extraction at cutover.
What about historical users or former employees?
What about historical users or former employees?
Historical records keep their original attribution. Audit trails always show who actually performed the action, regardless of current employment status.
Can we exclude certain data?
Can we exclude certain data?
Yes. Migration scope is defined during assessment—we document exactly what is included and excluded in the Data Migration Plan.
What if we have trouble getting data from our current provider?
What if we have trouble getting data from our current provider?
There are usually multiple extraction methods available—APIs, database exports, or standard file exports. We work with you to find the smoothest path and can coordinate with your provider if helpful.
Why do you extract data before transforming it?
Why do you extract data before transforming it?
Extracting your data in raw format first allows us to verify completeness before any transformation. This provides a clear checkpoint—if something is missing, we identify it at extraction, not after transformation. Your extracted data also serves as a permanent reference during verification and beyond.
What happens to our original source data?
What happens to our original source data?
We retain a complete copy of your original source data in secure cloud storage for the entire duration of our relationship. This means you always have access to your historical data exactly as it existed in your previous system—useful for audits, regulatory queries, or any future reference needs.
What if something goes wrong after cutover?
What if something goes wrong after cutover?
Your previous system remains available read-only after cutover. If a critical issue is discovered, we can extend this period while we investigate. The complete source data we retain means we can re-run or correct any part of the migration if needed.
What happens to in-flight work?
What happens to in-flight work?
Experiments, runs, or other work in progress are handled during assessment. Most customers complete in-flight work in the old system before cutover—we time the migration accordingly. If needed, we can support multiple cutover phases (e.g., migrate completed work first, then in-progress work later), though we recommend a single cutover when possible for simplicity. The approach is documented in the Data Migration Plan.
Will our historical data be interactive in Seal?
Will our historical data be interactive in Seal?
Yes. We migrate historical data as structured, interactive records—fully searchable, filterable, and viewable in familiar layouts. Your team works with past data the same way they work with new data. If you have legacy data that’s purely archival, we can store it as reference files instead. We define this during scoping.