DNN (DotNetNuke) modernisation

Alive, and standing still. DNN Platform is open source under the .NET Foundation and gets releases; 10.3.2 came out in May 2026. The commercial Evoq editions continue too. But every version of it targets .NET Framework 4.8, there is no DNN on modern .NET, and the Web Forms technology most modules are built on was never carried forward by Microsoft either.

The sites we see are older than that. DNN 5, 6 or 7 on a Windows server that's out of support, with third-party modules from vendors who've closed, custom modules written by someone who's left, and a skin that breaks on phones. Upgrading DNN itself is possible, in steps, and each step is a chance for a module to stop working.

• The platform: pages, users, roles, permissions, content, all in SQL Server.
• Third-party modules: forms, galleries, e-commerce, document libraries, bought years ago, some from vendors who no longer exist.
• Custom modules: the application. The quote calculator, the booking system, the members' database, written as Web Forms controls against a specific DNN version.
• The skin: the design, usually HTML from the year it was built.
• Integrations: the module that talks to the CRM or the accounts system.

The platform and the content are the easy part. The custom modules are where the business runs and where the modernisation is decided.

Upgrade in place when the site is mostly content and the custom modules are small. DNN upgrades version by version, the content comes with it, and modules are fixed or replaced as they break. The site ends on DNN 10 and .NET Framework 4.8, which is supported for as long as the Windows version it ships with, and no further.

Move the application out when the custom modules are the business. They're rebuilt as a modern .NET or web application with its own database, one module at a time, with DNN still serving the pages that haven't moved. The content either stays on an upgraded DNN, or moves to a current CMS, or, often, turns out to be a handful of pages that don't need a CMS at all.

Usually both. Upgrade DNN enough to be safe, then take the application out. The assessment reads every module and says which.

1. Inventory. Every module, its version, its vendor, whether the source exists, and which pages use it. The assessment produces this from the site and the database.
2. Safety net. Source control for the custom modules, a copy of the site running in a test environment, and a backup that's been restored.
3. Upgrade the platform in steps, fixing or retiring modules as each step breaks them, until it's on a supported Windows server and a current DNN.
4. Rebuild the application modules that matter, one at a time, as a modern application alongside, with users re-pointed as each one moves.
5. Decide the content: upgraded DNN, a current CMS, or plain pages.
6. Retire what's left when the last module has moved.

Each stage has its own fixed price, and each ends with something safer than before.

It's in SQL Server, in DNN's schema and in each module's own tables. Users, roles and content export cleanly; module data is mapped table by table. Nothing meets a change until the change has proven itself somewhere else: a migration tested against a copy in a test environment, then run in staging with counts reconciled, before anything switches.

Yes. Platform upgrades go one version at a time. Application modules move one at a time behind the same site, so users see one change at a time rather than a new system. Stop after any stage and keep everything.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a DNN site it produces the module inventory, tests whether the site can be upgraded, identifies which modules are the application, and prices the stages as fixed numbers. What drives the price and the payment terms each have a page.

An old DNN site is usually public-facing, usually on an unsupported Windows server, and usually several versions behind on a platform that publishes its security fixes. The third-party modules get no fixes at all. And the custom modules are on Web Forms, a technology with no future version, so every year makes the rebuild larger rather than smaller.

Inventory, safety net, upgrade what upgrades, move the application out. Marc Allington has built on .NET Framework and Web Forms, which is what DNN and its modules are made of, and builds on modern .NET and the web stack they move to. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment.