Legacy System Replacement: Pricing the Data Migration Layer

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

For: A Series A SaaS founder in Bengaluru whose 4-year-old Django monolith is blocking two enterprise deals because it cannot pass a basic data-portability audit, and who has received two vendor quotes — ₹18L and ₹52L — with no explanation of the difference

If you have two vendor quotes for replacing a four-year-old Django monolith and they are ₹18 lakh and ₹52 lakh apart, the gap almost always lives inside the data migration layer — and neither vendor can honestly price that layer until someone has spent two to three weeks reading your stored procedures, your CSV export scripts, and the Slack threads where your first backend engineer explained why invoice numbering skips every seventh value. In Indian startup legacy replacements, data migration typically consumes 35–50% of total project cost, and the reason is not data volume. It is undocumented business logic. The cheaper quote is usually cheaper because the vendor has not yet discovered what they are migrating. The expensive quote is usually expensive because they have — or because they are padding against the risk that they haven't.

This post breaks down what actually sits inside a data migration line item for a Series A SaaS replacing a Django monolith, what moves the number up and down, and the three questions that convert a range into a defensible quote.

Why the migration layer is the line item that blows up budgets

Gartner research cited across the industry puts the failure rate of data migration projects at 83% — either they fail outright or significantly exceed budget and schedule (TechVedhas summary). The failure pattern is almost always the same: the discovery phase was rushed or skipped, undiscovered objects surfaced during execution, and the team paid execution-phase rates to solve problems a two-week assessment would have caught (AZ Big Media, 2026).

The counter-intuitive bit, documented across DataFlowMapper and CTO Accelerator benchmarks, is that pre-migration planning and assessment consume 50–70% of total project effort, while actual migration execution accounts for only 20–30% (DataFlowMapper). Teams estimating a migration keep budgeting for the move. The move is cheap. The archaeology is expensive.

For a four-year-old Django monolith specifically, the archaeology problem is acute. Django's ORM makes schema changes easy, which means your production database has four years of incremental, undocumented migrations. Business logic has leaked into three places simultaneously: Python models, raw SQL in RawSQL blocks or stored procedures, and the Celery jobs that patch data nightly because someone found an edge case in 2022 and never came back to fix it properly. A new system has to replicate all of this behaviour or decide, item by item, which rules were bugs and which were features.

What is actually inside the migration layer

When a vendor writes "data migration" as a line item, they are bundling at least six distinct workstreams. The quotes that come in low usually include two or three of these and quietly assume the client will handle the rest.

1. Source system discovery and schema archaeology

Someone has to read every table, every foreign key, every index, every trigger, every stored procedure, and every scheduled job. For a Django app, that includes the migrations folder (which is often inconsistent with the actual production schema), management commands, Celery periodic tasks, and any raw SQL embedded in views. CloudApper's teardown of legacy migrations notes that stored procedures routinely encode pricing rules, compliance calculations, and approval chains added iteratively by developers who no longer work at the company — none of which appear in any requirements document (CloudApper AI, 2025).

2. Business rule reverse-engineering

Once the schema is mapped, someone has to figure out why. Why does the invoices table have a legacy_tax_rate column that is null for 94% of rows but populated for a specific set of customers in Maharashtra? Is that a bug, a grandfathered pricing promise, or a GST compliance workaround? This is the single most under-estimated line in every migration quote, because the only way to answer it is to interview the founding engineer, the finance lead, and sometimes a specific customer success manager.

3. Target schema design

The new system's schema is not a copy of the old one. It is a cleaned-up version that encodes the business rules you decided to keep, drops the ones you decided were bugs, and restructures anything that was shaped by old product decisions. This takes a senior engineer and a product owner in the same room, and it is where most of the "should we even keep this feature" conversations happen.

4. ETL pipeline construction

The actual code that extracts from the source, transforms into the target shape, and loads. For a well-scoped migration this is the smallest line item — frequently 15–20% of total migration effort. It is also the only part that most vendor demos show you.

5. Reconciliation and validation

You cannot ship a migration until you can prove that every invoice total, every user balance, every audit log in the old system matches the new one — or that you have an explicit, signed-off reason for every difference. For a SaaS failing a data-portability audit, this is the layer that satisfies the auditor. Skipping it is how companies end up with a successful migration and a lost enterprise deal.

6. Cutover and rollback

The plan for the actual switch — whether it is big-bang, parallel-run, or strangler-pattern — plus the rollback plan if cutover fails. A dual-write parallel-run adds 20–40% to migration cost but is often the only option for a company that cannot afford a weekend of downtime because enterprise SLAs are in play.

Cost drivers, in order of impact

These are the levers that actually move the number, roughly ordered by how much variance they introduce.

Data complexity, not data volume

This is the single most mis-estimated driver. A 500 GB database with heavy procedural logic costs more to migrate than a 5 TB database with a clean, well-documented schema (AZ Big Media, 2026). Volume affects infrastructure cost during cutover, which is a line item in rupees not lakhs. Complexity affects engineer-weeks, which is where the money is.

Markers of high complexity in a Django monolith: more than 30 stored procedures or database functions, Celery jobs that modify data on a schedule, any use of PostgreSQL triggers, custom audit tables maintained by application code, soft-delete flags with inconsistent enforcement, and columns whose meaning changed over time (same field, different semantics in 2021 vs. 2024 rows).

Number and type of integrations

Every external system that reads from or writes to your database is a migration dependency. Payment gateways, email providers, analytics tools, CRM syncs, data warehouse ETLs, webhook consumers. Each one needs its connection re-pointed, re-tested, and sometimes re-architected. Two integrations is a small project. Twelve is a different project entirely.

Compliance surface

If you are failing a data-portability audit now, you are probably about to be asked for SOC 2, ISO 27001, or sector-specific requirements (RBI for fintech, DPDP Act compliance generally). Audit-grade migration means every record movement is logged, every transformation is explainable, and PII handling is documented. Add 15–25% to migration effort for audit-grade work versus best-effort.

Who supplies the domain expert

If your founding engineer or finance lead can give the migration team 8–10 hours a week for the discovery phase, you save weeks. If the vendor has to reverse-engineer business rules from code alone because your team is unavailable, the archaeology phase doubles. This is the cheapest lever a founder controls and the one most consistently wasted.

How much of the old system has to keep running

A clean cutover is cheaper than a parallel run. A parallel run is cheaper than a strangler migration where old and new coexist for six months. Enterprise SLAs usually force the expensive option.

Target architecture choices

Moving to a cleanly structured monolith on managed Postgres is cheaper than moving to microservices on Kubernetes. Teams often decide to re-architect during migration, which is the single fastest way to turn a six-month project into a fourteen-month one.

An illustrative worked example

To make the shape of the number concrete — this is illustrative, every number is a benchmark not a quote, and your situation will differ.

Assumed scope: a four-year-old Django + PostgreSQL monolith; roughly 180 GB of production data; 24 tables with meaningful business logic; 11 stored procedures and 6 Celery jobs that modify data; 4 external integrations (Razorpay, SendGrid, Segment, HubSpot); SOC 2-adjacent audit requirements but no formal certification yet; founding engineer available 8 hours a week; parallel-run cutover required because two enterprise customers have 99.9% uptime SLAs; target is a cleaner Django service on managed Postgres, not a re-architecture.

For a project of this shape, industry benchmarks suggest data migration alone typically runs 35–50% of total replacement cost. Fullstack's 2026 modernization pricing analysis notes that 67% of legacy modernization projects exceed initial estimates by over 35%, and the overrun almost always traces to the migration layer being under-scoped at quote time.

Breaking the migration layer itself into the six workstreams above, the rough effort distribution for this scope looks like:

The two workstreams at the top — discovery and reverse-engineering — are where the ₹18L and ₹52L quotes almost certainly diverge. The cheaper quote is probably assuming your team will do most of the archaeology and hand the vendor a clean specification. The expensive quote is probably assuming the vendor has to do it all.

What pushes the number up vs. pulls it down

If you look at your own system and most of your rows are on the left, the ₹52L quote is probably closer to honest. If most are on the right, the ₹18L quote might be real — or the vendor might not have asked enough questions yet.

The India market context

India's application modernization services market is projected to grow from USD 626.68 million in 2025 to USD 1,746.63 million by 2030, an 18.6% CAGR that significantly outpaces global expansion (MarketsandMarkets, 2025). The practical consequence for a Series A founder: vendor capacity is tight, pricing is firming up, and the gap between competent and incompetent migration vendors is widening. The ₹18L quote may not be a bargain — it may be a shop that is undercutting because they do not yet know what they do not know.

The Indian SaaS sector is on track to reach US$50 billion by 2030 (IBEF, citing Bessemer), and the enterprise deals that growth is unlocking all come with data-portability, audit, and security requirements that four-year-old monoliths were not designed to meet. The migration problem is going to get more common, not less.

How to read your two quotes

Before you compare the numbers, line both quotes up against this checklist. Ask each vendor, in writing:

• Have you reviewed our production schema, our Django migrations folder, our stored procedures, and our Celery job definitions? Which of these does your quote assume versus not?
• Which of the six migration workstreams above is included in your line item, and which is excluded or assumed to be client responsibility?
• What is your assumption about availability of our founding engineer or domain SME during discovery?
• Is your cutover plan big-bang, parallel-run, or strangler? What triggers rollback?
• What reconciliation evidence do you provide to our auditor at the end?
• What happens to your price if discovery surfaces more than N stored procedures or more than M undocumented business rules? (A good vendor has an answer. A bad one says "we'll handle it.")

The ₹18L vendor who answers these honestly may still be the right choice — some vendors genuinely are cheaper because they are efficient. But the ₹18L vendor who cannot answer them is the one who will come back at week six asking for a change order.

For founders working through this evaluation, our legacy modernization work and migration case studies in fintech SaaS walk through how discovery scoping actually changes the shape of a quote.

The three questions that turn a range into a quote

No vendor — including one you trust — can give you a defensible fixed price on data migration until these three things are answered. If you want to compress the quote cycle, answer them before the next sales call.

1. What is the full inventory of writers to your production database? Not just the Django app. Every Celery job, every management command, every manual SQL script your team runs, every external system with database credentials. List them.
2. Which business rules do you want preserved, which do you want fixed, and which do you not know about yet? The last category is the biggest cost driver — it is what forces the discovery phase. Being honest about its size up front is cheaper than discovering it mid-execution.
3. What is your cutover tolerance? Can you take a 12-hour maintenance window on a Sunday? A 4-hour window? Zero downtime? Each answer is a different architecture and a different price.

Once those three are on paper, the ₹18L vs. ₹52L gap usually resolves itself — either the cheaper vendor revises up because they now see what they missed, or the expensive vendor revises down because the risk they were pricing against turns out to be manageable. Either way, you are comparing the same project.

Frequently Asked Questions

Why is data migration so expensive relative to building the new system?

Because the new system is scoped by a product spec you control, while migration is scoped by four years of undocumented decisions you don't fully remember making. Industry benchmarks consistently show pre-migration planning and assessment consuming 50–70% of total project effort — the actual data movement is the small part. You are not paying for the move. You are paying for the archaeology that makes the move safe.

Can we do the data migration ourselves to save money?

Sometimes, yes — if your founding engineer is still at the company, has 15–20 hours a week to spare for 8–12 weeks, and has done a migration of comparable scope before. For most Series A teams, none of those conditions hold, and the opportunity cost of pulling your senior engineer off product for three months is higher than the migration quote. A common middle path is to have your team own discovery and business-rule documentation while a vendor owns ETL, reconciliation, and cutover.

How long does a legacy migration like this typically take?

The honest answer is that duration is driven by the same factors that drive cost — complexity, integrations, cutover tolerance, and SME availability. A clean like-for-like migration for a mid-sized SaaS is usually a matter of a few months end-to-end; a parallel-run migration with audit requirements and a re-architecture pulled in is substantially longer. The three questions above are the ones that convert a timeline range into a date.

What is the single biggest mistake founders make when evaluating migration quotes?

Comparing the total number without comparing the discovery assumption. Two vendors can quote the same project and arrive at numbers 3x apart purely because one assumed two weeks of discovery and the other assumed six. Ask each vendor to break out discovery as its own fixed-price phase, then compare execution quotes once discovery is done. This is also the pattern that catches 67% of legacy modernization projects that overrun by more than 35% — the overrun almost always traces to execution being quoted before discovery was done.

Does the DPDP Act change how we should plan the migration?

It changes the documentation and consent trail you need around PII movement, and it means your migration logs become part of your compliance evidence. Specific obligations depend on the categories of personal data you hold and your role as data fiduciary — a lawyer and a compliance auditor should review your migration plan before cutover, not after. Build the audit trail into the ETL from day one; retrofitting it later is more expensive than including it.