How to Estimate an Enterprise Platform Rebuild Without Lying to Yourself

Ask five engineering leaders how long a platform rebuild should take, and you'll get five numbers with no shared method behind any of them. That's not because estimation is impossible — it's because most organizations estimate the part of the work that's easy to estimate and wave their hands at the part that actually determines the timeline.

The easy part is feature scope: how many screens, how many CRUD flows, how many roles in the permission model. This is genuinely estimable, and most teams are decent at it. The hard part — the part that blows up nine-month timelines into fifteen-month ones — is almost never feature scope. It's data migration integrity, undocumented business logic buried in the legacy system, and integration behavior that doesn't match what the vendor's documentation claims.

Our estimation process treats these as three separate problems, because they have three separate failure modes.

Feature scope gets a bottom-up estimate from the people who'll build it. We break the system into vertical slices — not "the frontend" and "the backend," but full flows like "an adjuster resolves a claim" — and the engineers who'd actually build each slice estimate it, based on prototypes from discovery where possible. Top-down estimates from an architect who won't write the code are systematically optimistic, because the architect doesn't feel the friction of the ORM's quirks or the third field validation library that turns out to be abandoned.

Legacy business logic gets a discovery budget, not an estimate. If your current system has fifteen years of behavior encoded in stored procedures, conditional branches, and tribal knowledge that lives in three people's heads, we don't pretend to know how long it'll take to extract before we've actually looked. We scope a fixed-time, fixed-cost investigation phase — usually one to three weeks depending on system size — whose sole output is an inventory of the logic that has to be preserved, with confidence ratings on each item. Only after that inventory exists does the rebuild estimate include real numbers for this category, instead of a padding percentage pulled from nowhere.

Integration and migration risk gets ranges with named triggers. Instead of a single number, we give a range and say explicitly what pushes the estimate toward each end: "12 weeks if the legacy database's foreign keys are actually enforced the way the schema claims, 16 weeks if we find orphaned records that need manual reconciliation." This isn't hedging — it's giving the client the actual decision-relevant information, which is not the number but what the number depends on.

The habit we're pushing against is the single point estimate delivered with false confidence, because that's what internal stakeholders often want to hear and what agencies are incentivized to say to win the deal. A range with named triggers is harder to sell in a pitch meeting. It's also the only version of an estimate that's still true six weeks into the build.

The last thing worth saying: an estimate is not a promise, and a good estimation process includes a plan for what happens when reality diverges from the range. We re-estimate at defined checkpoints — typically every four weeks — using the same method, so that surprises get surfaced in days, not discovered at a launch date that was fiction from week two.