What Is mvBase and What Can You Still Do With It Today?

mvBase is a multivalue (Pick-family) database and development environment that runs primarily on Windows, and it is now a legacy, end-of-life product with no active vendor support. You can still run an existing mvBase system, but the practical options today are: keep it running as-is, migrate the data to a modern database, or move the application to another multivalue platform. Which one makes sense depends on how much the application still matters to the business and how much risk you can tolerate.

Where mvBase sits in the multivalue family

Multivalue databases store data in a way that breaks with the relational model: records are organised into files, fields within a record can repeat, and values within a field can repeat again. This "nested" structure is why the model is called multivalue, and it is the common thread running through Pick OS, mvBase, Universe, and Northgate Reality Realweb.

mvBase belongs to that family but is not the same thing as Pick OS. Pick OS is the older operating-system-and-database combination that established the model; mvBase is a later implementation that brought multivalue concepts to a mainstream platform. If you already understand Pick-style files, dictionaries, and query language, mvBase will look familiar. If you are coming from SQL, the mental shift is the main hurdle.

What that means in practice

• Data is accessed through a dictionary-driven query language rather than SQL.
• Applications are typically written in a BASIC variant tied to the platform.
• The database and the application environment are closely coupled, which is convenient while it works and awkward when you want to leave.

Who still runs mvBase, and why

mvBase systems tend to survive in organisations where the application was built years ago, does one job well, and has never been worth the disruption of replacing. Typical settings include distribution and wholesale, manufacturing, membership and subscription administration, and other line-of-business systems with heavy record-oriented processing.

The reason these systems persist is usually not technical affection. It is that the application encodes years of business rules, the data model is genuinely efficient for the workload, and a rewrite looks expensive until something forces the issue.

The consequence of end-of-life status

Because mvBase is no longer actively supported, the practical risks are:

• No vendor fixes. Security issues and platform-compatibility problems stay unfixed.
• Hardware and OS drift. Newer Windows versions and new servers may not be validated against it.
• Skills scarcity. People who know mvBase are retiring or moving on, so routine changes get harder to staff.
• Migration debt. The longer the system runs, the more business logic accumulates inside it, and the larger any future migration becomes.

None of these is an emergency on its own. Together they mean the system should be treated as something you are managing down, not building on.

Your three realistic options

If the application is genuinely load-bearing, the second and third options are the ones worth costing properly. If it is peripheral, the first is defensible.

Migrating data away from mvBase

The data migration is usually the part people underestimate. The steps below are the general shape of the work; the specifics depend on your files and dictionaries.

1. Inventory the data. List every file, its dictionaries, and which fields actually hold meaningful data. Undocumented fields are common and are a frequent source of lost information.
2. Map the model. Decide how repeating fields and values will be represented in the target. A repeating field might become a child table, a JSON array, or a delimited column — each choice has consequences for querying later.
3. Extract. Pull the data out in a form you can transform, preserving record keys and any relationships encoded in them.
4. Transform. Apply the mapping, resolve duplicates and orphaned records, and normalise dates, numbers, and codes that were stored in platform-specific formats.
5. Load and verify. Load into the target and reconcile record counts and key totals against the source. Do not skip this — silent row loss is the classic failure mode.
6. Run in parallel. Keep the old system readable while the new one beds in, so you can check results against the original.

Common pitfalls

• Treating dictionaries as documentation. They describe how data is presented, not always what it means.
• Flattening too eagerly. Collapsing repeating structures into single columns loses information you cannot reconstruct.
• Ignoring the application logic. The data is only half the system; business rules embedded in BASIC code often need to be reimplemented, not just moved.
• No reconciliation step. Without a count-and-total check, you will not know what went missing.

Finding help

mvBase and multivalue work is a specialist niche, and the pool of people who know it is shrinking. When looking for contract or specialist help, the useful signals are direct experience with Pick-family systems (mvBase, Universe, Northgate Reality Realweb) and a track record with legacy data migration and transformation, ideally including moves toward modern targets such as Oracle.

One practical caution: some of the long-standing firms in this space have wound down. Nine Elms Solutions, for example, has ceased trading following the retirement of its owner, though its principal continues website development as a hobby through Internet Style. That pattern — experienced multivalue people leaving the market — is itself a reason to plan your exit or support arrangement sooner rather than later. When you engage someone, ask specifically which multivalue platforms they have migrated from, and ask for a reconciliation approach, not just an extraction tool.