When to migrate off Carrot and when to stay

Every scaling Carrot operator eventually types the same question into a search bar: is the platform my ceiling, or am I? The honest answer splits. For most operators, staying on Carrot is the right call, and this article will say so plainly. For a specific, measurable profile, staying caps compounding organic returns year after year. The operator writing this ran his own cash-buying site on Carrot, moved it to a second managed platform, and finally migrated to a custom build with rankings preserved. He also sells the migration service — which means the "stay" answer below is advice against interest. By the end you will know what Carrot genuinely does well, where its defaults bind at scale, and which sites should never migrate. You will also know which sites pay a ceiling tax by staying, how rankings survive a migration, what a custom build really costs, and the 16-item checklist that runs the whole process.

What does Carrot do well?

Carrot ships a working cash-buyer site in days with hosting, lead capture, templates, and conversion-tested copy handled fully for you. For a brand-new operator without technical help, that launch speed and managed infrastructure remains genuinely hard to beat in 2026.

This section is written from experience, not observation — Yuba Home Buyer ran on Carrot before any migration happened. What the platform delivers is real. A new operator gets a working site in days: hosting, SSL, forms, mobile templates, and copy patterns refined across thousands of investor sites. The conversion testing alone is a genuine moat. Carrot has run more landing-page experiments on motivated-seller traffic than any single operator could fund in a career, and its defaults encode those results. The ecosystem compounds the value — training, an active community, integrations, and support that answers when a form breaks at 9 p.m. before a seller appointment.

The honest claim that follows from this: for a brand-new operator without technical capacity, Carrot’s defaults are a better decision than a cheap custom build done badly. A bad custom site loses to a default Carrot site on every surface that matters — conversion, reliability, time-to-launch, and total cost of ownership. Anyone who tells you Carrot is a mistake for a first-year investor is selling something and skipping the part where ownership requires capacity.

The platform’s defaults are optimized for a specific job: getting an operator from zero to lead-capturing fast, at a subscription price in the $99–$149 monthly range. They do that job well. The question this article actually answers is never "is Carrot good." It is "where do defaults stop compounding" — and the answer to that one has three measurable parts.

What does Carrot do poorly at scale?

At scale Carrot’s defaults cap three surfaces: Core Web Vitals scores trail custom builds by twenty to fifty measured Lighthouse points, template copy deduplicates across fifty thousand similar sites, and default installs ship near-zero entity density beyond Organization and WebSite.

All three ceilings are defaults trade-offs, not defects. A platform optimizing for launch speed across tens of thousands of sites cannot simultaneously optimize each site’s ranking ceiling — that trade is structural, and Carrot made it deliberately.

The first ceiling is performance. A June 2026 audit of five showcase Carrot domains scored mobile Lighthouse between 47 and 76, against 97 on the operator’s custom build, with Largest Contentful Paint running 2 to 2.6 seconds slower on the shared-template stack. The full methodology and numbers live in the Carrot Core Web Vitals reality check. Shared infrastructure serves the platform’s economics; it cannot serve any single site’s speed budget.

The second ceiling is template deduplication. Search and AI retrieval systems deduplicate at the passage level, and tens of thousands of near-identical service-area templates collectively contribute roughly one passage’s worth of retrievable content. The variance in outcomes within Carrot is operator-driven, not platform-driven — operators who replace template copy with original content escape the dedup penalty page by page.

The third ceiling is entity signal. The same June 2026 audit scored entity density across the showcase cohort: four of five default installs measured a density of 1 with zero sameAs declarations, while the one operator-customized install scored 8. Default installs ship Organization and WebSite nodes and little else — no Person entity, no credential anchor, no LocalBusiness granularity.

Note what the customized install proves: the gap is operator customization, and two of the three ceilings can be partially raised inside the platform. The performance ceiling cannot. That asymmetry is what the migrate-vs-stay decision actually turns on.

Which sites should never migrate?

Sites still validating their market, operators without technical help or budget beyond five thousand dollars, and businesses whose leads come from PPC rather than organic should never migrate. A migration spends months and money fixing a problem they don’t have.

This is the section a Carrot loyalist should read first, because it agrees with them. Four profiles should stay put.

First, operators still validating their market. If deal flow is uncertain, platform optimization is premature optimization. The constraint is acquisition skill and market knowledge, and no website migration moves either.

Second, PPC-and-direct-mail-led businesses. If organic search is a side channel rather than a revenue engine, the migration ROI math never closes. A faster site with deeper schema improves a channel that wasn’t producing — the spend belongs in the channels that are.

Third, operators without technical capacity or a realistic budget. A migration is months of attention plus four figures minimum, and a half-finished migration is worse than either steady state: rankings disrupted, redirects incomplete, two systems half-maintained. If no one on the team can own a custom site after launch, the platform’s managed surface is worth its subscription.

Fourth, operators inside their first 12 to 18 months. The conversion learning embedded in Carrot’s tested templates is worth more to a new business than marginal Core Web Vitals points. Speed compounds rankings; conversion competence compounds a business.

One anti-pattern deserves a name: migrating because a competitor did, or because a PageSpeed score embarrassed you, with no organic revenue thesis underneath. A Lighthouse number is a diagnostic, not a strategy. If none of the profiles in the next section describe your site, the rest of this article is reference material — staying is the right call, and everything else on this site works on Carrot too.

Which sites leave ranking on the table by staying?

Operators with proven organic demand leave ranking on the table by staying: sites earning growing impressions despite template deduplication, hyperlocal entities capped by shared template infrastructure, and teams whose customization spend already exceeds what a custom build would cost annually.

The mirror profile has four markers, and they are measurable rather than vibes.

First, proven organic demand. If Google Search Console shows impressions rising quarter over quarter despite the dedup handicap, the site is winning with a weight vest on. Demand already proven under a ceiling is the single strongest migrate signal.

Second, hyperlocal entity strength capped by shared infrastructure. An operator who owns the local query space at the entity layer — the concentration thesis from the backlinks vs entity signals framework — but serves it through shared templates is suppressing exactly the compounding that concentration earns.

Third, customization spend above ownership economics. Operators paying for add-ons, custom work inside the platform, and premium tiers can quietly exceed the annualized cost of owning the asset. The math gets concrete in the next section.

Fourth, AI-surface ambition. LLM retrieval systems cite heavily customized installs and custom builds — named author entities, original passages, complete schema. Default templates structurally cannot earn those citations.

One lesson from the operator’s own history belongs here. Yuba Home Buyer’s path was not one hop but two: Carrot to Grumpy Hare, then Grumpy Hare to a custom Next.js build. Switching managed platforms did not remove the ceiling — the second platform inherited the same defaults economics, because the ceiling lives in the model, not the vendor. Only ownership changed the surface. The post-migration profile shows what removal looks like: PageSpeed holding 96–100, position 1.31 on the canonical brand query, and a verbatim Perplexity citation on the canonical city query. The test, then: run the four-tier self-audit from the framework above, and if Tiers 1 and 2 are maxed inside the platform while the binding constraint is the platform itself, the migrate branch is open.

How do you preserve rankings through a migration?

Preserve rankings by freezing the URL map first, shipping one-to-one 301 redirects for every indexed URL, carrying entity schema across with identical @id anchors, and verifying canonical consistency before launch. Most migration ranking losses are self-inflicted redirect and canonical gaps.

The playbook below has run twice on the operator’s own sites. It has five moves, in order.

Freeze the URL map first. Before any build work, crawl the live site and export every indexed URL and its query profile from Search Console. That frozen map is the contract every later phase verifies against — skip it and there is nothing to verify a launch against.

Ship one-to-one 301 redirects. Every indexed URL redirects to exactly one destination. No chains, and no wildcard collapses that flatten pages which earned rank into a single target. The second operator migration carried 161 city pages across on an explicit one-to-one map; pages being deliberately retired were handled individually with rank recovery verified afterward.

Carry the entity across with identical @id anchors. Person, Organization, LocalBusiness, and Service nodes get reconstructed on the new stack so the Knowledge Graph sees continuity, not a new entity — the node structure from Organization schema for cash-buying LLCs, sitting on the entity-based SEO foundation. The credential anchor is the invariant thread: the same DRE-anchored identity survived both migrations.

Verify canonical consistency at launch. One protocol, one host, everywhere. This step earns a named pitfall from the operator’s own record. The second migrated site indexed both its www and non-www variants post-migration, splitting entity authority across two addresses — 38 and 16 clicks scattered across 24,038 and 11,646 impressions. The operator-side measurement infrastructure caught it. That is the self-inflicted loss class this entire section exists to prevent.

Watch for 90 days. Indexing API submission at launch, URL Inspection verification inside 72 hours, then GSC diffs against the frozen baseline at weeks two, four, and eight. The evidence this works: the hyperlocal site’s primary city ranking dipped through the transition, recovered on schedule, and now sits above its pre-migration position.

What does a Next.js investor site cost to build and maintain?

A custom Next.js investor site costs roughly three to eight thousand dollars to build at agency rates and ten to forty dollars monthly to run on modern hosting. The maintenance trade: you own every ranking surface Carrot’s subscription previously managed.

Most articles in this niche refuse to print numbers. Here are the real ones, with their assumptions stated.

Build cost runs $3,000 to $8,000 at typical agency rates for an investor site done properly. That range buys the four-tier entity schema baseline wired in as architecture, lead capture with event tracking, a content management system the operator can use without a developer, and performance engineered to a budget rather than inherited from a template. The low end assumes a focused hyperlocal site; the high end covers statewide scope with city-page programs. Cut-rate builds below this range usually skip the schema and measurement layers, which produces exactly the bad-custom-site outcome that loses to a default Carrot install.

Run cost is where ownership economics surprise people: $10 to $40 monthly on modern hosting, using a deployment platform and a headless CMS whose free-to-low tiers comfortably carry an investor site’s traffic. Both of the operator’s migrated sites run inside that band while holding 96–100 PageSpeed. Compare against the $99–$149 monthly platform subscription, plus whatever customization add-ons have accumulated on top of it.

The break-even math: a $5,000 build amortized over 24 months plus $25 monthly run cost is roughly $233 per month across the period. That lands near the platform’s subscription before counting add-on spend — and drops far below it from month 25 onward, when the platform fee would simply continue forever.

Now the honest column. What you give up is real: managed templates, platform support, and conversion-tested defaults that update without your attention. Custom means someone must care for the site — "set and forget" is a Carrot feature, not a custom-build feature. What you gain is every ranking surface: Core Web Vitals, schema, content architecture, and the asset itself. The cost question is never which number is smaller. It is which constraint is binding.

What’s on REI Spark’s migration checklist?

REI Spark’s migration checklist runs four phases: pre-migration crawl and URL-map freeze, entity schema reconstruction with preserved @id anchors, one-to-one redirect shipping with launch-day canonical verification, and a full ninety-day GSC watch against the pre-migration baseline. Sixteen checklist items total.

This is the working checklist behind both operator migrations — four phases, four items each.

Phase 1 — Pre-migration. One: full crawl of the live site, every URL inventoried. Two: GSC export of indexed URLs and their query profiles — the frozen baseline. Three: schema inventory of every entity node and @id on the old stack. Four: analytics parity plan, so every event the old site fired has a named successor.

Phase 2 — Build. Five: the URL map honored one-to-one in the new architecture. Six: entity schema reconstructed with identical @id anchors. Seven: a Core Web Vitals budget enforced per template, including no priority loading on below-fold images. Eight: a staging crawl matched line-by-line against the frozen map.

Phase 3 — Launch. Nine: 301 redirects shipped and spot-verified the same day. Ten: canonical and host consistency check across every page — the www lesson, applied. Eleven: sitemap submitted. Twelve: Indexing API batch across the full URL set.

Phase 4 — Watch. Thirteen: URL Inspection verification pass inside 72 hours. Fourteen: GSC diffs against the frozen baseline at weeks two, four, and eight. Fifteen: entity continuity check — brand SERP and Knowledge Panel surfaces. Sixteen: the 90-day signoff, or the rollback decision if the baseline says so.

Operators who match the leave-rank-on-the-table profile and want this executed rather than DIY’d can apply for a Custom Website Build — the same playbook, run by the operator who built it, one investor per market. And the mirror honesty from earlier holds: if you matched the never-migrate profile, staying is the right call, and every framework on this site works on Carrot too.

The migrate-vs-stay question resolves to one test: is the platform the binding constraint on proven organic demand, or is operator layering still the gap? Carrot earns its subscription for launch-stage operators. It caps compounding for hyperlocal entities with demonstrated impressions growth. If you migrate, rankings survive on discipline — frozen URL map, one-to-one 301s, entity continuity through identical @id anchors, canonical hygiene, and a 90-day watch. The deeper mechanics live in the backlinks vs entity signals framework and the entity-based SEO foundation. The platform is a tool, not an identity. Match the tool to the stage.

By YK Kuliev, California DRE #02006033. Platform history and migration data are from the author’s own sites; cohort data captured 2026-06-11.