--- title: "Why Your Website And Member System Still Feel Like Two Products" url: https://www.axelerant.com/blog/website-member-system-integration-order published: 2026-07-23T10:15:00Z author: "Bassam Ismail, Director of Digital Engineering" source: Axelerant Thinking --- # Why Your Website And Member System Still Feel Like Two Products > Members bounce between your website and member system like they are two products. Why iframes and quick SSO fail, and the integration order that works. A member finds the course on your website, clicks register, and lands somewhere else. Different navigation, different design, sometimes a second login. Certificates live in one system, resources in another. Your support inbox translates between the two. Everyone internally calls it "the portal," with a small sigh attached. The seam between the CMS and the member system is where journeys actually break. Not the homepage, not the brand. The seam. ## Why The Obvious Fixes Fail The iframe embed. Wrap the member system's screens in your website's frame and call it integrated. We evaluated this seriously on a recent engagement and rejected it, for reasons that will be familiar to anyone who has lived with one: iframes fight responsive layouts, modals and pop-ups misbehave inside them, dynamic content changes height unpredictably, and you inherit a set of security concerns you did not need. Members can tell. It reads as two products in a trench coat. The quick SSO bolt-on. Single sign-on removes the second login and nothing else. The member still teleports between two information architectures. SSO is necessary. It is nowhere near sufficient, and treating it as the finish line is the most common way these programs stall. The full rebuild-everything reflex. Rebuilding the member system's business logic inside the CMS sounds like the clean answer. It doubles the scope, duplicates rules that already work, and creates a second source of truth that drifts from the first within a quarter. The tool was never the problem. The sequence was. ## The Order That Works Decide who owns identity, once. The member system holds the memberships, certifications, and payments, so it should be the identity provider. On the engagement above, the AMS acted as the SAML identity provider; the web platform consumed identity, mapped member IDs to platform accounts, and synced roles at every login. One login, no duplicated identity, no drift. Split interactions into display and transaction. This was the decision that made everything else tractable. Anything a member reads, certificates, registrations, invoices, rosters, renders natively in the CMS through the AMS's APIs, inside one consistent experience. Anything with complex business rules, multi-step registration workflows, payment logic, stays in the AMS, reached by clean redirects under a unified header and footer. Members experience one system. Engineering maintains one set of business rules. Fix query performance before it fixes you. Raw record-by-record API calls against an AMS are too slow for page loads. The workable pattern is the AMS's structured query layer for shaped, purpose-built reads, plus a caching tier in front of it. This is unglamorous [Data Engineering](https://www.axelerant.com/what-we-do/engineering/data) and it is the difference between a portal that feels native and one that spins. Plan for the AMS having a bad day. Any integration this deep needs a failure posture. The engagement's answer was a circuit breaker: after repeated AMS failures, the platform stops calling it and serves cached or empty states instead of taking the whole site down. Members see a quiet degradation, not an outage. Phase the migration along the display-transaction split. Because reads move to the CMS independently of writes, you can migrate audience by audience without a big-bang cutover. Each phase generates real usage data that informs the next, which is the [data-informs-activation](https://www.axelerant.com/how-we-do/data) loop doing its job at the infrastructure level. ## What This Looked Like In Practice A large membership and certification organization ran exactly this sequence while replatforming from a legacy CMS. Identity stayed with the AMS as SAML provider. Member-facing reads, certificates, current registrations, invoices, company rosters, moved into the new platform through the structured query pattern with caching. Complex registration and payment flows stayed in the AMS behind consistent navigation. The iframe route was formally evaluated and formally rejected. A year after the engagement began, the organization launched on the new platform with the seam designed rather than inherited. ## The Honest Edge This pattern does not make the AMS better. Slow upstream queries get cached, not cured, and a product decision the AMS vendor makes can still land in your roadmap uninvited. The redirect boundary is also a permanent design constraint: those AMS-hosted flows will never fully match your design system, and pretending otherwise burns budget. What the pattern buys is control over where the seam sits and how gracefully it behaves, which is most of what members actually feel. ## What You Can Take From This Draw the display-transaction line for your own estate before you evaluate any tool. Which member interactions are reads you could own, and which are workflows that should stay in the system of record? That one-page exercise, done honestly, is the real scope of your integration project, and it starts with the [data layer](https://www.axelerant.com/how-we-do/data). --- Read on the web: https://www.axelerant.com/blog/website-member-system-integration-order