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 then we run both engines against the same files and compare the bytes — for as long as it takes you to believe it. 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 engine is the harness that moves you
We established our behavior by measuring what the runtime you license today actually does —
down to its on-disk record-locking protocol. That is why both engines can run against the
same files, and why the comparison is yours to watch.
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. Both engines then run against the same files, with 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 an entire production ERP corpus of real Business Basic source, every program, without an exception, and you get a report back.
Automated. No call, no salesperson, no card. It names every program in your corpus, tells you what each one needs, and shows 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.
Your data files, your integrations, your customizations, gone through by hand by the engineers who wrote the engine. It inventories every integration and every third-party component and says exactly what each one needs, before anything is committed — then comes back as a written migration plan and a fixed-price quote. The $9,500 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: both engines, the same files, and the bytes compared.
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 engine was built in the first place. We did not read a manual — we measured what the runtime you license today actually does, down to its on-disk record-locking protocol. That is why both engines can hold the same files open at once without corrupting each other's work, and it is what turns a parallel run from a slide into a thing you can watch.
We pointed it at ourselves first. When we rewrote our engine, we ran the new one and the one it replaces over all seven benchmark programs, twice, independently, and byte-compared the output: identical, both runs, zero mismatches. Behind that sit more than 2,200 automated tests, and nearly half of our source is test code. We kept the harness after it went green, and 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: the entire program corpus parsed, every program, no exceptions; 1,344,450 records read and compared byte for byte; writes read back in the incumbent runtime byte for byte; expression cases penny-exact under the PRECISION model; a key-indexed read at 2 ms against a 3,665 ms full scan; seven of seven benchmark programs byte-identical across two independent runs; 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. It can run them at the same time we do, because we implemented the same on-disk record-locking protocol we measured off it.
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 pricing module that came from somewhere else. The assessment is where the shape becomes a schedule, the schedule comes with a fixed price attached, and the custom work is written into both.
08 Questions
Because you watch it. Both engines run against the same files, get the same programs and the same inputs, and every read, every write and every arithmetic result is compared. Nothing is sampled: 3,631,827 records across ten production files have already gone through that comparison record for record, and your corpus goes through the same rig.
We built the engine the same way. Its behavior was established by measuring what the runtime you license today actually does rather than by reading a manual, and more than 2,200 automated tests hold that behavior in place. When we rewrote the engine, all seven benchmark programs produced byte-identical output against the engine they replaced, twice, independently, with zero mismatches.
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 that is the right instinct — a close exercises more of your business rules in three days than normal trading does in a month.
Every program lands in the report with its own name on it, and making it run is our work, not yours. We do not hand you a list of "customer remediation items" and call that a migration plan.
The assessment inventories every integration and every third-party component you have — the interface somebody wrote against a supplier in 2004, the module that arrived from another vendor, the feed that goes out at four in the morning — and says exactly what each one needs, before anything is committed. Engineering against your particular corpus is the method here, not an exception to it, and it is priced before you sign.
Printing and output are engineered against what you actually run — your forms, your stationery, the check run, the pick ticket, the label printer on the packing bench — rather than inheriting forty-year-old constraints and calling that compatibility. Your print paths come out of the assessment named one at a time, and building them is part of the migration.
It is also where the interesting requests live. Most shops want something out of printing that the old spooler was never going to give them, and this is the point at which they get it.
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 — named program by named program, costed before anything is committed, from the engineers who wrote the engine.
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.