Hard conversation: how the CTO communicates the product needs a rewrite

The word "rewrite" freezes any executive meeting. The problem is rarely technical — it is communication. See the template senior squads use to present a rewrite to CEO/CFO/board, and why managed squads execute rewrites without stopping operations.

Por Victhor Araújo

Victhor Araújo

Every CTO eventually has to present the hardest word to the board: rewrite. Legacy system doesn't scale, doesn't document, doesn't attract talent, doesn't meet compliance. Engineering has known for months; the CFO hears it today for the first time. The predictable reaction: 'you want to redo everything?'.

The problem is rarely the technical decision — it's the communication. A senior squad presents rewrite as a risk and timing decision, not as engineering complaint. Revin has a template that shifted the conversation across 3 clients in the last 2 years: rewrite approved in the first meeting, executed without stopping operations.

For CTOs needing to sell rewrite to CEO/CFO/board, and for founders who heard the word and are deciding whether to approve or fire the CTO.

Presenting rewrite as a risk decision (not a dev complaint) changes the board's answer

🚫 Why the traditional presentation fails

The CTO walks into the meeting with technical slides: 'code is spaghetti, no tests, old framework, team can't evolve'. CFO hears 'you want to spend money to redo the same thing'. CEO hears 'engineering isn't keeping up'. Result is defense, not decision.

The problem: the CTO presents symptom (bad code) without translating to consequence (risk in money and time). Without that translation, executives can't decide rationally.

📋 The 4-slide template that works

Slide 1 — The cost of NOT rewriting in the next 12 months

In USD: feature capacity lost (devs spend X% on workarounds), expected incident cost (probability × impact), turnover cost from technical frustration, cost of failing compliance the client is asking for. Total over 12 months.

That slide shifts the conversation. Without it, executives only see rewrite cost; with it, they see the cost of both paths.

Slide 2 — Defined scope (not "let's redo everything")

Partial rewrite is the rule; total rewrite the exception. List modules to be rewritten (usually 30-50% of system), modules to be kept (50-70%), and why each division. 'We'll rewrite payments and auth because X; reporting stays because Y'.

Slide 3 — The no-stop strategy (strangler pattern)

Executives fear 'stopping operations for 6 months to redo'. The right answer: strangler pattern. New version runs alongside old, traffic migrates module by module via feature flag, rollback possible any time. Operations don't stop; clients don't notice.

This slide eliminates the biggest executive fear. Without it, the board's 'no' is almost guaranteed.

Slide 4 — Delivery cadence and when the board measures success

Monthly milestone with business metric (not technical). Month 1: auth module migrated, login latency -40%. Month 2: payments migrated, transaction failure -60%. Months 3-6: continuation. Without business milestones, rewrite becomes an opaque project; with them, it becomes a measurable investment.

A managed squad executes rewrite with strangler pattern — operations do not stop, value keeps flowing

🛠️ How a managed squad executes rewrite without stopping operations

• Strangler pattern by default — new version coexists with old, gradual migration with feature flag.
• Team split between 'legacy maintenance' and 'new build'. Senior squads have capacity for both.
• Parallel metrics: legacy and new system reported together for 6-12 months until full decommission.
• Rollback documented per module — not 'all or nothing', but 'module X reverts to legacy if it fails'.

💸 The scenario where rewrite is NOT the answer

A senior squad also knows how to say "no" to rewrite. Cases:

• Team lacks maturity to conduct rewrite — becomes infinite refactor with no progress.
• Product is in product-market-fit validation — focus on iteration, not re-architecture.
• Legacy maintenance cost is < 30% of rewrite cost. The math doesn't work.

Revin operates with a 'refactor before rewrite, rewrite when refactor doesn't fit' bias. Clients will save money more often than they'll approve a rewrite — and that honesty is the differentiator.

📢 Have a legacy system demanding a decision and the CTO has no framework to present? Book a Diagnostic Sprint — Revin delivers analysis in 2 weeks with ready slides for the board.

🎯 Conclusion: rewrite is an executive decision translated by engineering

A CTO who presents rewrite as a technical problem gets 'no'. A CTO who presents it as a risk decision with scope, no-stop strategy, and business metric gets 'yes'. Senior squads conduct that translation; generic squads keep complaining in retro.

📢 See our cases to see where Revin led a rewrite with a client without stopping operations.