DNN CMS Alternative for Water Authorities: Why Drupal Holds Up Where DotNetNuke Doesn't

Water authorities don't have the luxury of a website that occasionally breaks. When ratepayers need to check service alerts, report an issue, or pay a bill, the platform has to work. DNN (DotNetNuke) made sense for many municipal and utility organizations in the 2000s and early 2010s. It was affordable, familiar, and got the job done. For most water authorities still running it, that era is over.

The problems are predictable: integrations with billing and CIS systems that require workarounds, accessibility compliance gaps that are increasingly a legal exposure, and a development ecosystem that has contracted sharply as the platform lost market share. A security patch that used to ship in days now takes weeks. Finding a developer who knows the platform well enough to touch a custom module is harder every year. These aren't signs that your team made a bad decision. They're signs that the platform has aged out of the work you need it to do.

Inclind has built and maintained Drupal platforms for water and utility organizations for over 25 years. That includes Eagle River Water and Sanitation District and California Water Service, along with electric cooperatives like Delaware Electric Cooperative, where the work has spanned four website builds, a mobile outage application with 99.9% uptime over its lifetime, and ongoing CIS integration. When a water authority moves from DNN to Drupal, the migration is rarely just a content lift. It's a platform replacement that has to account for authenticated ratepayer portals, service area mapping, billing integration, and WCAG 2.1 AA compliance from day one. That's the scope Inclind plans for.

Why Water Authorities Are Moving Off DNN

DNN's decline isn't sudden, and that's part of what makes it hard to act on. The platform still runs; pages load. Staff knows where things are. But the technical debt has been compounding quietly, and at some point the cost of staying outweighs the friction of leaving.

The core issue is market contraction. DNN's developer community has shrunk significantly over the past decade. Modules that once had active maintainers are now effectively abandoned. When a water authority needs a custom integration built or an existing one updated, the pool of qualified vendors is small, and the ones who remain command a premium. Organizations end up paying more for less capable work.

Security is the sharper concern. Utility websites handle authenticated sessions, ratepayer account data, and in some cases payment processing. A platform that is slow to patch known vulnerabilities isn't just a technical inconvenience. It's a liability. Water authorities operating under state oversight or federal programs face real consequences if a breach occurs on infrastructure that should have been replaced.

Accessibility enforcement has also changed the calculus. The ADA's application to public-facing websites is no longer theoretical. Agencies and utilities are facing demand letters and litigation. DNN's aging theme architecture and limited support for modern accessibility tooling make WCAG 2.1 AA compliance genuinely difficult to achieve and maintain. Drupal, by contrast, has accessibility built into its core contribution standards, and the ecosystem of tested, compliant components is deep.

What a DNN-to-Drupal Migration Actually Involves

The word migration gets used loosely. For a water authority, it's rarely accurate to describe a DNN-to-Drupal move as simply transferring content. The content comes over, yes. But the real work is rebuilding the architecture that the content sits on.

Most water authority DNN sites have accumulated years of customization: modules extended in ways the original vendor didn't intend, templates patched repeatedly, and integrations held together by code no one on the current team fully understands. Before a single page of content moves, you have to audit that architecture. What's actually in use? What integrations are live and essential? What was built for a need that no longer exists?

Content migration itself requires decisions. Drupal's content modeling is structured and intentional. DNN sites often aren't. Content dropped into free-form HTML modules needs evaluation and, in many cases, restructuring to fit a content-type framework that will remain maintainable going forward. That work takes time, and skipping it creates problems that compound over the life of the new site.

There's also the question of URL structure and redirects. Water authority websites carry years of indexed content, inbound links from government directories, and ratepayer-facing URLs that staff have communicated in newsletters and bill inserts. A migration that doesn't map and preserve those paths damages both search visibility and user trust. Inclind builds redirect architecture into every migration plan before development starts.

Integrations That Have to Hold: Billing, CIS, and Service Portals

This is where water authority migrations diverge sharply from a standard website project. The public-facing site isn't just a brochure. It's a service delivery surface. Ratepayers use it to pay bills, set up automatic payments, report leaks, check outage status, and manage their accounts. If any of those functions break during or after a migration, the impact is immediate and visible.

Customer Information Systems, the platforms that manage billing and account data, vary significantly across utilities. Some water authorities run Tyler Technologies products. Others use Versapay, Paymentus, or utility-specific platforms built decades ago that expose data through aging APIs. Drupal's integration architecture is mature enough to handle most of these, but the work is specific. An integration isn't a module you install. It's a custom build that has to account for authentication flows, data sync timing, error handling, and what ratepayers see when something goes wrong on the backend.

Inclind's work with Delaware Electric Cooperative required exactly this kind of sustained integration work, including a mobile outage application that maintained 99.9% uptime over its operational life. That kind of reliability doesn't happen by accident. It comes from planning the integration architecture before writing the first line of code, then maintaining it with the same care as the public-facing site.

Authenticated ratepayer portals add another layer. These require session management, role-based access, and data display that's accurate in real time or close to it. Drupal handles this well when it's configured correctly. Getting the configuration right, and making sure it stays right through Drupal core updates and CIS vendor changes, is an ongoing responsibility, not a one-time task.

Accessibility and Compliance Requirements Water Authorities Can't Ignore

Public utilities occupy a specific legal position. State public utilities commissions govern many. Some receive federal funding. All of them serve the public in ways courts have increasingly interpreted as subject to ADA Title II requirements. The updated DOJ rules that took effect in 2024 made WCAG 2.1 AA the explicit standard for state and local government entities. Water authorities are not exempt.

The problem with achieving WCAG 2.1 AA compliance on DNN isn't that it's impossible. It's that the platform makes it genuinely difficult. Theme rendering, module output, and the way dynamic content is structured often produce accessibility failures that can't be fixed with a CSS override. Remediation on a DNN site is frequently a game of whack-a-mole, where fixing one issue surfaces another.

Drupal's approach is different. Accessibility is a stated core commitment, and contributed modules are expected to meet accessibility standards to be included in the ecosystem. That doesn't mean every Drupal site ships accessible by default. It means the foundation is there, and a development team that knows what they're doing can build to WCAG 2.1 AA from the start rather than retrofitting compliance after launch.

Inclind builds accessibility testing into the development process, not the QA phase at the end. That includes automated scanning, manual keyboard navigation testing, and screen reader validation across the ratepayer-facing workflows that matter most: bill payment, account access, service alerts, and contact forms. Compliance documentation is part of the deliverable.

What the Transition Timeline Looks Like

Water authorities ask this question early, and it's the right question. A platform migration can't disrupt ratepayer services or coincide with peak demand periods, and the internal staff capacity to support a migration is always limited.

A realistic DNN-to-Drupal migration for a water authority typically runs six to nine months for a site of moderate complexity. Sites with multiple authenticated portals, active CIS integrations, and large content archives can take longer. The timeline breaks into three broad phases.

The first phase is discovery and architecture. This is where Inclind audits the existing DNN environment, maps every active integration, inventories content, and defines the Drupal content model. This phase typically runs six to eight weeks. Decisions made here shape everything that follows, so compressing it is a mistake.

The second phase is development and integration. The team builds the Drupal environment, develops and tests integrations, and migrates and validates content. This is the longest phase, typically three to four months, and it runs in parallel tracks to maintain forward momentum.

The third phase is testing, training, and launch. This includes full accessibility validation, staff training on Drupal's editorial interface, and a phased or hard cutover depending on the authority's risk tolerance. Post-launch support is scoped separately but planned for from the start.

Throughout the project, the existing DNN site stays live. Ratepayer services don't go dark during a migration. The new Drupal environment is built alongside the old one, and cutover happens only after the new platform has been validated end to end.

Is Inclind the Right Partner for Your Migration?

Not every agency is a fit for Inclind, and we'd rather say that directly than let a project start on the wrong footing.

Inclind works best with water authorities and utilities that have real integration requirements, take accessibility obligations seriously, and need a long-term partner rather than a one-time vendor. We've maintained client relationships that span multiple website generations, including organizations where we've built the same platform four times as needs evolved. That kind of continuity is only possible when the technical relationship goes deep enough to be genuinely useful.

Our work with Eagle River Water and Sanitation District, California Water Service, and Delaware Electric Cooperative reflects the kind of organizations we're built to serve. Complex integrations, regulated environments, ratepayer-facing services that can't afford downtime. If that's where your authority sits, we should talk.

We start with a discovery conversation, not a sales pitch. Inclind will look at your existing DNN environment, ask questions about your integrations and compliance obligations, and give you an honest read on what a migration would actually involve. If the project is right for us, we'll say so. If it isn't, we'll say that too.

Contact Inclind to start the conversation about your DNN migration.