How to price a legacy rebuild from evidence, before you go to vendors
Every rewrite estimate rests on a scope, and most scopes are assembled from memory. That is where the overrun begins, long before anyone quotes a day rate. This guide shows how to measure the scope instead and turn it into an estimate your board can approve and a baseline your bidders can use to prepare comparable bids.
Why the estimate is wrong before anyone quotes a price, and what the overrun data actually shows
Why the most expensive line in a rewrite is functionality nobody uses, and why it costs you twice
Nine questions to interrogate any rewrite estimate, including ours
The board wants a number, and nobody can produce one they trust
A rewrite cannot be approved without a price, and the price cannot be built without knowing what has to be rebuilt. In most organisations that second question has no reliable answer, so the number is assembled from workshops, from memory and from what people believe is important.
The result is an estimate that holds until the work meets the system. Then it moves, and everyone concludes that estimating software is inherently hard. Estimating software is hard. Estimating the wrong scope is impossible.
You will recognise this if
Three vendor quotes came back so far apart that none of them told you anything
The scope was agreed in a workshop and nobody could say which modules are still in use
Your last estimate held until month four, and then it did not
Finance has asked for a number and the honest answer is a range wide enough to be useless
Most guides answer this with a price range. This one does not.
A published range tells you what other organisations paid to rebuild systems that are not yours. It is useful for orientation and it is not sufficient for a board paper or a tender, because neither will accept a number that cannot be traced to your own application.
There are only two ways an estimate gets produced. Either the scope is described by people and then priced, or the scope is measured from the system and then priced. Everything else is arithmetic performed on whichever of those you started with.
This guide is about the second route: what it takes to measure a scope, what it produces, and what it lets you do that a range never will.
Nine questions to ask about any rewrite estimate
A number without a method behind it cannot be evaluated, only believed. These questions separate the two, and they work on any supplier.
The remaining six, including the one about who owns the specification if you choose a different supplier, are in chapter 7 of the e-book.
Pretius states an accuracy of around 90 per cent for its AI Forms to APEX Assistant, which reads .FMB and .XML files for Oracle Forms estates. That figure belongs to that tool, on that input. The behavioural method described in this guide carries no published accuracy claim, and the guide does not invent one. What it does instead is state what each method is built from, what it can see and where it stops.
Three things the guide is explicit about
#1
Which estimation method fits which situation
including the case where neither applies cleanly and conventional discovery is the right answer
#2
What an evidence-based scope contains
and what it still cannot tell you before delivery starts
#3
Why an estimate that states its own confidence
is worth more than one that does not
What is inside
01
Why the estimate is wrong before anyone quotes a price. Four weak inputs, and what the research on IT project overruns actually establishes
02
Counting what is actually there. The six things an evidence-based scope gives you, and the estimate line each one corresponds to
03
The most expensive line item is the one nobody uses. Why unused functionality costs twice, once to build and once in duration
04
Complexity is not screen count. The four variables a count misses, and the five surprises that arrive in month four
05
The same scope, three different prices. Why the target stack belongs in the estimate rather than in the technical annex
06
Two ways to produce the number. Code-based and behavioural estimation, their entry conditions and their limits
07
How to interrogate an estimate. Nine questions, written to be used on us
08
Turning the number into an RFP. Why three quotes usually cannot be compared, and what to put in the pack so they can be
09
Where this guide stops. The boundary between a project cost and a business case
Written for everyone in the approval chain
CIOs and IT directors
You have to bring a number to a committee and defend how it was built. The guide gives you the method behind it and the questions to test every quote you receive.
CFOs and finance leaders
You are being asked to approve a figure for work that has a documented history of overrunning. Chapters 1, 3 and 8 explain where the risk actually sits and what makes one estimate more defensible than another.
Programme and procurement leads
You need bids that can be compared. Chapter 8 covers what goes into a scope baseline and why publishing it changes what a tender tells you.
Where OmniSense fits
The e-book is about a method. OmniSense is how Pretius applies it. A lightweight component is installed alongside your application, records real user sessions and converts them into a scope you can price, without access to your source code.
Full system inventory, with unused functionality identified rather than assumed
Dependency mapping and risk scoring per component, based on complexity, coupling and observed error rates
Complexity classification and effort estimates adjusted for the target stack
Timeline ranges given as best case, expected and worst case, with the assumptions stated explicitly
A structured cost breakdown you can put into a vendor RFP or an internal budget request
Installation carries no upfront cost beyond compute resources, and the captured data stays in your infrastructure
For Oracle Forms estates where source files are available, the AI Forms to APEX Assistant analyses .FMB and .XML files directly and produces a module-level scope with a manday estimate.
Get the e-book
Leave your work email and we'll send the PDF straight to your inbox.
FAQ
By measuring how it is used rather than by taking it apart. Sessions are recorded alongside the running application, or in a dedicated environment equivalent to production, and converted into an inventory of screens, roles, workflows and dependencies.
A workshop produces the system as people describe it, which is the main path without the exceptions and the modules they personally touch without the ones they do not. A measured scope is testable, which is the property that survives a tender.
Yes, where the system is web-based and actively used. Where verifiable source files exist and the estate is Oracle Forms, code-based analysis is available as well. The e-book explains which route fits which situation.
Considerably. The same inventory of screens and workflows produces different effort figures on different target stacks, which is why a credible estimate prices the scope against each candidate and states its assumptions for each.
A system inventory with unused functionality identified, a complexity classification, a dependency map, extracted business rules, a risk register, and a cost breakdown with timeline ranges and stated assumptions.
No. The specification belongs to you. Whether or not you proceed with any particular partner for delivery, you leave with a map of how your system actually functions, which is what makes it usable as an input to a tender.
Looking for a software development company?
Work with a team that already helped dozens of market leaders. Book a discovery call to see:
