HubSpot CMS migration with a redirect launch gate for a payments platform
An Australian recurring-payments platform for merchants needed its ageing website rebuilt on a new content system without losing the search rankings the old site had already earned. We engineered the launch as a checkpoint instead of a hopeful cutover. The client supplied a list of every current URL against its replacement, we built a redirect map from that list, and a broken-link gate had to clear before the new site was unlocked to search engines.
Executive Summary
Context
The platform's public site ran on twenty-six modules inside an older HubSpot setup, and each module carried search visibility that a rebuild could easily have reset. Those modules needed a new home on HubSpot's drag-and-drop CMS, and they had to be migrated and handed over in one launch window instead of page by page.
What We Built
We rebuilt twenty-six website modules on HubSpot's drag-and-drop CMS. In place of an ad hoc cutover, we added a matched-URL redirect map and a broken-link and 301-redirect gate that the site had to clear before going live.
Tech Stack
- HubSpot CMS, SEMrush, Google Analytics 4
Not a fit if you cannot supply a complete, matched list of your site's current and target URLs before launch: the redirect map and the broken-link gate that protect your search rankings are built from that list, not inferred from a crawl. It also assumes one nominated contact who can aggregate every launch-week fix request, because a fixed launch date cannot absorb fixes arriving through more than one channel.
The Challenge
The platform's website ran on twenty-six modules, and rebuilding it on HubSpot's drag-and-drop CMS meant every module would get a new template and, in many cases, a new address. A straight cutover would have broken the links that search engines had already indexed, and it would have reset months of ranking history overnight.
So launch couldn't be a single moment. The delivery team needed a way to catch every renamed or moved URL before a search crawler ever saw a broken link.
Our Approach
We built and fixed every module first, and we treated the site as ready only once that pass was complete, instead of launching page by page. Before cutover, the client supplied a matched list of every current URL against its planned replacement. That list became the key we built the redirect map from, so the redirects came from known pairs and not from assumptions about likely renames.
The site moved to the client within twenty-four hours of build sign-off. A broken-link check and 301 redirect mapping had to clear before the new site went live to search engines, which put the burden of proof on the migration and not on a post-launch fix cycle.
The gate caught every redirect that the matched list could express, but it couldn't catch links written as absolute addresses, because those still pointed at the old site. We found them by hand and gave the list to the client to fix after go-live. One nominated contact gathered every launch-week fix request against a fixed close date, so late requests didn't push launch back.
Impact
Search rankings carried through the platform switch
Because the redirect map matched every renamed URL before launch, the new site inherited the old one's indexed pages instead of starting a ranking history over. The switch to HubSpot's CMS didn't cost the business the search equity that twenty-six modules had built up.
A full platform migration handed over in a single day
The handover ran inside twenty-four hours once the production team signed off. The gate had already forced every redirect and broken link to surface before that point, so go-live was a scheduled event and not an open-ended cutover.
The client's own team could run the new CMS from day one
Staff were trained on HubSpot's drag-and-drop CMS alongside the migration. Page updates after launch didn't depend on the delivery team's continued involvement.
A single contact caught every launch-week fix request
A single nominated contact gathered every punch-list item against a fixed close date, so last-minute fixes didn't extend the schedule. The project closed out its second milestone on the date the statement of work had set.
The client supplied a list of every current URL paired with its post-migration destination, and we built the map from it. The map is the single source the launch gate checks against, instead of a set of assumed or crawled redirects.
The new site couldn't go live to search engines until a broken-link check and a complete pass of 301 redirect mapping cleared against the map. A failed check blocked launch, which protected the crawl-budget recovery that the gate exists for.
Once the production team's build and fix pass was complete, the site moved to the client inside a single twenty-four-hour window. That kept the handover a scheduled event tied to sign-off instead of an open-ended cutover.
One nominated client contact gathered every launch-week fix request against a fixed punch-close date. Duplicate or conflicting requests didn't reach the production team directly, and late fixes didn't push the launch date.
The client supplies a list pairing every current URL with its replacement, and the redirect map is built from that list. The production team's build and fix pass hands the site over within twenty-four hours, and a broken-link and 301-redirect gate has to clear against the map before the new HubSpot CMS site is unlocked to search engines. Links written as absolute addresses still point at the old site, so they go to a manual fix step after launch. A single punch contact feeds every launch-week fix request into one fixed close date.
FAQ
Rankings depend on the URLs that search engines have already indexed. So the migration runs on a redirect map made from a matched list of your current and target URLs, not a hopeful cutover. That map and a broken-link check both have to clear before the new site is unlocked to search engines. The one gap the check can't close on its own is a link written as an absolute address, which we find by hand and the client fixes after launch.
It doesn't run as an extended freeze. Once the production team's build and fix pass is signed off, the site is handed over inside twenty-four hours. A launch-week punch window closes on a fixed date, so last-minute requests don't push the go-live date back.
