Beyond the black box: modernizing proprietary systems with Drupal

At PNW Drupal Summit 2026, I presented Beyond the black box: modernizing proprietary systems with Drupal. The session looked at what happens when an organization needs to replace a proprietary platform that has evolved for more than a decade.

What first looks like a website redesign can quickly become something much larger: a complete modernization of the systems that manage relationships, learning, payments, permissions, communications, and operational workflows.

The real challenge isn't rebuilding the interface. It's understanding the business rules hidden beneath it, and making sure the replacement preserves what matters without recreating years of technical debt.

I organized our approach at MindSing into five acts: discovering hidden behavior, modeling the organization, sequencing the migration, orchestrating AI-assisted development, and preparing for go-live.

The challenge: a website is often just the visible layer

Organizations rarely set out to build complicated legacy systems. Platforms evolve one decision at a time. A new approval process is introduced. A payment workflow changes. Another department needs additional permissions. New requirements lead to custom functionality, and exceptions accumulate.

After ten or fifteen years, the platform holds thousands of decisions, and many of them were never written down.

Public experienceContent, navigation, brand

Legacy CRM + LMS platform

Contacts and relationships

Enrollment and credentials

Payments

Approvals

Communications

Permissions

In the case I presented, the platform combined two major operational domains:

• Customer relationship management (CRM): contacts, organizations, relationship histories, communications, approvals, and payments.
• Learning management system (LMS): learners, enrollments, evaluations, certificates, and learning histories.

The broader modernization involved seven connected workstreams: brand refresh, design system, public CMS, CRM, payments, LMS, and communications. Each depended on rules or data from the others, so rebuilding the website alone would not solve the underlying problem.

The goal was an operating model the organization could understand, maintain, and evolve.

---

Act I: software archaeology

The first challenge in migrating a legacy platform is finding out how it actually works.

Documentation is usually incomplete. Staff understand parts of the system, but institutional knowledge leaves with turnover. Even the source code doesn't explain why a rule exists.

We treat this as software archaeology and combine four sources of evidence. No single source tells the whole story, and the contradictions between them point to the next question to investigate.

Evidence

Staff memoryIntent: why the workflow exists, but often misses rare paths.

UI behaviorHappy path: what users can reach, but hides automation.

Source codeImplemented rules, side effects, and accidental behavior.

DatabaseHistory: real states and records the UI no longer creates.

AI-assisted synthesisClassify actors and states, draft flows, compare contradictions, generate missing questions

Every rule gets a classification

ConfirmedObserved in code or data and validated with the people who run the process.

InferredImplied by several sources. Needs a targeted test or decision.

UnknownUnresolved behavior that blocks scope, acceptance criteria, or cutover.

Using AI to accelerate discovery

AI makes this process dramatically faster. Instead of manually connecting every screenshot, code path, database field, and interview note, AI-assisted analysis can help:

• Identify business entities and relationships.
• Generate preliminary workflow diagrams.
• Reconstruct state transitions.
• Compare contradictory information.
• Surface undocumented dependencies.
• List the questions that need human validation.

But AI-generated conclusions must stay distinguishable from verified facts. That's why every rule is labeled confirmed, inferred, or unknown. AI can help reconstruct the system; the people who run the organization validate its behavior.

The exceptions reveal the real complexity

Consider a seemingly simple paid enrollment. The happy path is easy to reproduce, and every step has side effects downstream.

1. Enrollment requested
2. Payment confirmed
   Receipt and reconciliation
3. Administrator approved
   Approval audit record
4. Enrollment activated
   Course access and notifications

The difficult questions show up around the exceptions:

• What happens when payment succeeds but the confirmation email fails?
• What if a payment webhook is delivered twice?
• What if two contact records represent the same person?
• What if a certificate expires during an active enrollment?
• Can an administrator override a decision?
• How should the new system represent historical records that match no current state?

These exceptions often hold the most important business rules, and each one needs an expected result and a test.

Not every legacy behavior deserves to survive. During discovery, each rule is assessed: preserve it, simplify it, replace it with a mature capability, eliminate it, or question who owns it and who benefits. Discovery documents the behavior; a named owner decides its future.

The lesson: recover the hidden behavior before estimating or rebuilding the platform.

---

Act II: modeling the organization with Drupal

Once we understand the rules, the next challenge is representing them in a coherent architecture.

Drupal is a strong foundation because it offers much more than content management. Its entity system, access control, configurable workflows, extensibility, and integration options suit complex operational applications.

Shared identity, separate lifecycles

A key principle is separating shared identity from specialized business processes. One person may at the same time be a contact associated with an organization, a learner enrolled in courses, an evaluator reviewing assignments, and an administrator for a specific workflow.

Those roles share an identity but follow very different lifecycles. Changing someone's relationship with an organization should not rewrite their learning history.

CRM lifecycle

RelationshipOrganization, role, dates

Interaction historyActivity, owner, consent

PreferencesCommunication consent

ContactShared identity with an optional user account

LMS lifecycle

Learner recordEnrollment and history

EvaluationEvidence, outcome, revisions

CertificateAward, expiry, verification

Mapping business concepts to Drupal

Drupal core and its ecosystem provide reusable building blocks for each concept:

Business concept	Drupal approach
Contacts	Content entities with an optional link to a user account
Organizational relationships	Entity references with historical dates
Payments	Drupal Commerce orders and payment records
Enrollments	Custom entities with defined state transitions
Evaluations	Revisionable entities with outcome history
Certificates	Entities tracking issuance, expiry, and verification
Notifications	Events and queue workers with retries, deduplication, and delivery tracking

These are representative choices, not a universal prescription; every implementation has to reflect the organization's real requirements. The principle that matters is that business rules stay explicit, inspectable, and testable.

The same thinking applies to access. Roles grant capabilities, while record relationships and state limit them: an evaluator can review only assigned learning records, and a CRM administrator manages contacts without touching certificates.

Why not build a collection of independent apps?

The common alternative is a separate application for every function: a CRM app, an LMS, an approvals app, a notification service, a CMS, a reporting tool.

Each one may be simple on its own, but connecting them adds real complexity. Shared identity, synchronization, permissions, audit trails, and operational ownership still have to live somewhere. Without a coherent domain model, organizations risk replacing one black box with several smaller ones.

Drupal lets us build one shared domain model and integrate specialized services, such as a payment gateway, an identity service, email delivery, and analytics, with the rules kept explicit at each boundary.

The lesson: a unified platform doesn't require every business process to share the same lifecycle.

---

Act III: sequencing the migration around dependencies

One of the biggest risks in modernization is building things in the wrong order.

Targeted communications depend on contact records, relationship history, consent, and access. Certificates depend on learner records and evaluations. Both depend on identity. Building the downstream capabilities before their foundations are stable creates rework.

Shared identity

CRM path

1. Contact record
2. Relationship history
3. Consent and access
4. Targeted communications

LMS path

1. Learner record
2. Evaluation
3. Certificate

A dependency-driven migration strategy

Our approach moves through seven stages:

1. DiscoverInventory behavior, rules, and exceptions
2. ModelEntities, relationships, permissions, states
3. CoreIdentity, authentication, access
4. PublicContent, presentation, theme
5. OperationsCRM, LMS, payments, communications
6. ValidateReconciled data, end-to-end tests
7. CutoverGo / no-go decision

This doesn't mean teams work strictly in sequence. Independent workstreams run at the same time, as long as the dependencies stay explicit. A foundation-first approach allows parallel development without giving up architectural coherence.

Demonstrating the architecture without exposing client information

The session also showed how a generic demonstration can communicate the architecture. By running a working Drupal domain model with synthetic branding, content, and records, we can show real routes, forms, permissions, and workflows without exposing anything sensitive. It lets us validate concepts and walk stakeholders through complex workflows while protecting the actual implementation.

The lesson: dependencies, not visual priorities, should set the migration sequence.

---

Act IV: orchestrating AI swarms and micro pull requests

AI-assisted development is changing how teams approach large modernizations. At MindSing, we've been running workflows that coordinate very high volumes of change, more than 100 pull requests a day as launch approaches.

The challenge isn't generating code faster. It's managing that volume without losing quality, traceability, or human oversight.

Smaller changes make AI development manageable

Rather than handing an AI agent a large, loosely defined feature, we break the work into bounded tasks. A task might:

• Correct one business rule.
• Implement one state transition.
• Update one interface component.
• Fix one reproducible defect.
• Add coverage for one exception.

Independent tasks run in parallel. Dependent tasks join a stack of pull requests. Each change stays narrow enough for a person to understand.

What belongs in an AI-generated pull request?

Every micro PR carries a standard change record. For a routine change, the goal is a review that takes a person one or two minutes: request changes, resolve the open choices, or accept it.

Require administrator approval before enrollment activates1–2 min review

What changed

Activation now waits for an approval transition, not only a confirmed payment.

Before / after

Screenshots captured automatically.

Before

After

Decision points

Should an administrator override skip the approval audit record?

Scope and dependency

One workflow transition; builds on the enrollment states PR.

Enrollment states → This PR → Activation notifications

This isn't about removing human review. It's about making human review work at a much larger scale.

Making the development process resilient

We pair micro PRs with established engineering practice:

• Squash each PR into one focused commit with a traceable record.
• Stack dependent PRs in the order they need to merge.
• Gate the stack with automated checks and required approvals.
• Use reproducible tests and before / after screenshots to investigate regressions.

When something breaks, we reproduce it, compare the PRs since the last known-good build, inspect the small diffs, then fix or revert and retest the affected flows. A narrow change history makes that investigation much smaller.

The result is a workflow that uses AI for execution and speed while people keep judgment over architecture, quality, and business decisions.

The lesson: the value of AI development comes from coordinating small, verifiable changes, not from generating more code.

---

Act V: preparing for go-live with real people

A migration isn't complete when the code is finished. It's complete when the organization can confidently run the replacement. For a complex CRM and LMS, that confidence comes from real people performing real workflows.

Running the legacy and new systems side by side

We test the existing platform and the new Drupal implementation in parallel, with each group testing the work it actually does:

• CRM users validate contact and relationship flows.
• Learners test enrollment, access, and learning history.
• Evaluators test assigned reviews and outcomes.
• Administrators verify approvals, permissions, and operations.

Each stream has real testers, a known build, and traceable findings.

One testing effort, three kinds of evidence

1. User-flow results: both systems compared using the same scenario.
2. How-to documentation: the tested flow written as steps people can follow.
3. Traceable bugs: test steps, the expected result, and the tested build.

This matters most where knowledge lives with individual staff members. Writing documentation alongside testing reduces that dependence.

Defining measurable cutover criteria

Before launch, the organization needs explicit pass / fail criteria:

• Persona scenarios: contact, CRM administrator, learner, and evaluator journeys complete successfully.
• Data reconciliation: stable IDs, relationships, financial totals, and migration exceptions all reconcile.
• Side-effect comparison: access, notifications, certificates, and audit output behave as expected.
• Rollback rehearsal: the write freeze, abort point, and recovery path are defined and practiced.

Every acceptance criterion needs supporting evidence and a named go / no-go owner.

The lesson: go-live should be an operational decision backed by evidence, not just a deployment date.

---

The bigger goal: organizational resilience

The greatest value of modernizing a proprietary system isn't a faster interface or a quicker development process. It's reducing the organization's dependence on undocumented knowledge and specialized ownership.

Leadership changes. Processes change. Staff move on. Vendors and development teams change. A platform built on opaque custom behavior gets harder to operate through every one of those transitions.

A documented, conventional, open platform is the resilient alternative. Drupal's value comes not only from its capabilities but from making it possible to build systems whose behavior, data, permissions, and integrations can be understood by people who weren't there when they were built.

That is what moving beyond the black box really means.

Five lessons for modernizing legacy platforms

If you're evaluating a legacy CRM, LMS, or proprietary business platform, these are the principles I'd emphasize:

1. Discover before rebuilding. Understand the rules, exceptions, and history before committing to scope.
2. Model distinct domains deliberately. Share identity where it helps without collapsing independent lifecycles.
3. Build in dependency order. Establish data, identity, and access before the features that depend on them.
4. Use AI with structured oversight. Small, reviewable changes enable parallel work without losing traceability.
5. Make real-user testing part of the migration. Validation, documentation, and operational readiness should grow together.

Watch the full session

Watch the complete presentation from PNW Drupal Summit 2026, which walks through the architectural models, migration sequence, AI-assisted development workflow, and testing strategy in more detail.

Thank you to the Pacific Northwest Drupal community and the summit's sponsors for the opportunity to share this work.

---

Replacing an aging proprietary platform, or untangling disconnected systems? The starting point is always understanding the organization behind the technology. Let's talk about your platform, or explore our web development services.