Mapping Legacy Respiratory Database Schemas to Modern Cloud Platforms: A Field Guide to Data Normalization and Format Reconciliation

Feb 20, 2026

Moving respiratory data from a legacy system to a modern cloud platform is a well-understood process when approached with the right framework. The core challenge is not the migration itself but the translation work: reconciling mismatched schemas, normalizing proprietary data formats, and ensuring that decades of patient records arrive intact and clinically usable on the other side. Done correctly, the transition improves data quality, eliminates redundancy, and positions a respiratory lab for long-term scalability.

TL;DR

  • Legacy respiratory databases store data in fragmented, proprietary formats that require deliberate schema mapping before migration.

  • Data normalization and format reconciliation are the highest-risk steps and deserve the most planning time.

  • A phased, validated migration approach minimizes downtime and protects data integrity.

  • Cloud platforms offer significant advantages for respiratory labs: better interoperability, remote access, and reduced IT overhead.

  • Switching from a legacy system like Respiro to a modern platform like Rezibase is designed to be straightforward, not disruptive.

What Is Schema Mapping in the Context of Respiratory Databases?

Schema mapping is the process of defining how data fields in a source database correspond to fields in a target database. In respiratory informatics, this means translating legacy tables storing spirometry results, flow-volume loop data, sleep study outputs, and patient demographics into the structured, standardized format required by a modern cloud platform.

Legacy respiratory systems often grew organically over years, accumulating inconsistent field naming, redundant tables, and non-standard units. A field labeled FVC_litres in one system might be fvc_l or simply fvc in another. Without explicit mapping documentation, automated migration tools will either fail silently or produce corrupted records.

According to Ispirer, best practices for migrating legacy healthcare applications specifically highlight database schema migration and integration risks as the primary technical challenges to address before any data movement begins.

Why Do Legacy Respiratory Systems Create Data Normalization Problems?

Legacy systems create normalization problems for a predictable set of reasons:

  • Vendor-specific data models: Many respiratory reporting systems were built by device manufacturers, meaning the database schema was designed to serve the machine, not interoperability.

  • Inconsistent units and reference ranges: Predicted normal values may be stored as raw numbers without the reference equation used to calculate them, making retrospective reconciliation difficult.

  • Mixed data types: Numeric results stored as strings, dates in multiple formats, and free-text clinical notes embedded in structured fields are common.

  • No audit trail: Older systems rarely logged who entered or modified a result, which complicates data governance during migration.

As ThoughtSpot notes, data migration requires maintaining accuracy and integrity throughout the process, not just at the point of transfer. For respiratory labs, where a single mismatched predicted value can affect clinical interpretation, this standard is non-negotiable.

What Are the Core Steps for Mapping a Legacy Respiratory Schema?

A structured mapping process reduces risk and creates an auditable record of every decision made during migration.

Step 1: Audit the source system

Catalogue every table, field, data type, and relationship in the legacy database. Document which fields are actively used versus legacy artifacts. Evinent recommends starting modernization with a comprehensive audit of existing systems, including codebases and data structures, before any transformation work begins.

Step 2: Define the target schema

Understand exactly how the destination platform structures its data. For respiratory platforms, this includes how spirometry parameters, DLCO results, sleep indices, and patient identifiers are stored and related.

Step 3: Build the field-level mapping document

Create a table that maps every source field to its target equivalent. Include:

Source Field

Source Type

Target Field

Target Type

Transformation Required

FVC_litres

VARCHAR

fvc

DECIMAL(5,2)

Cast to numeric, validate range

DOB

DD/MM/YYYY

date_of_birth

ISO 8601

Reformat date string

pred_FEV1

FLOAT

predicted_fev1

DECIMAL(5,2)

Verify reference equation

study_date

INT (YYYYMMDD)

study_date

DATE

Convert integer to date

Step 4: Identify and resolve conflicts

Flag fields where the source and target definitions conflict. Common conflicts in respiratory data include different normal value libraries, different ATS guideline versions used for interpretation, and proprietary severity grading scales.

Step 5: Validate with a test migration

Run a subset of records through the migration pipeline and compare source and target outputs manually. Discrepancies at this stage are far cheaper to fix than post-go-live.

How Should Format Reconciliation Be Handled for Respiratory Data?

Format reconciliation addresses the structural differences between how data is stored, not just what it means. For respiratory databases, the most common reconciliation challenges are:

  • Flow-volume loop data: Often stored as binary blobs or proprietary waveform formats. Modern platforms need these extracted into discrete, queryable data points.

  • PDF reports embedded in databases: Legacy systems frequently stored the final report as a PDF rather than discrete fields. Migrating these requires either OCR extraction or accepting that historical data will be read-only.

  • Device-specific output files: Each spirometry or sleep device manufacturer produces its own output format. A vendor-neutral platform needs a reliable import layer to normalize these into a common schema.

  • Date and time formats: Inconsistent timezone handling and date format conventions (DD/MM/YYYY vs. MM/DD/YYYY) are a frequent source of silent errors.

According to Astera, schema mappings between source and target must be documented and validated before any live migration begins. This is especially relevant for respiratory data where format errors can affect the clinical usability of historical records.

What Does a Safe, Low-Disruption Migration Actually Look Like?

The goal of any migration from a legacy respiratory system is continuity of care. A phased approach achieves this.

Tactionsoft outlines a practical framework for healthcare data migration that covers data mapping, compliance, and integration, emphasizing that a structured, step-by-step process is what separates a smooth cutover from a disruptive one.

A practical phased approach looks like this:

  1. Discovery and audit (weeks 1-2): Document the source schema, data volumes, and active vs. archived records.

  2. Mapping and transformation design (weeks 2-4): Build the field mapping document and write transformation logic.

  3. Test migration (weeks 4-5): Migrate a representative sample and validate outputs.

  4. Parallel run (weeks 5-6): Operate both systems simultaneously, comparing outputs in real time.

  5. Cutover and decommission: Switch fully to the new platform once validation is complete.

For labs switching from Respiro to Rezibase, this process is supported directly. The migration is designed to be straightforward, with data import tools built to handle the realities of existing respiratory data formats rather than requiring labs to clean everything manually before they start.

Frequently Asked Questions

Will historical patient data be preserved after migration?
Yes. A properly executed migration preserves all historical records. The key is thorough schema mapping before data movement begins.

How long does a respiratory database migration typically take?
For most lab sizes, a structured migration takes four to eight weeks from audit to cutover, depending on data volume and legacy system complexity.

What happens to flow-volume loop data during migration?
Flow-volume loop data requires specific handling. Platforms like Rezibase use tools such as Magic Import to extract discrete data from device reports, including waveform data, into a structured format.

Is data migration HIPAA and privacy compliant?
Compliance depends on how the migration is executed. Encrypted transfer, access controls, and audit logging are standard requirements. Cloud platforms with healthcare-grade infrastructure handle this by design.

Do we need to clean our data before migrating?
Basic validation is recommended, but you do not need a perfect dataset before starting. Most issues are identified and resolved during the test migration phase.

What if our legacy system uses non-standard normal values?
This is common. During schema mapping, the reference equations used for predicted values should be documented and reconciled with the normal values library in the target platform.

Can we keep using our existing devices after switching platforms?
Yes. A vendor-neutral platform like Rezibase is manufacturer-agnostic, meaning it accepts data from any device, regardless of brand.

About Rezibase

Rezibase is Australia's most advanced cloud-based respiratory and sleep reporting platform, built by respiratory scientists for respiratory scientists. Trusted by over 35 sites including NHS trusts in the UK and NSW Health in Australia, Rezibase delivers a vendor-neutral, fully integrated solution covering reporting, accreditation, administration, and device data import with no lock-in contracts and a 30-day free trial. Learn more at rezibase.com.

References

Interoperability Maturity Models for Clinical Physiology Departments: Assessing Where Your Respiratory Lab Falls on the Integration Spectrum in 2026 ›

Interoperability Maturity Models for Clinical Physiology Departments: Assessing Where Your Respiratory Lab Falls on the Integration Spectrum in 2026 ›