Migrating a Live Product from jQuery to Vue

The visitor side of Endless Fairs started life as server-rendered pages with jQuery sprinkled on top. It worked — until the product grew chat, video calls, live sessions and a dozen interactive modules, and every new feature meant hunting global selectors across a growing pile of scripts.

We migrated to Vue. The catch: real events ran on the platform every week. There was no "freeze development for a quarter" option.

How it actually went

Strangler pattern, not big bang. New features were built as Vue components mounted into existing pages. Old features were converted one at a time, usually when they needed changes anyway. For months, jQuery and Vue lived on the same pages — inelegant, but shippable every single day.

State first, widgets later. The most valuable early move wasn't converting UI — it was pulling shared state (the current visitor, the event config, socket connections) into one place that both worlds could read. Half the jQuery mess was different scripts each keeping their own copy of the truth.

The realtime layer forced the issue. Chat and live-session UI were the hardest to keep in jQuery — DOM patching on every socket message was slow and fragile. They became the first full Vue conversions, and the difference was immediate: declarative rendering turned "update these six elements carefully in order" into "change the data."

What I'd repeat

• Convert by feature, never by page. A page half-converted along feature lines still ships; a page frozen mid-rewrite doesn't.
• Keep a kill list — every global selector and inline script you delete goes on it. Watching that list shrink kept morale up for months.
• Resist prettying up old code you're about to delete. Every hour spent polishing doomed jQuery is an hour stolen from its replacement.

The rewrite nobody notices is the successful one. Visitors never saw a migration — they just saw a product that stopped feeling creaky.