> ## Documentation Index
> Fetch the complete documentation index at: https://seal-d2ca5bea.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Migration
> How we migrate your historical data from existing systems into Seal.
## At a glance
Typical timeline. 8+ weeks for complex multi-system migrations.
Your time commitment. We tell you upfront if yours requires more.
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
All records with complete field values, exactly as stored in your source system.
Links between records preserved—sample to study, result to sample, document to batch.
Complete change history with timestamps, users, and previous values for every modification.
Signer identity, timestamp, and meaning (approved, reviewed, witnessed) all preserved.
Documents, images, raw data files—everything attached to your records.
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](/validation/implementation) for the full picture.
Your data moves through three locations, with verification at each step:
1. **Your system** — where your data lives today
2. **Your data** — extracted and permanently retained by Seal in its original form (no action required from you)
3. **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.
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
You'll receive a **Data Migration Plan** covering objectives, scope, data mappings, transformation rules, technical approach, test criteria, and timeline.
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
Your data is preserved without transformation, exactly as it exists in your source.
**Extraction Verification Report:** We compare record counts, field completeness, and file inventories between your source system and your extracted data. This confirms we have captured all data before any transformation occurs.
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
**Migration Verification Report:** The Seal Migration Tool runs comprehensive validation comparing your extracted data against Seal—record by record, field by field. Every check must pass before we proceed.
Your team reviews the migrated data in Seal. You verify:
* Data completeness and accuracy
* Relationships and hierarchies
* Audit trail integrity
* Business-specific acceptance criteria
This is also the ideal time for **user training**—your team learns Seal using your own real data, not dummy examples. We resolve any issues identified. Only once you are satisfied do we proceed to cutover.
On the agreed cutover date, we re-run the complete migration process:
1. **Freeze source system** — users stop entering data in the old system
2. **Delta extraction** — capture any new or modified records since the test migration
3. **Merge and reconcile** — combine delta with validated test migration data
4. **Transform and load** — apply the same validated transformation rules and data mappings
5. **Final verification** — run all verification checks
6. **Cutover** — Seal goes live, users switch over
**Final Migration Report:** Documents the complete production migration with verification results. Your previous system remains available read-only for reference.
## 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 |
If your migration requires more involvement, we identify this during assessment.
## 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 |
You receive the full verification report showing source vs extracted counts for every entity type. We proceed only after you confirm the extraction is complete.
**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")
**Automated comparison:** The Seal Migration Tool runs a comprehensive comparison between your source baseline and your extracted data. Every record is accounted for — we flag any discrepancy, whether missing records, extra records, or count mismatches.
**If discrepancies are found:** We investigate immediately. Common causes include in-flight data changes, permission issues, or API pagination limits — all resolvable. We re-extract and re-verify until counts match exactly.
**Your review:** You can cross-reference against your source system UI or run your own queries to validate counts.
### 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 |
Every check must pass before we proceed to User Acceptance Testing. You receive the full results.
| 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.
* "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"
We document these criteria together, execute them as part of testing, and include the results in your verification reports.
### 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
This report becomes part of your validation documentation package.
```
EXTRACTION VERIFICATION
─────────────────────────────────────────────
✓ Samples Source: 24,891 | Intermediate: 24,891
✓ Results Source: 156,420 | Intermediate: 156,420
✓ Attachments Source: 8,547 | Intermediate: 8,547
✓ All entity types extracted successfully
MIGRATION VERIFICATION
─────────────────────────────────────────────
✓ Samples Intermediate: 24,891 | Seal: 24,891
✓ Results Intermediate: 156,420 | Seal: 156,420
✓ 1,247,832 field values compared — 0 mismatches
✓ 8,547 files verified — checksums match
✓ 892,341 audit entries preserved
✓ All acceptance criteria passed
```
## 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.
Complete copy retained in secure cloud storage for the duration of our relationship.
You decide when to go live. Your current system keeps running until you approve.
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.
### 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
Risk mitigations are documented in the Data Migration Plan and verified through testing.
### 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
This allows you to focus your testing on intended use and acceptance criteria rather than duplicating tool qualification.
### 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
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.
We capture it. The cutover migration includes a delta extraction that captures all new and modified records since the test migration. Nothing is lost.
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.
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.
Historical records keep their original attribution. Audit trails always show who actually performed the action, regardless of current employment status.
Yes. Migration scope is defined during assessment—we document exactly what is included and excluded in the Data Migration Plan.
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.
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.
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.
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.
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.
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.
**Ready to get started?** We begin with an assessment to understand your current system. After one week, you'll have a Data Migration Plan with defined scope and timeline.