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 the pages built from them 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.
The sequence mattered as much as the gate. Three roadmapping workshops in April and May 2023 covered the competitor set, buyer personas and the information architecture before any module was touched, so the 26-module migration was scoped against an agreed structure rather than page by page. Phase 1 closed in two milestones, August and September 2023, with staff trained on the drag-and-drop editor alongside the build. The custom pages that followed, a new homepage and mega menu, platform overview, resource hub, partner directory and developer pages, went live in April 2024 on the same redirect discipline.
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 rebuild on HubSpot's drag-and-drop 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 kept broken links and missing redirects away from search engines.
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.
A straight cutover to HubSpot's CMS would have broken the links search engines had already indexed. So the client supplied a list pairing every current URL with its replacement, and we built the redirect map from those known pairs. The broken-link and 301 gate now has to clear before the site opens to search engines. It couldn't catch links written as absolute addresses, because they still pointed at the old site, so we found them by hand and gave the list to the client to fix.
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.
