Legacy rewrite vs refactor: ROI for CEOs and CTOs
The client cabinet is slow. 1C feeds the site via Friday CSV. A new product does not fit the old data model. In the meeting someone says the magic words: “let’s rewrite from scratch.” Six months later — two contours, double entry, and a slipped release.
Legacy rewrite vs refactor is not an engineer argument. It is a CEO/CTO call about money, risk, and a 6–18 month window. Below is an ROI frame and a checklist for when you need a rewrite versus layer-by-layer extraction.
Bottom line. First name the slice that actually blocks revenue. A full rewrite without cutover and a pilot is almost always more expensive than shipping a cabinet/API next to the old contour.
Ship the money-making slice first — then “rewrite everything”
What “legacy” means in business language
Legacy is not “an old language.” It is a system that blocks growth:
- a new sales channel or client role does not fit without hacks;
- CRM/1C exchange is manual or a nightly file;
- peak load or ads mean 503 on the cabinet;
- half the sprint is spent on workarounds, not product.
If the pain is Excel and “final_v3” files — fix the process and a single cabinet first, not rewrite for its own sake. See Excel no longer works and B2B cabinet MVP in 7 screens.
Three strategies: patch, extract a layer, rewrite
1. Patch (local fixes). Fast and cheap on a weeks horizon. Works when the root is a bug or one screen. Fails when the data model and integrations are already the ceiling.
2. Layer refactor (strangler). Next to the old contour you ship a new slice: cabinet, orders API, 1C sync. Old stays until cutover by role/branch is proven. Business sees value every 4–8 weeks.
3. Rewrite from scratch. Makes sense when the core is objectively dead (no tests, no data owner, unsafe to change) and a year of patching costs ≥ a new contour. Otherwise it is an expensive way to delay the decision another year.
- Patch — one screen/bug, business is not blocked
- Layer / strangler — cabinet, API, integration; pilot → cutover
- Rewrite — core blocks growth; scope owner and cutover date exist
How to calculate ROI over 12–24 months
Answer first: compare not “build cost” but full TCO — plus downtime, double entry, and lost deals.
- Build / vendor — rewrite estimate vs slice + keeping the old system alive.
- Operations — staff hours on workarounds, CSV, manual reconciliations (often 0.5–2 FTE).
- Downtime and errors — an hour of cabinet/accounting outage; for SMB often tens–hundreds of thousands ₽ — see cost of an hour of downtime.
- Slip risk — big bang without a pilot pushes a new channel’s revenue by a quarter or two.
Rewrite wins on ROI when patching does not remove the root brake (data, integrations, performance) and in a year you are in the same meeting. Otherwise extracting the cabinet/API is cheaper and pays sooner.
A related scale trap on builders is in No-code vs custom: fast start without an exit plan.
When a rewrite is almost certainly wrong
- No product owner and no “done” criteria — only “make it pretty.”
- No inventory of integrations and data (what writes where).
- Cutover in peak season or with no rollback.
- The team patches production and builds the “new world” without a dedicated contour.
- Budget covers code only — not training or history migration.
Classic failure: two years of a “new” cabinet while orders still live in the old one — because 1C sync was left “for later.”
When layer refactor is the right move
Answer first: there is a thin slice you can ship in 4–12 weeks and measure (cabinet conversion, sync time, share of manual fixes).
- Pick the money path: client/dealer cabinet, order statuses, documents.
- Define API and roles; the old UI can stay.
- Pilot on one role or branch.
- Cutover + rollback; then the next layer (CRM/1C, reports).
You stop arguing “rewrite or not” in the abstract — you buy a working contour in chunks. A 1–2 week scope estimate is a normal first step: get an estimate.
CEO/CTO checklist: rewrite or extend
- Named slice that blocks revenue (not “the whole monolith”).
- TCO for 12–24 months: build + workarounds + downtime + slip risk.
- Integration inventory and data owners on one page.
- Cutover criteria and rollback plan written before coding.
- Pilot on a limited audience before full switch.
- One owner for the contour — through handoff.
- If “a year of patching” ≈ cost of a new slice — extract the layer, don’t stretch the pain.
What to do this week
Book one hour: CTO, product owner, someone who lives in 1C/CRM. Write three money pains and one candidate for the first layer. If the list is empty — you need prioritization, not a rewrite. If the candidate is clear — estimate the slice, not “all legacy.”
Need an external frame for cabinets and integrations — web apps and cabinets, get an estimate, or Telegram @MozziDev.
Related services
Executive FAQ on legacy rewrite vs refactor
When the core blocks growth every quarter (new products, integrations, load), a 12–18 month patch estimate approaches the cost of a new contour, and the team already spends more than half its time on workarounds. A rewrite without a scope owner and cutover criteria costs more than any repair.
Not “rewrite everything,” but extracting a thin slice — cabinet/API, CRM/1C exchange, reporting — while the old contour keeps running. The business gets value every 4–8 weeks instead of after a year-long big bang.
Over 12–24 months compare build cost + downtime/double entry + lost deals + release-slip risk. Rewrite wins if patching does not remove the root brake (data, integrations, performance). Otherwise a planned one-contour refactor is cheaper.
Two contours run in parallel without a clear cutover, data diverges, and staff learn a new UI under peak season. Without a pilot on one branch/role and a rollback plan, the project slips and burns growth budget.
Lock the “money path” (cabinet, orders, accounting sync), estimate a 1–2 week slice, and extract it behind an API. Everything else is queue. An eventual full rewrite with no slice is the most expensive path.
Want to apply this in practice?
Tell us about your system — we’ll propose a work plan and the metrics worth fixing in an SLA/SLO.
Related articles
AI Agent Development for Business: 2–4 Week Pilot, Not a Demo Bot
AI agents for business: how they differ from chatbots and RAG widgets, what a 2–4 week pilot includes, on-prem, CRM/ERP/API integrations, orchestration and KPIs. Checklist before you buy.
Read Article1C and ERP Integration with a Web App: What to Put in the Spec Before Signing
How to connect 1C/ERP to a portal, CRM, or request system without double entry: master data, REST/OData, sync frequency, conflict rules, and integration budget ranges for CEOs and CTOs.
Read ArticleIT Projects for Leadership: 10 Questions Before You Sign
A checklist for CEOs, CFOs and boards: measurable outcomes, business owner, IP, SLA, contract exit and vendor red flags — without microservices jargon.
Read ArticleDeveloper Outstaffing: Senior Squad vs a "300-Person Farm"
How to choose outstaffing: rates, time to onboard, NDAs, velocity transparency, and when a boutique team beats a large integrator.
Read Article