The Problem Wasn't the Platform, It Was the Data
When a mid-market safety association—a 200-person organization managing thousands of members, certifications, and compliance records—decided to replatform from an aging Kentico CMS to Drupal, they faced a decision point that many digital leaders encounter but few talk about openly: do we migrate everything, or do we build a bridge?
On the surface, the answer seemed obvious. Eight years of accumulated content, member records, role-based access controls, and integrations with their legacy association management system (iMIS) created what felt like a migration imperative. The organization had grown accustomed to thinking of their digital infrastructure as a monolith—one system of record, one source of truth. But migrating 8 years of data wholesale would have introduced significant risk: data quality issues that only surface in production, broken relationships between old and new systems, and a multi-month implementation timeline that would have left the entire member portal in limbo.
More fundamentally, the client's actual business need wasn't a data migration. It was a modern, role-based member portal that worked reliably. The iMIS system—which had been managing their association data since the early 2000s—was doing its job adequately. What was failing was the content management layer, the member-facing experience, and the ability to control access granularly across six distinct user types: public visitors, registered members, instructors, administrators, auditors, and approved training partners.
This distinction—between a technical migration task and a business outcomes task—became the foundation of our approach.
Replatforming Without Full Data Migration: The API-First Decision
Rather than pursue a lift-and-shift data migration, we proposed an API-first integration architecture: keep iMIS as the system of record for member data, authoritative reference lists, and transactional records. Use Drupal as the presentation layer, the modern CMS, and the source of truth for content, user experience, and role-based access control. Connect them through a managed API layer that selectively synchronized data, verified permissions in real time, and allowed both systems to operate independently without constant bidirectional coupling.
This approach had several advantages. First, it eliminated the risk of a large-scale data migration—no ETL failures, no orphaned records, no post-go-live data cleanup. Second, it allowed the team to preserve the client's existing investment in iMIS. Third, it allowed both teams to work in parallel rather than sequentially. The legacy system could continue operating during the entire implementation without risk of disruption.
The constraint was complexity. Building an integration that was both selective and reliable required clear boundaries about what data flowed where, when, and under what conditions. That meant detailed API contracts, careful handling of authentication and authorization across two systems, and rigorous testing of edge cases.
Content Debt and Taxonomy Rebuild
Eight years of accumulated content on the Kentico platform had been organized in ways that made sense at the time but hadn't been systematically restructured as the organization evolved. Rather than transplanting an outdated information architecture to Drupal, we conducted a parallel content audit. The exercise revealed that roughly 40% of existing content was either outdated, redundant, or no longer referenced by members. We archived it and rebuilt the active content library with consistent metadata, clear ownership, and a taxonomy that reflected actual member workflows.
This meant a student in a training program saw different content than an instructor, and an auditor saw different content than both. This level of granularity required intentional content modeling from the start—it could not have been achieved through a migrated data structure.
Building Role-Based Access Control Across Two Systems
The portal required six distinct user role types, each with different permissions. The complexity arose because the source of truth for user identity and role attributes lived in iMIS, while the access logic lived in Drupal. When a user authenticated, Drupal made a real-time request to the iMIS API to verify their identity and fetch current role attributes—member status, program enrollments, organizational role. This data was cached in Drupal's session with a 15-minute expiration window. If an instructor's access was revoked in iMIS, they would lose portal access within that window without requiring a logout.
This hybrid approach—authoritative data in iMIS, permission logic in Drupal, with real-time sync points—required careful automated testing across both systems: simulating role changes, validating that portal access reflected those changes within the cache window, and testing edge cases like simultaneous role modifications and session timeout scenarios.
Team Dynamics and Knowledge Transfer
The 20-person team ran from RFP in February 2025 through delivery to a go-live target of March 16, 2026. Midway through, a core backend engineer transitioned off the project. The mitigation was intentional: a detailed knowledge transfer documenting API contracts, permission synchronization logic, and testing patterns. Because the integration layer had a specific, clearly scoped purpose—authenticate against iMIS, sync role attributes, verify permissions—knowledge transfer was possible without losing momentum. No single person was a bottleneck on critical architectural decisions.
Go-Live and Outcome
The final demo on March 11, 2026 showed a fully functional member portal with all six user role types working as specified and seamless iMIS integration for user identity and role attributes. The VP described the effort as "an enormous amount of work"—reflecting a genuine understanding of the project's true scope. This wasn't a routine CMS migration. It was a deliberate replatforming that preserved existing member management infrastructure while building a modern digital experience on top of it. The engagement resulted in a multi-year commitment to digital expansion and ongoing optimization.
What This Approach Teaches Us
For technical leaders evaluating similar scenarios—especially in regulated industries like safety, healthcare, and financial services where legacy systems carry critical operational logic—four principles emerge.
First, question the migration assumption. Data migration is a means to an end. API-first integration can achieve the same functional outcome with less risk and, often, lower cost.
Second, invest in clear system boundaries. The iMIS-Drupal integration worked because each system owned its domain explicitly: iMIS for member identity, enrollment records, transactional history; Drupal for content, presentation, and role-based access logic. The boundary prevented the gradual coupling that makes legacy integrations fragile.
Third, address content debt intentionally. Migrating old content structures simply delays the problem. A content audit and taxonomy rebuild is more work upfront but results in a cleaner, more maintainable system long-term.
Fourth, design for real-time synchronization where it matters. Permission-critical data should be verified in real time or on a short cache window. The cost in API calls is worth the reliability it buys.
The mid-market safety association now operates a modern member portal built on Drupal while keeping their 20-year-old iMIS system fully operational and unmodified. The two systems are connected, but not entangled. This is what thoughtful legacy integration looks like—not a migration, but a bridge.
This kind of integration-first modernization is a core application engineering pattern we use when a full migration is off the table.
Bring this dispatch into a working session - one page in, scoping memo out.
Brief Foyer