Migration · Audit → Mirror → Cutover
The only question that matters is what happens to your company while we do this. The answer is: nothing. We audit a copy of your programs, we stand your system up in our cloud against a copy of your data, and we run both engines side by side until they agree byte for byte. Your production system keeps running the entire time — right up to the weekend you choose.
Byte-exact, or it doesn't ship.
The harness that built the runtime is the harness that moves you
The incumbent runtime was the golden-master oracle while we wrote ours. That same comparison
rig is what we point at your business.
01 The shape of it
Here is the same process described only in terms of what it does to the system you are running right now — because that is the part nobody else will put in writing.
01Audit
You send a copy of your program directory. Programs only — no data, typically a few megabytes. Everything after that happens on our machines. Nothing is installed, nothing is connected to, and nobody has to schedule anything.
02Mirror
Your ERP comes up in our cloud against a copy of your data, while production carries on untouched. Then both runtimes get the same programs and the same inputs, and every read, every write and every arithmetic result is hashed and compared.
a37f1c9e==a37f1c9eOK41b8e0d2==41b8e0d2OKPREC 4==PREC 4OK03Cutover
Freeze Friday evening, copy the files, run the weekend in parallel, point the terminals at the new host. Monday morning your users sign on to the same screens and the same keystrokes. The old box is still sitting there, still working.
02 Stage one · Audit
Tar up your program directory and send it over. Programs only, no data — for most shops that is a few megabytes. It goes through the same parser that has already digested 5,079 programs and 536,000 lines of real production Business Basic source, and you get a report back.
Automated. No call, no salesperson, no card. It tells you which programs run today, which need attention, and what your migration actually looks like — named program by named program, in plain language. Plenty of people take that report and do nothing with it, and that is a perfectly good outcome for us.
This one goes further: your data files, your integrations, your customizations, gone through by hand. It comes back as a written migration plan and a fixed-price quote for the work. The fee is credited in full toward the migration itself, and the plan is yours to keep whether or not you go ahead.
03 Stage two · Mirror
We stand your ERP up in our cloud against a copy of your data. Your production system is not migrated, not touched and not aware of us. Then we do the thing that makes this provable rather than promised.
The incumbent was our oracle. Now it's your referee.
Differential testing. Both runtimes, the same programs, the same inputs — and every read, every write and every arithmetic result hashed and compared. Not a smoke test. Not a sample. The whole file, record for record, and the pennies digit for digit under the same rounding model.
This is exactly how the runtime was built in the first place. We used the incumbent as a golden-master oracle for years: it answered, we answered, and any disagreement was a failing test on our side. That harness didn't get thrown away when the engine worked. It is now the migration tool.
So the mirror isn't a demo environment. It is a continuous, machine-checked argument about whether the two systems are the same system — and you can watch it run for as long as you like. Most people want at least one clean month-end close diffed before they will talk about a date, which is the correct instinct.
Byte-exact or it doesn't ship. There is no second definition of "working" here.
Differential harness summary screen: 5,079 programs and 536,000 lines parsed at 100%; 1,344,450 records read and compared byte for byte; writes read back in the incumbent runtime byte for byte; 245 of 245 arithmetic cases penny-exact; a key-indexed read at 2 ms against a 3,665 ms full scan; 0% CPU per idle session; zero differences.
↑ The harness output during a parallel run. Reads, writes and arithmetic are compared on both engines; production is not part of the experiment.
One line of harness output, repeated a few million times
Both runtimes · same inputs · hashed and compared
a37f1c9e==a37f1c9eOK41b8e0d2==41b8e0d2OKPREC 4==PREC 4OKThe write path is gated the same way as the read path: records our engine writes are read back in the incumbent runtime and compared byte for byte, on real multi-level keyed files. Writing is the part everyone else waves through.
04 Stage three · Cutover
Your programs are unchanged. Your data files are unchanged. Your users sign on Monday to the same screens and the same keystrokes. The only thing that changed is the runtime underneath them.
Last order goes through the old system as normal, end of the shift. Nobody works late. Nobody has to be told a new procedure, because there isn't one yet.
The data files are copied across as they are — same format, same keys, no conversion pass and no transformation step to get wrong. It is a copy, and copies are verifiable.
Both systems get the weekend's work and the harness compares them one more time, on the real cutover data. If Sunday doesn't come out clean, Monday doesn't happen and nothing has been lost but a weekend.
Terminals point at the new host. Same sign-on, same menu, same F-keys, same 80×24 screen. The training budget for this is zero, because nothing your people touch has moved. The old box is still there, still working.
We don't convert. We don't transform. We don't rewrite.
That isn't a promise about how careful we are. It's a description of the architecture: there is no conversion step in this process, so there is no conversion step to undo.
05 No lock-in
This is the part worth reading twice, because it is the part that decides whether any of the rest is worth the risk.
Rolling back is not a project. It's a decision.
We do not convert, transform, re-encode or rewrite anything. Your programs are still your programs. Your data files are still in their native format, with their original keys, on disk, byte for byte.
Which means your existing runtime still runs them. Not "could be made to" — still does, exactly as it does today, on exactly the same bytes.
There is no lock-in, because there is nothing to lock in. No proprietary export format to get back out of. No schema that only we understand. No re-implementation of your business rules that only exists in our codebase. Nothing about this migration is one-way.
So if you decide six weeks in that you hate us, you point the terminals back at the old box and carry on. That is the whole reversal procedure.
Your keyed files are read and written in place, in the format they are already in. No migration script, no intermediate representation, no one-way door. The thing everyone fears about a data migration is the transform, and there isn't one.
Your source is not modified, refactored, ported or "modernized". If a program has to be changed in order to run, we treat that as a defect on our side — it goes on our work list, not on your team's plan.
Through audit and through the whole mirror period, production runs exactly as it always has. The first time anything about your live system changes is the Friday you picked — and the old environment is still there afterwards.
Ask at any time and we hand back a complete copy of your programs and data files in their original on-disk format, not a proprietary export — during the relationship, not only at the end of it. That is written into our terms, not just into a sales conversation.
06 What it costs you in effort
Four things, and none of them is a full-time person. The team that is already too busy to do the rewrite is also too busy to do this, so we designed it that way.
Programs only, no data. A tar file, typically a few megabytes. This is the entire input to the free audit.
For the mirror only, and it is a copy — taken however your backup already takes one. Production keeps the original and keeps running on it.
Somewhere your people can sign on to the mirror and try to break it — the same 80×24 screen, in a browser if that is easier than a VPN.
Not a developer. The person who can say "that report is wrong, it should be netting freight" — because the harness proves the two systems agree, and only a human can say what they should be doing.
Not needed
No porting, no refactoring, no "small compatibility edits" that quietly turn into a six-month branch nobody can merge. We run your source as it sits. If it doesn't run, that is our defect and our work.
Not needed
No export, no reload, no schema mapping, no reconciliation weekend where somebody discovers the freight bucket didn't come across. The files are read and written where they are, in the format they are already in.
Not needed
Same screens, same field editor, same F-keys, same muscle memory built over twenty years. The people in the warehouse should not be able to tell you did this, and if they can, we got something wrong.
Everything else — standing the environment up, running the harness, chasing down every difference until there are none — is ours. That is what you are paying for.
07 Timeline
Every system is different, so we are not going to quote you a date on a marketing page. What we can give you honestly is the shape — and the shape is the useful part, because it tells you which units to think in.
Days
Audit
The free compatibility report is automated. The full assessment — data files, integrations, customizations, plan and fixed-price quote — takes longer, and is measured in weeks rather than days.
Weeks
Mirror and parallel run
Standing your environment up is quick. Diffing it until you believe it is the part that takes real time, and it should. Most people want a month-end close through the harness before they will pick a date.
Weekend
Cutover
Freeze Friday, copy Saturday, parallel Sunday, live Monday. If Sunday isn't clean, you don't go — and you have lost a weekend, not a quarter.
Stated as a shape, deliberately. A shop with a few hundred programs and no third-party code is not a shop with several thousand programs, four integrations and a vendor-encrypted pricing module. The assessment is where the shape becomes a schedule, and the schedule comes with a fixed price attached.
08 Questions
Once, for the cutover window you choose — normally a weekend. Everything before that happens on copies: a copy of your programs for the audit, a copy of your data for the mirror. Your live system is not migrated, not modified, and not connected to anything of ours during the process.
We do. Standing up the environment, running the harness, and chasing every difference to zero is our job — it is the thing you are buying.
From your side it is four things: a copy of the programs, a copy of the data, a terminal your people can test on, and one person who knows the business well enough to say whether a report is right. Not a project team, and not your one remaining developer full-time for a year.
As long as you want one. There is no clock on it and no pressure to cut over by a date that suits us.
Most people want at least one clean month-end close diffed before they will talk about a weekend, and we think that is exactly the right instinct — a close exercises more of your business rules in three days than normal trading does in a month.
It goes in the report with its name on it, and then it is our defect. We do not hand you a list of "customer remediation items" and call that a migration plan.
The exception we are honest about: a small number of programs in a typical corpus were shipped encrypted by a third party. We cannot run what we cannot read, so those need source from whoever wrote them, or they need replacing. The audit tells you precisely which ones and how many, before you have spent anything.
This is the honest gap. Report writing and print spooling are being rewritten rather than emulated — faithfully emulating a forty-year-old spooler means inheriting its constraints forever, and printing is the one area where customers actively want the behavior to change. That subsystem is not finished.
It is also the first thing the audit looks at, precisely because it is where the surprises live. You find out before you sign, not after.
Identical. Same sign-on, same menu numbers, same 80×24 screen, same box drawing, same function keys, same character-level field editor, same password masking. Terminal behavior was measured off the real runtime and replayed against ours, not guessed at.
If someone in the warehouse notices that anything changed, we consider that a bug report.
Stage one
Programs only, no data, no obligation and no salesperson. You get back a report on what runs today and what your migration would actually involve — and if the answer is "not yet", we would rather you found that out for free.
Would rather talk to a person first? Email hello@uniquebb.com and tell us roughly how many programs and how many users you have. See also pricing and what runs today.