The four things a website rebuild does not inherit: a migration runbook (India, 2026)

Disclosure: I work on delivery at ZoopCoder, a web and app development agency in India. Rebuilds are our higher-value work, so I have a commercial interest in you concluding "rebuild" — which is why this post is mostly about how to avoid needing one, and it publishes the number that argues against my own side.

Most "should we rebuild?" arguments happen on the wrong axis. People argue about the stack. The thing that actually decides the price, the timeline and the risk is what survives the move.

A redesign inherits everything for free, because nothing moves. A rebuild inherits nothing for free. That gap — not the framework, not the design hours — is where the entire cost difference lives, and it is why a rebuild quote with a big total and no migration lines is a quote for a different project.

Here is the runbook I wish more Indian rebuild quotes were written against.

First: does it even need to be a rebuild?

Three switches. Run them line by line down the change list, not on the project as a whole. One yes anywhere on a line puts that line into rebuild territory.

1. The platform changes. Builder → WordPress, WordPress → custom, one framework → another. Also: the platform is abandoned, or nobody has the code.
2. The site must start remembering something it does not store today. Logins, orders, uploaded files, a consent record, roles.
3. The URL structure changes. Addresses change, sections merge or split, new domain, language prefix.

Zero yeses across the whole list means it is a redesign, whatever anyone is calling it. This matters more than it sounds: it is common for eleven items out of twelve to be pure redesign and exactly one item — usually "let customers log in" — to be the only thing flipping a switch. That item can very often be carved out and scoped separately later, at a fifth of the price today.

Indian bands, 2026, for calibration:

Work	Band
Restyle a brochure site, same pages, same URLs	₹25,000–₹50,000
Restyle a WordPress site	₹35,000–₹75,000
"It is slow" — measure first	₹0–₹15,000 in most cases
Rebuild off a closed builder onto WordPress	₹35,000–₹75,000 + content carry
Rebuild that adds logins, roles or payments	₹1,00,000+

The four inheritances

Inheritance	Redesign	Rebuild	Reversible?
URLs	Kept, free	Lost by default	No, in practice
Content	Kept, free	Re-entered page by page	Yes, expensively
Data	Untouched	Mapped migration	No
Accounts	Untouched	Must be transferred	Yes, slowly

1. URLs — the 301 map is a deliverable, not a task

Ask for it as a file, before you sign. Every existing URL on the left, its destination on the right.

Building the left column properly means unioning three sources, because none of them is complete on its own:

• sitemap.xml — what the CMS thinks exists.
• Search Console → Pages → the indexed list — what Google actually has.
• The access log — what real traffic hits. On an old site this is where the surprises are: PDFs, old campaign landing pages, /index.php-style paths, an /amp/ variant nobody remembers shipping.

# distinct paths real traffic actually requested, most-hit first
awk '{print $7}' /var/log/nginx/access.log \
  | sed 's/?.*//' | sort | uniq -c | sort -rn | head -200

Rules that save you later: map to the closest equivalent page, never blanket-redirect everything to / (Google treats a mass redirect to the homepage as a soft 404 and you keep none of it), chain nothing more than one hop, and publish the map with the new site rather than a week after. Then watch crawl errors weekly for a month — the map is never complete on day one, and the log tells you what you missed.

This is the line most often absent from an Indian rebuild quote, and it is the one whose absence is invisible until traffic drops.

2. Content — decide who types it in, in writing

"We will migrate the content" is not a scope line, it is an ambiguity. Page-by-page re-entry is real hours and it is the item most often silently handed back to the client mid-project, which is also the single biggest cause of a slipped date. Put the answer in the document: who types it in, you or me?

3. Data — the only irreversible one

Not "we will move the data". The line should read: export → field map → import → reconcile row counts → spot-check N records together.

-- run on both databases after the import; the numbers must match
SELECT 'enquiries' AS t, COUNT(*), MAX(created_at) FROM enquiries
UNION ALL SELECT 'orders', COUNT(*), MAX(created_at) FROM orders
UNION ALL SELECT 'users',  COUNT(*), MAX(created_at) FROM users;

Then the cheapest insurance in the whole project: keep the old database live and read-only for 90 days after cutover, on a staging address. It costs almost nothing and it is the difference between an inconvenience and a catastrophe. Silent truncation of a TEXT column into a VARCHAR(255), timezone drift on created_at, dropped rows where a NOT NULL was added — none of these announce themselves, and all of them are recoverable if the source is still there.

Watch the encoding too. A lot of older Indian WordPress installs are utf8 (3-byte) rather than utf8mb4, so anything with an emoji or certain Indic sequences will silently mangle on the way into a stricter target.

4. Accounts — not technical work, and the usual reason it stalls

Registrar, hosting panel, DNS, analytics, Search Console, payment gateway, repository, and any transactional email or SMS sender. None of this is engineering. All of it is other people's queues — registrar transfers and gateway KYC in India routinely take a week each — and it is the single most common reason a rebuild sits stalled for three weeks with the code already finished.

Start it in week one, with every account created in the client's name and the developer added as a user. Not zipped up and handed over at the end.

Two more worth naming: keep the existing GA4 and Search Console properties rather than creating new ones — history is free to keep and impossible to recreate — and annotate the cutover date so that six months later you can tell a rebuild effect from a seasonal one.

Two dates that belong in the plan, not in the retro

3 October. If the client capitalises the rebuild as software, it is depreciated at 40% WDV rather than deducted, and the second proviso to section 32(1) of the Income-tax Act halves depreciation where an asset is put to use for under 180 days in the year. In an ordinary Indian financial year, 3 October is the last day that still completes 180. On ₹1,50,000 that is ₹60,000 of year-one depreciation if you go live on 3 October and ₹30,000 if you go live on 4 October. Same code, same invoice, one calendar day. A redesign treated as revenue expenditure under section 37 is usually deductible in full and is unaffected — in CIT v. Indian Visit.com (P.) Ltd. the Delhi High Court held website spend produces no accretion to fixed capital. Classification follows what was actually done, never the noun on the invoice. (General information, not tax advice — worth an hour of the client's CA.)

13 May 2027. The DPDP Act 2023's substantive obligations on ordinary Indian data fiduciaries are set to apply from this date under the rules notified in November 2025. What it asks for is structural: a plain-language itemised notice available in English or any Eighth Schedule language at the user's option, consent as a specific affirmative action, withdrawal as easy as giving, and erasure afterwards. In schema terms that is somewhere to write a consent record, something to match a withdrawal against, and a delete path — plus the retention rule that makes the delete meaningful. If you are rebuilding anyway, build it once now instead of retrofitting in eighteen months. Treat the date as a planning date; the phasing has moved before.

The number that argues against my own business

A redesign that keeps the platform, the content and the URLs typically costs between a third and a fifth of a rebuild of the same site, and carries almost none of its risk. If the switch test comes back all-off — and "it looks dated and it is slow" comes back all-off — the honest answer is a redesign.

Especially "it is slow". On small Indian business sites that is almost always one of three cheap things, in this order: uncompressed images straight off a phone, oversubscribed shared hosting, and plugin bloat. Measure, fix those, measure again. A rebuild will certainly produce a fast site; so would ₹8,000 and a Saturday, and only one of those bills arrives twice.

And "we want better SEO" is backwards. A rebuild is the most reliable way to lose rankings, because it changes URLs. Rebuild for what the site must do, never for what you hope a search engine will do afterwards.

Full version with both price tables, the three-switch matrix and the tax breakdown: Should you redesign your website or rebuild it? (India, 2026)