CAQH

The brief

CAQH needed a lighter, cleaner CMS setup while also supporting custom functionality for users. On paper that can look like two workstreams: migrate the public site and separately support the portal experience. In practice, those two systems shape each other.

If the public site becomes easier to edit but the portal experience feels disconnected, the platform still feels fragmented. If the portal solves user needs but the publishing layer becomes more chaotic during migration, the operating team inherits the cost. The project only works when the whole environment feels coherent to both editors and end users.

That was the real brief: simplify the platform without simplifying the problem.

What made it more complex than a normal migration

Migration projects often get scoped around page counts, template conversion, and launch parity. Those things matter, but they are not the whole risk profile.

Here, the harder questions were operational:

• How do you move content out of Drupal without bringing years of structural mess into the new system?
• How do you keep the publishing experience predictable for editors while the platform underneath is changing?
• How do you support a custom portal experience without making the surrounding architecture feel improvised?

Those questions tend to decide whether a migration becomes a cleaner next chapter or just a new stack carrying old habits.

The approach

I worked from the assumption that the public site and the portal experience had to feel like parts of the same system, even if they behaved differently. That changed how I thought about the work.

Instead of treating migration as a content move and the portal as a separate product surface, I treated both as architecture problems with shared constraints: maintainability, clarity, and user trust.

• Mapped the migration so the CMS move did not introduce content chaos.
• Rebuilt the site in HubSpot with an emphasis on maintainable templates and predictable editing patterns.
• Supported a custom portal experience that extended the platform instead of fighting it.

That meant being deliberate about where logic lived, which editing patterns would be reused, and how much operational burden the new implementation would create after launch.

How the work stayed grounded

The migration itself needed discipline. Public content systems often carry a lot of hidden duplication, historical structure, and naming that only made sense to the previous implementation. Moving that blindly into a new CMS is one of the fastest ways to lose the benefit of a rebuild.

So the work focused on making the content layer more governable, not just more modern. The goal was to give the team a publishing environment that felt easier to reason about after launch, not just a better looking interface on day one.

The portal side had a similar standard. Custom functionality can easily feel bolted onto a CMS project when the architecture is segmented too aggressively. I wanted the user-facing experience to feel intentional and connected, even where the implementation details differed from the public marketing surface.

Why it worked

The project stayed grounded in operational reality. Editors needed a system they could use confidently, and users needed a portal experience that felt intentional rather than bolted on.

That sounds obvious, but it is exactly where migration work often drifts. Teams get pulled toward launch parity, visual cleanup, and technical handoffs. Those matter, but they are not the same as building a system that people can operate with confidence afterward.

By keeping the publishing layer, portal expectations, and implementation boundaries aligned, the result was a platform that could do more without feeling more fragile.

What this case study really demonstrates

This project is a useful example of the kind of work I do because it sits at the intersection of content systems, product behavior, and technical delivery. It was not only a CMS rebuild and not only a custom functionality effort. It was a platform-alignment problem.

Those are usually the projects where architecture matters most, because the wrong decision does not just affect developers. It affects editors, operators, and end users all at once.

The takeaway

The best migration projects simplify the platform while still expanding what it can do. That was the goal here, and it is why this work is worth showing as a case study instead of just a line item.

The visible deliverable was a cleaner CMS and a supported portal experience. The more important outcome was that the stack became more coherent instead of more layered. That is usually the difference between a successful migration and a future maintenance problem with a nicer interface.