Project managers facing a fixed migration deadline are offered a tempting equation: compress the test phase, hit the go-live date, deal with the fallout later. It feels rational. Deadlines are public commitments; test suites are internal niceties. The gamble, made in hundreds of boardrooms every quarter, rests on the assumption that “later” is a manageable country with familiar roads. It is not. It is a territory without maps, funded from next year’s budget. The macro evidence should settle the argument. According to McKinsey (2021), three-quarters of cloud migrations exceeded their budgets and 37% experienced schedule delays — outcomes strongly correlated with compressed testing windows before cutover. A Forbes survey from the same year found 64% of data migrations blew their budgets and 54% ran behind schedule. On ERP projects, McKinsey (2019) found 75% failed to stay on time or within budget, with roughly two-thirds producing negative ROI. The date was met, technically. The project was not.
A Deadline Won Is a Crisis Postponed
The mechanism is not mysterious. When test cycles are eliminated to preserve a cutover date, the defects are not eliminated — they are relocated. An empirical study of 8 open-source projects spanning 12,300 commits and 371 releases, published on arXiv in May 2025, quantified what happens next. In Home Assistant, 85% of scheduled deadlines were followed by spikes in bug-related issues. Kubernetes showed technical-debt peaks immediately before deadlines in 74.1% of measurement windows. GitLab had 77% of feature issues created in a rush just before deadlines. The data describes not a bug but a policy: the deadline is the mechanism by which work is deferred rather than completed. What the distribution reveals is what enterprise architects already know but rarely say aloud: the release date marks the beginning of the crisis, not its end. The delivery team goes home exhausted; the support organisation inherits a defect backlog it did not create and cannot understand. Migration projects that were three months behind schedule at cutover tend not to catch up — they accumulate. The dynamic is perverse. Shortening the test cycle does not compress the timeline; it displaces the work onto a phase — production support — that is slower, noisier, and structurally unsuited to systematic fault-clearing. A bug caught in a test environment costs an afternoon. The same bug reaching thousands of live users costs an incident, a root-cause analysis, an emergency patch, and a customer-relations reckoning. The deadline was met in the calendar. It has not been met anywhere else.
The Defect Tax Nobody Has Measured
Anyone arguing for the test cycle reaches for the same chart: a defect costs 1× to fix at design, 15× at testing, and 60 to 100 times as much in production, attributed to the IBM Systems Sciences Institute. The number is quoted in vendor decks, conference talks and business cases, and it is almost certainly worthless. The Institute was an internal staff training programme, not a research body. The chart’s traceable origin is Roger Pressman’s 1987 textbook, whose citation reads “[IBM81]” — course notes. Laurent Bossavit, who followed the chain back, found no underlying data at all, and dated whatever project figures might once have existed to 1981 or earlier, possibly 1967.
That matters more than it first appears. The case for testing under deadline pressure has been resting, for forty years, on a number with nothing behind it — which is precisely the sort of unexamined assumption a migration programme is built from. The case does not need it. The Consortium for Information and Software Quality put the cost of poor software quality to US organisations at $2.41 trillion in 2022, and the deadline studies above measured where the defects actually go. The honest claim is not that a production bug costs sixty times a design bug. It is that nobody knows the multiplier, the organisation discovers it only after go-live, and no migration plan has ever budgeted for it. A known, bounded cost is being exchanged for an unknown one, and the exchange rate is set after the trade. The behaviour is further entrenched by organisational accounting. Test failures before go-live appear on the project’s ledger. Production incidents after go-live appear on operations. The deadline is measured against the project; the blowout is someone else’s budget line. This accounting fiction is what makes the gamble feel rational at the time, and catastrophic in retrospect — usually during the following year’s planning cycle, when a new transformation programme is scoped to fix what the last one left behind.
Debt That Doubled While Teams Sprinted
The project-level dynamics are only part of the picture. Oliver Wyman calculated in July 2024 that global technical debt roughly doubled between 2012 and 2023, growing by approximately $6 trillion. Three US industries alone — banking and investment, communications, and government — accounted for 64% of an estimated $2.2 trillion of that growth domestically. Oliver Wyman’s prescription: earmark 15–20% of IT budgets for systematic debt reduction. Organisations that defer until crisis typically spend 30–40% on emergency transformation programmes instead — twice the rate, under conditions far worse for careful engineering. The developer doing the actual work already knows where the time goes. Stripe found in 2018 that engineers spend more than 17 hours per week — roughly 42% of their working time — on maintenance: debugging, refactoring, and unpicking the decisions of previous deadline sprints. That is the productivity premium sitting inside the test cycles being sacrificed. Now add generative AI to the stack. Faros AI’s 2025 analysis of development pipelines, drawing on DORA data, found that bugs per developer rose 54% year-on-year, the probability of a production incident more than tripled per merged change, and 31% more pull requests were merged with no review at all — with PR review time rising 441% as volume outpaced reviewer capacity. The DORA 2024 report simultaneously recorded a 3.4% code-quality improvement alongside a 7.2% drop in delivery stability. Throughput is up; fragility is up faster. The industry has discovered a novel method for skipping testing: automate the code generation and leave the human reviewer too far behind to catch up. The project manager who cuts testing to hit the deadline is not buying speed. She is writing a bond with a floating interest rate, no maturity date, and no coupon payments — just a principal that compounds until the next transformation programme is commissioned to pay it off. The next transformation, naturally, will also have a fixed deadline.
References
- Curiosity Software, “Too Many Migration Projects Fail” (2024) — citing McKinsey (2019, 2021) and Forbes (2021). https://www.curiositysoftware.ie/blog/too-many-migration-projects-fail
- Empirical study of scheduled deadlines and defect spikes across 8 open-source projects, arXiv, May 2025. https://arxiv.org/html/2505.04027v1
- Consortium for Information and Software Quality (CISQ), 2022 annual report on the cost of poor software quality. Via ContextQA. https://contextqa.com/blog/cost-of-defects-in-software-testing/
- Laurent Bossavit, “The IBM Systems Science Institute” — tracing the 1:15:60-100 defect-cost ratios to course notes cited in Pressman (1987), with no underlying data. https://gist.github.com/Morendil/ebfa32d10528af04e2ccb8995e3cb4a7
- “Everyone cites that ‘bugs are 100x more expensive to fix in production’ research, but the study might not even exist”, The Register, 22 July 2021. https://www.theregister.com/2021/07/22/bugs_expense_bs/
- Oliver Wyman, “Reducing Technical Debt” (July 2024). https://www.oliverwyman.com/our-expertise/insights/2024/jul/reducing-technical-debt.html
- Stripe (2018) developer time survey; Stepsize (2021) longitudinal study. Via Rockstar Developer University. https://rockstardeveloperuniversity.com/technical-debt-statistics/
- Faros AI, “The 5th DORA Metric: Rework Rate — Track It Now” (2025). https://www.faros.ai/blog/5th-dora-metric-rework-rate-track-it-now
Discussion