Why Replatforms Go Over Budget

Replatform budget overruns trace to a consistent set of causes: unexamined feature-parity requirements, redesign scope creep, underestimated data migration complexity, and vague RFPs that produced quotes not actually scoped against real requirements. All four are preventable, and all four are scoping failures rather than execution failures.

Last verified: September 6, 2026.

The four most common causes, in order

1. Unexamined feature-parity requirements. Rebuilding every old-platform feature without auditing whether each one is a real customer need or a workaround for an old limitation. This is the largest single cause we see, and the cheapest to prevent. → Feature parity is a trap

2. Redesign bundled in without a deliberate decision. Treating design change as free because the project is already underway. → Should you redesign while you replatform?

3. Underestimated data migration complexity. Assuming data will migrate cleanly rather than budgeting for the reconciliation work real parity testing requires. Dirty data is discovered, not estimated — which is why it lands as an overrun rather than a line item. → Data migration for ecommerce

4. Vague RFPs that produced incomparable quotes. The lowest bid often reflects the vendor who assumed the least complexity, not the best value, and change orders follow once real scope surfaces. → The replatforming RFP template

The pattern underneath all four

Every one of these is a scoping failure rather than an execution failure. The overrun happens because the original scope didn't reflect the actual project, not because the team executing it did poor work against what was agreed.

That's why the disciplines in this series concentrate so heavily on the planning phase. A business case, an RFP, a feature audit, and a data migration plan done rigorously up front prevent the overruns that otherwise show up mid-project, when the cheapest options for fixing them are gone.

It also explains a counterintuitive pattern: overruns correlate more strongly with how quickly a project started than with how complex it turned out to be. Complexity that was scoped is a budget line; complexity that was discovered is an overrun.

Two causes that don't make the top four but should be budgeted for

Post-launch stabilization. The first 30 days after launch reliably produce work — edge-case data issues, integration hiccups, and real-world traffic patterns that pre-launch testing didn't surface. Budgeting zero for this is a choice to fund it from somewhere else later. Treat it as a planned phase with allocated hours rather than an unplanned surprise.

Internal time. A replatform consumes significant hours from people whose salaries sit outside the project budget — merchandising, customer service, finance, and whoever answers the vendor's questions. That cost is real even when it never appears in a line item, and underestimating it is how projects slip on decision latency rather than engineering.

What the disciplined version looks like: Nuts.com cut reliance on custom code by 85% during its migration and saw total cost of ownership fall 28% in year one and 41% in year two. That's what a feature-parity audit buys, priced over the life of the platform rather than the length of the project.

What to do if you're mid-project and already over budget

Identify which of the four causes is actually driving the overrun, because the fix differs by cause. A feature-parity problem needs an honest re-scoping conversation, not more hours. A data migration problem needs more reconciliation time, not more development time. An under-scoped RFP needs a renegotiated statement of work rather than a series of change orders approved one at a time.

Treating all overruns the same way — usually by adding budget without diagnosing the cause — just delays the same problem to the next milestone. And approving change orders individually is how a project loses track of its own total: each one is defensible on its own, and nobody is looking at the sum.

One thing worth protecting when a budget conversation gets tight: the pre-launch disciplines are the wrong place to cut. SEO preservation, parity testing, and pre-launch UX review are cheap relative to what they prevent, and cutting them converts a budget problem into a revenue problem.

How to build a budget that holds

Since all four causes are scoping failures, the defence is structural rather than a matter of estimating more carefully.

Carry a real contingency, and say what it's for. Fifteen to twenty percent of the build cost, held against the four named causes specifically. A contingency with a stated purpose survives review; an unexplained buffer gets negotiated away in the first budget conversation and is then missing when it's needed.

Fund discovery separately from the build. The two decisions that most affect final cost — the feature-parity audit and the data profiling — happen before anyone can price the build honestly. Approving them as their own small phase produces a build estimate worth having, instead of an estimate made in the absence of the two facts that determine it.

Set a change-order threshold in the contract. Agree in advance that changes above a stated value need explicit approval, and that a running total is reported monthly. Overruns rarely arrive as one large surprise; they accumulate as a series of individually reasonable decisions that nobody was summing.

Budget the phases that get forgotten — post-launch stabilization, and the internal time from people whose salaries sit outside the project. Neither is optional. Leaving them out doesn't avoid the cost, it just moves it somewhere with no line item.

The signals that a budget is drifting

Four things worth watching monthly, each of which precedes a visible overrun by weeks:

• Change orders arriving steadily rather than occasionally. A pattern is a scoping problem; a one-off is a change.
• Discovery questions still being answered during build. If the team is still learning what the requirements are, the estimate was made without them.
• Data remediation appearing as a recurring line. It means profiling was skipped, and the remaining volume is unknown by definition.
• Testing being deferred rather than descoped. Deferred testing isn't a saving. It's a transfer of cost to a phase where it's more expensive, and usually to a phase where it's paid in revenue rather than hours.

Where this fits

These four causes are the failure modes that Anatta's replatforming method is organized to prevent, and the planning artifacts that prevent them start with the business case.

Frequently Asked Questions

What's the most common cause of replatform budget overruns?

Unexamined feature-parity requirements — rebuilding every old-platform feature without auditing whether it's a real customer need or a workaround for an old limitation that may not exist on the new platform.

How do I fix a replatform that's already over budget?

Diagnose which of the four common causes is actually driving it rather than just adding budget. The fix differs depending on whether the root cause is feature scope, redesign creep, data migration complexity, or an under-scoped original RFP.

What should be budgeted for that usually isn't?

Post-launch stabilization for the first 30 days, and internal team time from people whose salaries sit outside the project budget. Both are real costs that don't appear as line items, and both get funded from somewhere else when they arrive.

Where should we not cut when a replatform budget gets tight?

The pre-launch disciplines — SEO preservation, data parity testing, and pre-launch UX review. All three are inexpensive relative to what they prevent, and cutting them converts a budget problem into a revenue problem.

How much contingency should a replatform budget carry?

Fifteen to twenty percent of the build cost, held explicitly against the four named causes. A contingency with a stated purpose survives budget review; an unexplained buffer gets negotiated away and is then missing when it's needed.

What are the earliest signs a replatform budget is drifting?

Change orders arriving steadily rather than occasionally, discovery questions still being answered during build, data remediation appearing as a recurring line, and testing being deferred rather than descoped. Each precedes a visible overrun by weeks.