What Are Multivalue Databases and How Do You Approach Legacy Data Migration?
Multivalue databases store several values inside a single field or record, so related data that would need multiple tables and joins in a relational database can sit together in one record. That design is why they remain fast and compact for certain business applications, and also why moving them to a modern platform takes planning. If you are deciding whether to keep, support, or migrate a multivalue system, the practical answer depends on three things: which family you run, how much of the business logic lives inside the database, and whether you can still find people who know the system.
What the multivalue data model actually is
A multivalue record is a nested structure rather than a flat row. A field can hold multiple values, and each of those values can hold multiple sub-values. Instead of normalising that repetition into separate tables, the database keeps it in place and relies on a dictionary to describe how each field is stored, formatted, and displayed.
Two consequences follow:
- No joins for repeating data. A customer record can carry its own list of orders or line items directly. Retrieval is often a single read rather than a join across tables.
- The dictionary carries logic. Field definitions, display formats, and calculated values live in the dictionary, so business rules are frequently embedded in the data layer rather than in application code. This is the single biggest reason migrations are harder than they first appear.
The main multivalue families and how they differ
| Family | Typical platform | Vendor / support status | Notes for planning |
|---|---|---|---|
| Pick OS | Historically Pick-derived operating systems and ports | Long-established, niche | The original multivalue lineage; skills are scarce and often held by long-serving staff |
| mvBase | Windows-based multivalue environment | Legacy product | Common in smaller installations; often runs business-critical apps with little documentation |
| Rocket Universe | Unix/Linux and Windows | Actively vendor-supported | One of the more viable options if you intend to keep a multivalue system running |
| Northgate Reality | Reality/RealWeb environments | Legacy vendor line | Frequently encountered in older public-sector and enterprise estates |
The distinctions matter less for the data model than for your options. A vendor-supported platform gives you a realistic "keep and maintain" path. A discontinued or thinly supported one pushes you toward migration, or toward freezing the system and extracting data.
Signs you are still dependent on a legacy multivalue system
- The application runs on hardware or an OS version that is hard to replace.
- Only one or two people understand the dictionary items and stored procedures.
- Reporting is done by exporting to spreadsheets because the built-in tools are unfamiliar.
- Any change request is met with "we'd need to find a specialist."
Each of these raises risk. The knowledge dependency is usually the most urgent, because it disappears without warning when someone retires.
Migration paths and the steps that matter
Migration from a multivalue system to a relational or modern platform generally follows the same shape, whatever the source:
- Inventory the data and the logic. List files, dictionary items, and any calculated or trigger-like behaviour. Separate what is data from what is business rule.
- Extract to a neutral format. Flatten multivalue and sub-value structures into a form a target system can load, typically delimited files or staged tables.
- Transform. Rebuild the repeating groups as related tables, and re-implement dictionary logic as application or database logic in the target.
- Validate. Reconcile record counts, totals, and a sample of complex records against the source before cutover.
- Cut over with a rollback plan. Keep the source readable for a defined period.
The transformation step is where most projects lose time. A field that looked like simple text may encode a code, a date, and a status in one delimited string.
When to keep the system instead of migrating
Migration is not automatically the right answer. Keeping the existing system can be reasonable when:
- The application is stable and the business value of change is low.
- A supported vendor path exists for the platform you run.
- You can document the dictionary and train at least two people.
- You can isolate the system from unsupported hardware and OS versions.
If none of those hold, plan the migration early rather than under pressure.
A note on specialist availability
Contract resource for multivalue systems has been shrinking for years as experienced practitioners retire. Nine Elms Solutions, a UK firm that described itself as primarily multivalue systems users and designers offering legacy data migration help, has ceased trading following the owner's retirement, with the owner continuing website development only as a hobby through Internet Style. That is a concrete example of the wider trend: the specialists you might plan to call later may not be available when you need them. Build knowledge transfer and documentation into your plan now, not at the point of crisis.