Specialist · Pick / MultiValue migration

UniData, UniVerse & Pick systems, migrated by someone who actually knows Pick.

If your business runs on a Pick / MultiValue system — Rocket UniData, UniVerse, PickBasic, D3 or jBASE — you already know the problem: almost no one left can work on it. I can. I migrate the data and the business logic into a modern .NET, Angular and SQL platform — without losing what the old system knows.

Why it's urgent

A Pick system is brilliant — until you can't get anyone to touch it.

You can't hire for it

MultiValue and PickBasic developers are retiring and aren't being replaced — the talent pool shrinks every year.

One-person risk

The whole system often rests on a single person who understands it. When they leave or retire, the business is exposed.

Hard to integrate

Connecting a MultiValue database to modern web, mobile, payments or reporting tools is painful and brittle.

Ongoing licence & support cost

Proprietary licensing and specialist support keep costing you, for a platform you're trying to move beyond.

Undocumented logic

Decades of business rules are buried in PickBasic, largely undocumented — the riskiest part of any migration.

Aging green-screen UX

Terminal / green-screen interfaces slow new staff down and hold the business back from where it wants to go.

Why me, specifically

The rare part: I understand the old system and build the new one.

Most migrations fail in the gap between two groups: the modern developers who've never seen a MultiValue database, and the few remaining Pick developers who don't build modern web platforms. I sit in both camps — years of hands-on PickBasic, UniData and UniVerse, plus current .NET, Angular and SQL.

That's why the business logic survives the move. I can read what the old system actually does — including the edge cases no one wrote down — and rebuild it correctly, rather than guessing and shipping something that quietly does the wrong thing.

From

PickBasic
UniData · UniVerse
MultiValue · D3 · jBASE

To

.NET
Angular
SQL (MS SQL / PostgreSQL)

Two ways in

From a clean data migration to a full modernisation.

Data migration

Get your data out of the Pick / MultiValue system and into a modern SQL database — Microsoft SQL Server for enterprise needs, or PostgreSQL for lower cost — cleanly mapped from the multi-valued model, ready for reporting, integration, or as the first step toward a rebuild.

  • MultiValue → relational schema design
  • Dictionaries, dynamic arrays & multi-values handled properly
  • Validated, reconciled, repeatable migration

Full modernisation

Rebuild the whole system as a modern, cloud-native web platform — the PickBasic business logic recovered and re-implemented, a proper web UI replacing the green screen, and everything you own and can hire for.

  • Business logic recovered from PickBasic, documented
  • Modern web app on .NET + Angular
  • Phased cutover — the business keeps running

How a migration runs

De-risked, and done in the open.

1

Understand

Review the UniData/UniVerse schema and PickBasic logic; document the rules that matter.

2

Map & design

Design the relational model and target architecture; plan the migration and cutover.

3

Migrate in phases

Move data and rebuild in safe stages, reconciled against the old system, running in parallel.

4

Cut over & support

Switch off the legacy platform — and I stay on to support and enhance what replaced it.

Common questions

Pick / MultiValue migration, answered.

Yes. I map the MultiValue data model — including multi-valued and sub-valued attributes and dictionary items — into a clean relational schema in Microsoft SQL Server or PostgreSQL, then migrate and reconcile the data so you can trust it.

No. Many clients start with a data migration or a single module, running the new system alongside the old one, and rebuild in phases. It keeps the risk — and the cost — under control.

It gets recovered, not lost. I read the PickBasic, work out what it really does (including the undocumented edge cases), document it, and re-implement it in the new platform. This is the part cheap or offshore migrations get wrong.

Yes — migrations run in stages with the old and new systems in parallel, and the data is reconciled against the source before cutover. The business keeps running throughout.

Yes — BMH Technology is Melbourne-based, and you deal directly with me throughout. Not offshore, not a hand-off.

Get off Pick before the choice is made for you.

A free intro call to talk through your UniData / UniVerse / Pick system, or a paid Software Opportunity Review for a full migration plan with budgets and timelines.