Replacing a developer-locked CMS without slipping the launch
A developer had to touch the code before the organisation's own team could change a page, add a seasonal appeal, or update a program listing, because the legacy WordPress site gave staff no editing surface of their own. The engagement replaced it with fifteen-plus pages on HubSpot Content Hub, built from a branded module library staff could edit directly, and Phase 3 added a Resource Hub and training.
Executive Summary
Context
An Australian not-for-profit meal-delivery and community-care organisation ran its public website on a platform only a developer could edit. The second phase of its HubSpot roadmap replaced that site, and the launch date couldn't slip.
What We Built
We rebuilt the public site as fifteen-plus pages on a HubSpot Content Hub theme and branded module library that staff can edit directly. The build replaced the developer-dependent WordPress site and added multi-step forms, a Stripe integration on the Donate page, and a full redirect migration.
Tech Stack
- HubSpot Content Hub (CMS Hub Professional), branded custom module library, Marketing Hub multi-step forms, Stripe, 301 redirect migration from WordPress, Content Hub Resource Hub.
Not a fit if your team can't commit reviewer time mid-sprint. Staged design QA on multi-step forms needed sign-off from up to five people before each pass, and skipping that step is what lets punch-list work grow close to launch. It also assumes you have DNS-level control, so you can add a CNAME record and approve a redirect list before cutover.
The Challenge
The organisation ran its public site on WordPress, and every content change went through a developer, whether it was a new appeal or an updated program page, because the platform gave staff no editing surface of their own.
Phase 2 had a fixed scope: rebuild fifteen-plus pages, including donation and recruitment forms that had to keep collecting payments and referral traffic without a gap at cutover. The multi-step forms proved hardest to finish. Each needed sign-off from up to five Solutions staff, and that put the launch date at risk.
Our Approach
We considered finishing every multi-step form to the same polish as the rest of the site, but that risked slipping the committed launch date. So we moved design QA earlier in each sprint, which caught layout and logic issues before they reached the punch list. That traded a heavier review load mid-sprint for a lighter one at the end, and the build landed only 16 hours over estimate.
A branded module library built into the Content Hub theme kept every page editable by staff without a developer. Go-live followed a fixed sequence: a CNAME record at the client's DNS provider, then a redirect list that mapped every WordPress URL to its new address. Both went live at 2pm AEDT on 21 October 2024. Phase 3 added a Resource Hub, where we migrated three resources and trained staff.
Impact
Staff edit pages without waiting on a developer
The branded module library gives staff direct control over layout, imagery, and copy across fifteen-plus pages, so a funding update or a new appeal publishes the day it's needed. That closes the gap the WordPress site left.
The build held its launch date despite its hardest pages
Moving design QA earlier in each sprint caught issues in the multi-step forms before they reached the punch list. So the rebuild finished only 16 hours over estimate and launched on schedule at 2pm AEDT on 21 October 2024.
Every legacy link still resolves after the migration
A redirect list mapping each WordPress URL to its Content Hub equivalent went live at the same moment as the new site. Existing links, bookmarks, and search results carried straight through, and no visitor met a broken link.
The Resource Hub and Donate page keep running past go-live
Phase 3 migrated three key resources into a new Resource Hub and trained staff to keep it current on their own. Separately, the Donate page's Stripe integration processes a one-time or recurring gift without the donor leaving the site.
A custom theme and module library built inside HubSpot Content Hub replaced individually coded WordPress templates. Each module, such as a hero, a program listing, a form, or a donation panel, exposes editable layout and copy fields, so a non-developer can update a page without code.
The recruitment and donation pages run on multi-step forms, and each needed sign-off from up to five Solutions staff. We moved design review earlier in the sprint instead of leaving it to the end, which caught layout and logic issues before they reached the punch list.
The Donate page connects to Stripe to process one-time and recurring gifts, replacing the payment path the legacy WordPress site ran. A recurring donor moves through the same page without a separate checkout flow.
A 301 redirect mapping of every legacy WordPress URL to its Content Hub equivalent went live at the same moment as the new site. The client agreed the mapping before the CNAME switch, and it protects existing inbound links and search rankings.
The legacy WordPress site was replaced in October 2024 by the new site on HubSpot Content Hub. We mapped every legacy URL to its new address in a 301 redirect list, and the client approved that list before go-live. The switch itself was a CNAME record added at the client's DNS provider, which sent visitors to Content Hub with the redirects live at the same moment.
FAQ
Multi-step forms needed sign-off from up to five Solutions staff each, and finishing them at the same pace as the rest of the site risked pushing punch-list work close to the launch date. Moving design QA earlier in each sprint caught issues first, which is why the build landed only 16 hours over estimate.
We built a redirect list mapping every legacy WordPress URL to its new Content Hub address. The client approved it before the CNAME switch, and it went live at the same moment as the new site, so existing links and search results carried through.
