Why rewrites overrun
A legacy replacement overruns because it is estimated against the requirements someone can describe, and delivered against the rules the system actually enforces. Modernization starts by recovering those rules — the schema, the jobs, the integrations, the reports, the exceptions — and then replacing one bounded capability with a way to check that the new answer agrees with the old one.
The risk is not failure, it is rigidity
The danger in an old system is rarely that it stops working. It is that it cannot change: a pricing rule takes a quarter, a new customer type does not fit, and the workarounds have already moved into spreadsheets and side systems that now hold real state. Every year of that adds surface area the eventual replacement has to reproduce.
Signals to look for
None of these is decisive on its own. Three or more together usually is.
-
One person is the documentation
A critical rule is understood by exactly one person, and their explanation changes slightly each time they give it. That is not carelessness — it is what undocumented behavior feels like from the inside.
-
The database is reachable, the application is not
You can query the data. You cannot change what the software does with it without a vendor, a contractor, or a build nobody still knows how to run.
-
Exports are load-bearing
A nightly export into a spreadsheet or a side tool is not a report. It is a missing feature that somebody automated, and the operation now depends on it.
-
The estimate assumes the requirements are known
A fixed-price rewrite quoted from a feature list is priced against the described system, not the running one. The gap between those two is where the overrun lives.
-
Nobody can say what would break
Change one field, and the honest answer to "what depends on this" is a shrug. That is a dependency-mapping problem, not a coding one, and coding through it is how projects stall.
How to evaluate it
Five steps, in order. Each one produces something you can put in front of other people rather than an opinion you have to defend.
- 01
Recover the model before designing anything
Schema, scheduled jobs, integrations, reports, roles, and the exceptions people handle by hand. The output is a map of actual behavior, not a wish list of features.
- 02
Separate the rules to keep from the constraints to drop
Some behavior is your business. Some is an artifact of what a database could not do in 2009. Faithfully reproducing the second kind is how a replacement inherits the original's problems.
- 03
Choose a slice with a checkable boundary
One capability, with its own data and a way to compare the new answer against the old one. Reconciliation is the entire point of choosing a slice.
- 04
Build migration as a repeatable job
A migration you can run a hundred times, producing a report of what did not match, is the difference between a cutover and a weekend everybody remembers.
- 05
Name the rollback and the owner before the date
Who decides to go back, on what signal, and how long the old system stays warm. Settling this before cutover is what makes the cutover boring, which is the goal.
Where this leaves Bondi
Where Bondi fits
Bondi's modernization path pairs a scoped assessment and migration project with a platform where the replacement can keep changing after cutover: schema, screens, permissions and workflows version together, and Pro publishes from Development to Production with version history and version restore. The assessment, migration and implementation are scoped and quoted separately from the subscription.
- A dedicated PostgreSQL database per environment, with data import and export
- Development → Production publishing, approvals, version history and restore on Pro
- An owner-level SQL export of the whole database on Pro, so the new data can be reconciled against the system you are replacing
The other half of the answer
When Bondi is the wrong answer
- The system is stable, cheap to run, and nobody needs it to change — replacing it is optional
- It is packaged software with a statutory obligation attached, where the vendor's compliance is the product
- Your data cannot leave your own hardware
If one of these describes you, the honest recommendation is somewhere else. Nothing on this page is improved by pretending otherwise.
Common questions
Is the migration included in the subscription?
No. Assessment, onboarding, migration and implementation are scoped and quoted separately. The system that comes out of that work runs on a normal Bondi subscription.
Do we have to replace everything at once?
No, and it is usually the wrong call. A bounded slice with reconciliation and a rollback plan is the safer first move, and it teaches you what the rest of the project actually contains.
How long does an assessment take?
It depends on how much of the system is still running and how much of it was ever written down. Bondi has no shipped implementations to average, so a timeline quoted before the assessment would be a guess rather than an estimate.
What happens to the old data?
It is imported into a dedicated PostgreSQL database of its own. On Pro an owner can export that database in full as SQL, which is what makes a reconciliation pass against the old system possible during the overlap.
Sources
- NIST SP 1500-10r1 — Adoption and Modernization checked 2026-08-03
Claims about third-party products are limited to what these documents state on the date shown. Where a document is silent, this guide describes the product's design center rather than asserting a limit.