Pick and MultiValue Support, Migration & Modernisation
the database is not the problem. Old releases and lost knowledge are.
For businesses running a custom system on a Pick or MultiValue database: UniVerse, UniData, D3, mvBASE, jBASE or OpenInsight. We assess the BASIC programs, the dictionaries and the data, keep the system supported, bring it onto a current release where that is the better answer, and replace it in stages where it is not.
More about this service
We are an Australian team working remotely with businesses in the United States, the United Kingdom, New Zealand and Australia. Every engagement starts with a scoped technical assessment, so the estimate that follows is based on your code and your data.
- Assessment A scoped technical review before any estimate
- 18+ yrs Building business software
- Independent No licence commission, no reseller agenda
- US UK NZ AU Australian team, working remotely
Built here. Your data stays here.
- No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
- Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
- Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.
Still running the business, and understood by very few people
A Pick system keeps a whole order, lines and all, in one record, and lets a programmer change a screen or a report in an afternoon. That made these systems quick to build and cheap to run, which is why distributors, manufacturers, wholesalers and membership organisations still run custom systems on UniVerse, UniData, D3 and their relatives decades after they were written.
Read more
The obstacles are practical, not mysterious: a database release several versions behind, business rules spread across BASIC programs with no documentation, dictionaries that no longer match the data, green screens that new staff do not want, and one or two people who understand it all. The databases themselves are still developed, so the first question is what to keep, not how fast to leave.
Our Pick BASIC developer service is for businesses in Perth, Melbourne, Sydney and Brisbane. It covers three kinds of work: code fixes and updates, migration to a modern technology stack, and ongoing maintenance and support.
Three ways forward for a Pick or MultiValue system
They are not exclusive. Most systems need the first before either of the others.
-
Keep it and support it
The system stays on its current database. We maintain the BASIC programs, document the dictionaries and the overnight processes, and add a web service or a reporting copy of the data where other systems need one. This suits a system that works and mainly needs to stop depending on one or two people.
-
Upgrade it, or move to another MultiValue platform
The same programs and data are brought onto a current release, or moved from mvBASE or an old D3 release to a MultiValue platform with a longer road ahead, such as UniVerse or jBASE. Staff keep the screens they know, and the business rules are not rewritten.
-
Replace it in stages
Where the business needs browser screens, live links to other systems or reporting the old design cannot give, the data is reshaped into a relational database and modules are rebuilt as a web application one at a time while the rest keep running.
What we do with Pick and MultiValue systems
Six kinds of work. Most engagements are two or three of them.
-
BASIC maintenance
Faults fixed and changes made in existing BASIC programs, PROCs and paragraphs, in the dialect your platform uses.
-
File health and performance
Hashed files checked for overflow and resized, indexes reviewed, and slow selections traced to their cause.
-
Upgrades and platform moves
A system brought onto a current release, or moved between MultiValue platforms, with programs recompiled and the differences in BASIC and query syntax worked through.
-
Dictionaries written down
Every file, dictionary item and calculated field documented, with the places where the data no longer matches its dictionary.
-
Web services and reporting
A web service or a SQL reporting copy beside the system, so other software and report tools stop depending on a programmer.
-
Staged replacement
Multivalued data reshaped into relational tables, and modules rebuilt as a web application one at a time.
Supporting it, moving it and rebuilding it are different projects
Each trades cost against how much of the MultiValue system remains afterwards.
-
Stay on the current platform
Lowest cost. The system is documented and supported, and changes can be made again. On an old Rocket release it faces added maintenance charges and, in time, the end of vendor maintenance.
-
Upgrade or change MultiValue platform
Most of the code is reused and staff keep the screens they know. The system ends up on a supported release. It is still BASIC on a MultiValue database, so the pool of people who can change it stays small, and the licence for each user continues.
-
Rebuild on a relational database
Nothing depends on MultiValue afterwards, and standard report tools read the data directly. It takes longest. The risk is in rules that exist only in BASIC code, and in reshaping records that hold lists within lists into ordinary tables.
What a MultiValue assessment looks at
MultiValue is a family of related databases, not one product. Most of the points below come from knowing exactly which one you run. The lifecycle facts are from Rocket Software and Revelation Software.
-
Which platform and release
UniVerse, UniData, D3, mvBASE, jBASE and OpenQM all belong to Rocket Software. OpenInsight comes from Revelation Software. The Rocket lifecycle handbook lists UniVerse 14.2.1, released in November 2025, and nothing newer than mvBASE 3.3.2, whose standard support ended in April 2025.
-
Where the release sits in its lifecycle
Under the Rocket policy that applies from 1 October 2026, a release has four years of standard support, then limited support with an added charge. Releases more than seven years old lose maintenance after a transition that ends on 31 December 2029, with an added legacy charge on maintenance until then.
-
Whether the source is complete
BASIC source is stored as records in program files, with the compiled object code kept separately. Programs that survive only as object code can run but cannot be changed. Screens built in a tool such as SB+ live in that tool, not in BASIC.
-
Dictionaries and the data
Each file has a dictionary that names its fields, but nothing forces the data to follow it. Records hold lists inside fields, dates are stored as day counts and money without its decimal point. Calculated fields exist only in the dictionary.
-
File sizing and health
Hashed files are often created at a fixed size. When the data outgrows it, records spill into overflow and everything slows down. File sizes, overflow and any damaged groups are checked before anything else is planned.
-
The dialect of BASIC and the query language
Every platform has its own dialect of BASIC and its own query language, and UniVerse accounts run in one of several flavours that change how both behave. A move between platforms is a porting job, and this is where its size is measured.
-
Screens, terminals and printing
Character screens through a terminal emulator such as AccuTerm or wIntegrate, with function keys, printers and spooler queues set up years ago. They decide how any change to the screens will be received.
-
Integrations, licences and the operating system
Files in and out, report tools that read the data, and any web services already in place. How many users are licensed and through which supplier, since many licences were sold with the application. The AIX, Linux or Windows release underneath.
A Pick system that runs the whole business, and one person who knows it?
What the assessment needs from you
A fixed-scope piece of work with a written result: the options, the risks of each, and a staged estimate. No production data is sent by email. We agree a secure way to share it first.
-
Platform and release
Which MultiValue database you run, its release, and the operating system underneath.
-
The source
Whether BASIC source exists for every program, and which parts came from a software vendor.
-
Screens and tools
Whether screens are written in BASIC or built in a tool such as SB+, and which terminal emulator people use.
-
The data
Roughly how many files and how large, and whether anybody has checked their sizing recently.
-
Overnight processes
What runs overnight and at month end, including background jobs, and who knows how.
-
Licences and support
How many users are licensed, who supplied the licences, and whether maintenance is being paid.
-
Integrations
Files in and out, printers and labels, and other systems that depend on this one.
-
People
Who maintains it today, and how long they will be available.
-
What is hurting
The two or three problems that started the conversation.
From assessment to a supported system
Done remotely, with meeting times agreed to suit your time zone.
-
Technical assessment
We establish the platform and release, what source you hold, how healthy the files are, what runs overnight and what connects to the system. You get a written list of options with the risks of each and a staged estimate.
-
Write it down
Dictionaries, key programs and overnight processes are documented with the people who know them. If a retirement is close, this comes before anything else.
-
Proof of concept
One representative piece, usually an upgrade of a copy, a handful of programs ported to another platform, or one file reshaped into relational tables, is taken end to end on your data.
-
Staged work
The work is done in stages agreed from the assessment, each with its own scope and estimate, starting with whatever is hurting the business most.
-
Reconciliation and user testing
Totals, record counts and report output are compared between the old and new, and your staff test the work they do every day.
-
Cutover and support
Each switch is planned with a way back. We watch the first days of live use, then maintain the system for as long as it stays in service.
What people ask us about Pick and MultiValue
Is Pick still supported?
Yes, under other names. Rocket Software develops UniVerse, UniData, D3, jBASE and OpenQM, and its lifecycle handbook lists UniVerse 14.2.1, released in November 2025. Revelation Software develops OpenInsight, now at version 10.2. Whether your own system is supported depends on the release it runs.
Do we have to move off MultiValue?
Often not, and we will say so. The database is fast, cheap to run and still developed. The usual complaints are the green screens, the reporting and the shortage of people who can change the code. The first two can be fixed beside the system. The third is the real reason to plan ahead.
What does the new Rocket lifecycle policy mean for us?
From 1 October 2026, each release has four years of standard support, then limited support with an added charge on maintenance. Releases more than seven years old lose maintenance altogether, after a transition that runs to 31 December 2029. If you pay Rocket maintenance on an old release, the renewal quote is where you will see it first.
Can MultiValue data be moved to SQL Server or PostgreSQL?
Yes, with design work. A MultiValue record can hold a list inside a field, so one file often becomes several tables. Dates, money and codes are converted using the dictionary, and calculated fields have to be rebuilt. The result is reconciled against the original before anything is switched off.
We run mvBASE or an old D3. Should we upgrade or change platform?
It depends on the code, so we test before recommending. Rocket lists no mvBASE release newer than 3.3.2, and its lifecycle FAQ tells D3 customers that this is a good time to consider another MultiValue platform. Porting to UniVerse or jBASE keeps the programs. It is a project with testing, not a restore from backup.
Our Pick programmer is retiring. What is urgent?
Documentation. Getting the dictionaries, the key programs and the overnight processes written down while that person is still available is worth more than any technical change made this year. A second person who can log in, compile a program and restore a backup comes next.
Do you provide Pick BASIC developers in Perth, Sydney, Melbourne and Brisbane?
Yes. We are an Australian team and we take on Pick BASIC work for businesses in Perth, Sydney, Melbourne and Brisbane, and elsewhere in Australia. Most of the work is done remotely, by video call and screen share, with secure access to a copy of your system. The service is the same in every city: code fixes and updates, migration to a modern technology stack, and ongoing maintenance and support.
How does this work from the United States, the United Kingdom or New Zealand?
Remotely. We are based in Australia and do not have offices elsewhere. Discovery is done by video call and screen share, with meeting times agreed to suit your time zone. Confidentiality, who can reach your systems and where your data is held are agreed in writing before work starts.
What does it cost?
The assessment is a fixed-scope piece of work with an agreed fee. The estimate for anything after it comes from what the assessment finds, in stages, so you are not asked to commit to a whole project on a guess.
Sending your details…
You can stay on this page while we send it.
Tell us about your MultiValue system
What the system does, the MultiValue platform and release, who maintains it today, and what is forcing the question. Include your country so we can suggest meeting times. Please do not send production data.
Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.
Kasun Wijayamanna, founderYou deal with Kasun from scope to delivery. No account managers and no offshore handoff.