Migrating a Live Site Off a Proprietary Platform

Challenge

A multi-market client's site was built on a proprietary website platform that renders much of every page from its own JavaScript at runtime. The business had outgrown it. Moving off meant rebuilding 108 pages and 39 blog posts on a new stack without losing rankings, without losing the design, and without interrupting a lead flow that feeds a CRM across multiple market routings. The site sells the whole time. There is no window in which it is allowed to be down or wrong.

Solution

We treated the existing site as the specification rather than as a starting point, and we built the checks before we built the pages.

Parity is measured, not eyeballed. Every page on the new build is compared against its counterpart on the old one for HTTP status, title, meta description and H1. The build sits at 107 of 108. The single exception is a page where the old platform emits two H1 tags, and we reproduce that deliberately rather than quietly improving it, because a migration is the worst possible moment to introduce a change you will later have to separate from the migration's own effect.

The legacy platform held 1,137 redirect rules accumulated over the life of the site. Those were exported and preserved, and they are in version control because they cannot be regenerated once the old subscription lapses. If a legacy redirect table is not carried across, every rule in it becomes a broken chain or a 404 on launch day.

Then the finding that paid for the whole exercise. Roughly 22 form conversion tags, across every market and service, fire on a pageview of a single /thank-you page. That page returns 200. It is not in the sitemap. It is not in the page inventory. Nothing on the site links to it. It exists only as the trigger. No crawl would ever find it, and the site would have migrated cleanly without it: pages ranking, forms submitting, leads arriving in the CRM, and every conversion number in the ad platform and in analytics reading zero from launch day forward, with no error anywhere to explain why. We found it by reading the tag container instead of the site. It was rebuilt, the form now redirects to it, and all 22 tags kept working with no changes to the container at all.

We also learned how much the old platform's runtime had been doing invisibly. Stripping its JavaScript silently killed seven per-market review widgets, the lead form, the photo gallery lightbox, the gallery category tabs, and the FAQ accordions on 48 pages. Every one of those still rendered. They simply did nothing. The rule that came out of it now applies to every platform move we touch: if a component looks present but does not respond, assume its runtime was stripped, and go find the others.

Deployment is automated, because hand-deploying during a migration is how sites break. One command backs up the live theme, syncs, lints every PHP file on the server, rolls back automatically if anything fails to parse, purges all three caches, and verifies a set of representative pages still return 200. The rollback is tested rather than assumed. We deliberately shipped an unclosed brace to prove it, and it was caught and reverted with the site never going down.

Result

In progress as of this writing, and we would rather say that than round it up. The rebuild is live on staging with parity verified, the legacy redirect inventory is exported and held, and the conversion path is proven end to end. Cutover is still ahead of us. What we would put in front of you is not the outcome, which we do not have yet. It is the list of things we found before cutover, each of which would have stayed invisible until it was expensive.