Migrate off jQuery without freezing feature work for 18 months.
Incremental, route-by-route migration from jQuery, Backbone, Knockout, or server-rendered Rails/Django/.NET front ends to React, Next.js, or Remix. Dual-running, SEO-preserving, rollback-safe.
The 'big bang React rewrite' is how 18-month projects become 36-month ones.
We get called in after the rewrite has stalled. A team forked the jQuery app two years ago, started rebuilding everything in React with a new design system, a new API layer, and a new auth flow simultaneously. Meanwhile the legacy app keeps shipping features — payment integrations, compliance updates, customer-requested reports — and the React version falls further behind every sprint. Eventually leadership asks why they're paying to maintain two codebases that do the same thing, and the rewrite gets quietly killed. The jQuery app is still in production. This is the default outcome.
- ▸ Rewrite team can't catch up to feature velocity on the legacy app, so the new version never reaches parity.
- ▸ Business logic encoded in 5+ years of jQuery — tax rules, edge-case workflows — gets missed and ships as regressions.
- ▸ SEO rankings drop after cutover because client-rendered React pages aren't indexed correctly by Google.
- ▸ jQuery plugins like DataTables, Select2, and jQuery UI become migration blockers nobody planned for.
Strangle the jQuery app page-by-page. Never rewrite it.
- STEP-01
Inventory and route map first
We catalog every page, partial, and jQuery plugin in the existing app — usually 40-200 routes for a mid-size system. Each gets tagged by traffic, business value, and DOM complexity. High-traffic, low-complexity pages migrate first so we ship value in weeks, not quarters.
- STEP-02
Pick a real boundary: route-level or component-level
For server-rendered Rails/Django/.NET apps, we usually mount React per-route via a small bootstrap script and let the legacy router stay in charge. For SPAs we use Module Federation or single-spa. We avoid iframes except as a last-resort containment for risky vendor widgets.
- STEP-03
Dual-run with shared session and feature flags
Both stacks read the same session cookie, CSRF token, and auth headers. LaunchDarkly or a homegrown flag service routes a percentage of users to the React version per route. Rollback is a config flip, not a deploy. We keep this dual-run window short — typically 2-6 weeks per route.
- STEP-04
Preserve SEO and analytics from day one
Public pages get SSR via Next.js or Remix, or we keep server rendering and hydrate React islands. Canonical URLs, meta tags, structured data, and GA/GTM event names match the legacy app exactly. We diff Lighthouse and Search Console weekly during cutover to catch ranking drops early.
- STEP-05
Kill jQuery plugins deliberately
Datepickers, DataTables, Select2, and jQuery UI dialogs are the long tail. We replace them with React equivalents (TanStack Table, Radix, react-day-picker) only when the host page migrates — not preemptively. Premature replacement creates two versions of the same widget running side by side.
// bootstrap.tsx — mount React into a server-rendered page without taking over routing
import { createRoot } from 'react-dom/client';
import { StrictMode } from 'react';
type MountSpec = { selector: string; loader: () => Promise<{ default: React.ComponentType<any> }> };
const registry: Record<string, MountSpec> = {
'invoice-table': {
selector: '[data-react="invoice-table"]',
loader: () => import('./islands/InvoiceTable'),
},
'customer-search': {
selector: '[data-react="customer-search"]',
loader: () => import('./islands/CustomerSearch'),
},
};
document.querySelectorAll<HTMLElement>('[data-react]').forEach(async (el) => {
const key = el.dataset.react!;
const spec = registry[key];
if (!spec) return;
const props = JSON.parse(el.dataset.props ?? '{}'); // server-rendered props
const { default: Component } = await spec.loader();
createRoot(el).render(
<StrictMode>
<Component {...props} />
</StrictMode>,
);
});
// Legacy jQuery still owns the rest of the page. No router hijack, no global state collision.Island-style mounting lets React take over one widget at a time while Rails/Django/.NET keeps rendering the shell — the safest first step in a jQuery-to-React migration.
Field FAQ.
→ Why not just rewrite the whole thing in React from scratch?
Because rewrites of 5+ year old jQuery apps almost always overrun by 2-3x and ship with regressions in business logic that took years to encode. The legacy app has handled edge cases — tax rules, partial refunds, weird CSV exports — that nobody documented. Strangler-fig migration keeps the working system live, ships value every sprint, and lets you stop migration partway if priorities shift. Full rewrites also block all new feature work for the duration, which is rarely acceptable to the business.
→ How do you handle SEO when migrating public-facing pages?
Three rules. First, public pages must render HTML on the server — either via Next.js/Remix SSR or by keeping the existing server templates and hydrating React islands. Client-only React on indexed pages is a ranking risk. Second, canonical URLs, title/meta/OG tags, and JSON-LD structured data must match the legacy output byte-for-byte at cutover. Third, we monitor Search Console and a Lighthouse CI pipeline weekly during the dual-run period so any Core Web Vitals or indexing regression is caught within days, not quarters.
→ Should we use Next.js, Remix, Vite + React, or something else?
Depends on the app. Public marketing or e-commerce front ends with SEO needs go to Next.js or Remix for SSR/streaming. Internal admin tools and authenticated dashboards usually go to Vite + React Router — faster builds, simpler mental model, no SSR complexity you don't need. If you're already on a monorepo with multiple teams, Module Federation or single-spa is worth considering. We pick based on rendering needs and team size, not on what's trending on Hacker News.
→ What about jQuery plugins like DataTables, Select2, and jQuery UI?
These are the long tail and they're where most migrations stall. Our rule: replace a plugin only when the page hosting it migrates. DataTables maps cleanly to TanStack Table or AG Grid. Select2 maps to Downshift or react-select. jQuery UI dialogs map to Radix or Headless UI. Datepickers to react-day-picker. Don't try to wrap jQuery plugins inside React components long-term — the lifecycle mismatch causes memory leaks and event handler bugs that are painful to debug.
→ How do you avoid breaking the legacy app while React is being added?
Strict isolation. React mounts only inside designated DOM nodes marked with data-react attributes. We never let React tear down or reach outside its container. Global jQuery selectors stay scoped to legacy partials. Shared state — auth, feature flags, current user — flows one direction: server renders props into the DOM, React reads them on mount. No two-way binding between jQuery and React in the same widget. That single rule prevents 90% of the dual-stack bugs we've seen.
→ How long does a typical jQuery to React migration take?
For a mid-size app — call it 60-150 routes, a few hundred thousand lines of mixed server templates and jQuery — we typically see 6-14 months elapsed for full migration with a team of 3-5 engineers, while shipping new features the whole time. The first migrated route is usually live in 4-6 weeks. We've seen organizations stop at 70-80% migrated because the remaining routes were low-traffic admin screens not worth the effort, and that's a legitimate outcome.
→ Can you do this work under an SDVOSB federal contract?
Yes. VooStack is SDVOSB-certified and registered in SAM.gov, eligible for sole-source awards up to the SDVOSB threshold and for set-aside competitions. We've modernized legacy front ends running on government infrastructure including FedRAMP-authorized environments. We're familiar with Section 508 accessibility requirements, which actually become easier to meet during a React migration since modern component libraries (Radix, React Aria) ship with accessibility primitives built in. Reach out via /contact for contracting vehicles and past performance.
→ What's the right team structure during migration?
One team owns the migration platform — bootstrap loader, shared component library, build pipeline, feature flag plumbing. Feature teams own their own route migrations using that platform. This avoids the failure mode where a central 'modernization team' becomes a bottleneck and feature teams resent them. We typically embed a senior engineer with the platform team for the first 8-12 weeks to set conventions, then hand off. Staff augmentation makes sense here when internal teams haven't done a migration this size before.
→ How do you handle shared state, auth, and CSRF across both stacks?
Auth stays with the server. The legacy session cookie is the source of truth — React reads the current user from a JSON blob the server renders into the page on initial load, or from a /api/me endpoint. CSRF tokens are read from a meta tag the server already emits and attached to fetch calls via an interceptor. We don't introduce a separate React auth system during migration; that's a project for after cutover, if at all. Keep the auth surface area unchanged until the legacy stack is gone.
Continue recon.
Modernization services
Full scope of legacy-to-cloud and front-end modernization engagements we run.
REL-02Migration case studies
Real route-by-route migrations we've shipped, including timelines and rollback events.
REL-03Migration assessment package
Two-week fixed-fee audit producing a prioritized route migration plan.
REL-04Talk to an engineer
Skip the sales call. Get a working session with someone who's done this.
Get a route-by-route migration plan for your jQuery app — not a rewrite quote.
Talk to a VooStack operator. We respond within one business day.