Replacing a Legacy System: Where the Budget Actually Goes

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A seed-to-Series-A SaaS founder whose five-year-old Rails or Django monolith is blocking a enterprise sales deal because it cannot produce a SOC 2 Type II audit trail or support role-based access control, and who needs to take a replacement budget to the board next quarter

Replacing a five-year-old Rails or Django monolith to clear a SOC 2 Type II blocker almost never costs what the vendor's statement of work says. The honest shape of the budget is: 35–50% new build, 20–35% data migration and reconciliation, 10–20% compliance surface (SOC 2 audit prep, RBAC, audit logging, pen test), and 15–30% parallel-run operating cost for the 60–120 days you are paying to run both systems. That last line — the parallel run — is the one almost no vendor quotes and the one that most frequently turns a $400K engagement into a $550K engagement. This post breaks down each driver, what pushes the number up or down, and the three questions that convert a range into a real quote.

One honest caveat upfront: the industry baseline for projects at this scale is not encouraging. A McKinsey/University of Oxford study of 5,400+ IT projects found that large IT projects run on average 45% over budget and deliver 56% less value than predicted, and 17% threaten company survival. The point of a structured budget is not to eliminate that risk — it is to make the overrun visible before you commit, not after.

The honest shape of the number

For a Series-A SaaS company replacing a monolith that handles customer data, auth, billing, and 3–6 third-party integrations, the total engagement typically breaks into five buckets. The percentages below are directional, drawn from published modernization benchmarks, not a quote:

The two numbers board members usually ask about — build cost and timeline — are the ones that compress or expand least. The real variance lives in migration and parallel run. Bloor Group research cited by Oracle found that 83% of data migration projects either fail or exceed their budgets and timelines, with cost overruns averaging 30% and time overruns 41%. If your vendor's SoW has migration as a fixed line item under 15% of total, that is the first thing to interrogate.

Driver 1: New build (35–50% of total)

This is the least ambiguous bucket because it maps cleanly to feature inventory. The things that move it:

• How much of the existing feature surface you actually keep. Most legacy replacements are an opportunity to kill 20–30% of features that no one uses. Measure before you scope. Every feature kept is build cost plus migration cost plus test cost.
• Number of user roles and permission layers. A system with three roles (admin, user, viewer) is a different build from one with role inheritance, per-resource permissions, and delegated admin. For a SOC 2 Type II context, you are almost always in the second category.
• Integration count and style. Three REST integrations with modern APIs is a line item. Three integrations where one is a SOAP endpoint from a 2011 ERP and another requires SFTP file drops is a different project.
• Who owns the domain model. If your team can give the build team a validated data model on day one, you save 4–8 weeks. If the model has to be reverse-engineered from the Rails schema and tribal knowledge, add it back.

Driver 2: Data migration (20–35% of total)

This is the bucket most frequently underquoted. Industry data on ERP replacements suggests data migration accounts for 30–50% of total modernization budgets, and for mid-market ERP it alone can run $250K–$1.5M+. SaaS monolith replacements sit at the lower end of that range, but the mechanics are the same.

What drives it:

• Schema drift. A Rails app that has been through five years of migrations has columns added, deprecated-but-not-dropped, backfilled inconsistently, and populated by scripts no one remembers running. Every one of those is a decision in the migration.
• Data quality. The ERP Research Institute found 76% of companies discover data quality issues only during the parallel-run period. Translation: you cannot cost migration accurately until you have profiled the data, and profiling is itself a 2–4 week engagement.
• Historical depth. Migrating active records is linear work. Migrating seven years of transactional history for an auditor is a different problem — it may need separate archive infrastructure rather than a live table.
• Reconciliation tooling. You need automated row-count and checksum comparisons running continuously during the parallel run. Build this on day one of migration, not month three.

Driver 3: Compliance surface (10–20% of total)

If a SOC 2 Type II audit is the forcing function, the compliance work is a specific, well-bounded scope. The audit itself, per ComplyJet's 2026 analysis and Drata's cost guide, runs most seed-to-Series-A SaaS companies $35,000–$80,000 all-in (audit fee, compliance platform like Vanta or Drata, pen test), with maintenance of $15,000–$40,000 annually. That is the external cost — it does not include the engineering work to make your system auditable.

The engineering line items a SOC 2 Type II replacement typically needs:

• Role-based access control with per-resource permissions and the ability to prove, in an audit, who had access to what and when.
• Immutable audit logging for authentication, authorization decisions, data reads on sensitive records, and admin actions. Log retention policy aligned with your Type II observation window (typically 6–12 months).
• Encryption at rest and in transit with documented key management.
• Change management evidence — PR reviews, deployment approvals, access to production — all logged and tied to tickets.
• Vendor management for every subprocessor in your new stack.
• Incident response runbook and evidence of at least one tabletop exercise before the audit window opens.

One thing to make plain: a lawyer and a qualified SOC 2 auditor should review your specific scope. The list above is engineering surface; the controls framework and audit boundary need professional sign-off.

Driver 4: Parallel run (15–30% of total — and the one your vendor did not quote)

This is the insight that matters most for your board deck. For 60 to 120 days — sometimes longer — you are paying to operate two systems. Both have infrastructure costs. Both need on-call. Both need bug fixes. And someone, usually a senior engineer plus an ops person, is manually reconciling data between them every day.

The published numbers: running two systems simultaneously during modernization adds 20–40% to infrastructure cost, and for larger portfolios the dual-run period can extend 12–24 months. For a SaaS monolith replacement, 60–120 days is more typical, but the per-month cost is not just infrastructure. It is:

• Dual production infrastructure (databases, app servers, monitoring, backups)
• Dual observability stack (Datadog, Sentry, etc. — most are per-host or per-event)
• Reconciliation engineer time (0.5–1.0 FTE for the duration)
• Customer support dealing with discrepancies users surface
• Bug fixes applied to both systems during the window
• Delayed feature work on the new system because the team is firefighting the old one

The reason this line item is missing from vendor quotes is simple: the vendor is quoting their build. The parallel run is your operational cost, not theirs. But it is a direct consequence of the replacement decision, which means it belongs in the budget you take to the board.

A rule of thumb: take the monthly run-cost of your current system, multiply by 2.2 (not 2.0 — reconciliation overhead is real), and multiply by the number of months you plan to overlap. That is your parallel-run budget. Then add 25% because the overlap always runs long.

Driver 5: Cutover, training, contingency (5–10%)

The smallest bucket, and the one most often cut when the budget needs trimming. That is usually a mistake. This covers:

• Final cutover weekend (engineering + ops on standby, rollback plan tested)
• Customer communication and training materials
• Internal training for CS, sales, and finance teams who touch the system
• Post-launch support window (typically 30–60 days of elevated support capacity)
• A real contingency line — 10–15% of the build cost, not zero

An illustrative worked example

This is illustrative, not a quote. Assumptions stated inline so you can see what moves:

Scenario: Series-A SaaS, five-year-old Rails monolith, ~40 database tables, 4 user roles, 5 third-party integrations (Stripe, Segment, SendGrid, Salesforce, one internal customer's SFTP), ~15,000 active users, 3 years of transactional history to migrate, SOC 2 Type II required for a pending enterprise deal, no current RBAC beyond admin/user, no structured audit logging. Team has one senior backend engineer available to co-build; vendor supplies the rest.

Rough shape of the engagement:

• New build (React + Node or Rails 7 + Postgres, with proper RBAC and audit logging baked in): 4–6 months of a 4-person team
• Data migration (profile, map, build, reconcile): 2–3 months, overlapping with build
• SOC 2 engineering surface: 1–2 months of focused work, overlapping
• Parallel run: 90 days at ~2.2x current infra cost plus 0.75 FTE reconciliation
• External SOC 2 costs: $35K–$80K per ComplyJet, plus 6-month Type II observation window
• Cutover and 60-day post-launch support window

The total engagement for this shape typically lands in a wide range depending on team geography, hourly rates, and how much of the parallel-run work the customer absorbs internally. Published guides on legacy modernization — Mobisoft's AI-assisted delivery breakdown is one — put mid-complexity SaaS modernizations in the low-to-mid six figures for the build alone, with migration and parallel run adding another 40–60% on top. Your specific number depends on the three questions in the next section.

What pushes this up vs. what pulls it down

The three questions that turn a range into a quote

Before any vendor can give you a defensible number — and before you can defend a number to your board — three things need answers:

1. What is the exact feature inventory you are keeping, and who signed off on what you are cutting? Not a wishlist. A ranked list with an owner's name next to each item. This single artifact typically moves the build estimate by 20–30%.
2. What does your data actually look like? Not what the schema says. What a two-week profiling sprint on production data reveals: null rates on required fields, orphaned records, duplicate customers, date fields storing strings. Until this is done, every migration quote is a guess.
3. How long are you willing to run both systems in parallel, and who owns the reconciliation? If the answer is "as short as possible" without a specific number, you are optimizing for a risk your ops team will pay for later. A realistic 90-day plan with named reconciliation owners is cheaper than an aspirational 30-day plan that slips to 150.

Without these three answers, you are not getting a quote. You are getting a range dressed up as a number.

How CodeNicely can help

We work with Series-A and growth-stage SaaS teams on exactly this shape of problem: a monolith that was fine at $2M ARR is now the thing blocking a $400K enterprise deal, and the founders need a defensible modernization plan rather than a cleanup project. Our digital transformation practice handles legacy replacement as a scoped engagement — data profiling first, then feature audit, then a build plan with the parallel-run cost explicit on page one, not buried.

The engagement most similar to a SaaS monolith replacement is GimBooks, the YC-backed accounting SaaS where we rebuilt core billing and compliance workflows while the existing system continued serving customers — the kind of parallel-run management this post is about. For founders in the US specifically, our US delivery team handles the SOC 2 engineering surface alongside the build, so you are not sequencing two vendors. The IP and the audit evidence are yours; no vendor lock-in on either side.

The honest conclusion

A board-ready budget for replacing a legacy system is not a single number. It is five numbers with named owners and a documented contingency. The vendor's lump-sum quote is useful as an input, not an answer — and the single most important thing you can do before signing it is to make the parallel-run cost explicit. The McKinsey/Oxford data is clear that projects of this size overrun by default. The ones that do not overrun are the ones where the sponsor refused to accept a budget that did not break down into these buckets.

If you are preparing a board deck for next quarter, do the two-week data profiling sprint and the feature inventory before you lock the budget. Those two artifacts, more than any vendor negotiation, will determine whether your final number is defensible.

Frequently Asked Questions

How much does it cost to replace a legacy SaaS monolith?

The honest answer is a range, not a figure, because the five cost buckets — build, migration, compliance, parallel run, cutover — each depend on scope decisions only you can make. Published benchmarks put mid-complexity SaaS modernizations in the low-to-mid six figures for the build, with migration and parallel run adding 40–60% on top. The number becomes a quote once you have a signed-off feature inventory, a data profiling report, and a committed parallel-run duration.

Why is data migration so often underquoted?

Because accurate migration cost requires profiling the actual production data, and most vendors scope before profiling. Bloor Group data shows 83% of migration projects fail or exceed budget, with cost overruns averaging 30%. The fix is a paid two-week profiling sprint before the main SoW is signed — treat it as a separate engagement so the migration estimate is based on real data, not schema assumptions.

How long does a legacy system replacement take?

For a Series-A SaaS monolith with modest integration surface, the build phase is typically 4–6 months, data migration overlaps for 2–3 months, and parallel run adds 60–120 days before full cutover. SOC 2 Type II adds a 6–12 month observation window that can run in parallel with later stages. The timeline is driven more by data complexity and parallel-run length than by build velocity.

Can we do SOC 2 Type II on the old system instead of replacing it?

Sometimes — but if the current system cannot produce audit logs, enforce RBAC, or isolate customer data cleanly, retrofitting those controls often costs more than the replacement and buys you an auditable version of a system you are planning to retire anyway. A qualified SOC 2 auditor should assess your specific scope before you decide; this is not an engineering-only call.

What is the single biggest hidden cost in legacy replacement?

The parallel-run period — 60–120 days where you operate both systems while reconciling data between them. Published data puts the infrastructure overhead alone at 20–40% above steady state, and that does not include the reconciliation engineer, dual on-call, and duplicated bug fixes. This line item is missing from almost every vendor quote because it is your operational cost, not theirs. Add it to the budget before the board meeting, not after.