A reliable way to manage DNN upgrades across environments

Upgrading a DNN, formerly DotNetNuke, platform across development, staging and production is a release-management exercise rather than a single installation task. The safest approach treats the portal, database, extensions, themes, configuration files and deployment process as one controlled system.

This matters for Australian organisations operating across Sydney, Melbourne, Brisbane, Perth and regional offices. A release that works on a developer laptop in Melbourne may still behave differently in a production environment hosted in another state, using a separate database server, security policy or content delivery network.

A repeatable upgrade path reduces downtime, protects business content and gives technical teams a clear rollback option. It also creates a dependable foundation for custom software, partner portals and applications such as Acoléa, Adylic, AricieGrid and Budg-Immos.

Map the environments before changing anything

Start by documenting the exact role of each environment. Development should support rapid testing, staging should mirror production as closely as possible, and production should accept only an approved release package. Record the DNN version, .NET runtime, database engine, installed modules, skin packages, authentication providers and scheduled jobs in each environment.

Configuration differences deserve particular attention. Connection strings, SMTP settings, file paths, API keys, payment gateways and identity-provider details should be externalised rather than edited manually during deployment. Use environment-specific transforms or secured variables so that a staging notification never reaches real customers and a production database is never used by a developer workstation.

Inventory the applications that depend on the portal as well. An application portfolio view can help teams identify ownership, dependencies and business impact before a platform change. This is useful where a DNN portal connects to finance, document management, CRM or Australian tax and invoicing workflows.

Build and test a controlled upgrade package

Confirm the supported upgrade path with the DNN version and every installed extension. Some modules require an intermediate release, a database migration or a particular .NET version. Export the current module list and record custom code changes before installing anything. A clean package should include the platform update, compatible extensions, skin assets, database scripts and documented configuration changes.

Create a production-like staging copy using sanitised data. This should include representative page structures, permissions, workflows, media files, search indexes and integrations. Test administrator and editor functions, public pages, forms, scheduled tasks, authentication and file uploads. If the portal supports invoicing, validate a complete transaction without sending live email or creating a real financial record; an Acoléa invoice guide can provide useful configuration context for that type of workflow.

Include performance and security checks in staging. Measure page response times, search behaviour, error rates and background jobs before and after the upgrade. Run vulnerability scanning against the new runtime and confirm that permissions have not broadened during installation.

Promote the same release through each stage

Avoid rebuilding the upgrade separately for development, staging and production. Build one versioned artefact, test it in development, promote that same artefact to staging, then release it to production after approval. This prevents small manual changes from creating an untraceable difference between environments.

Use source control for custom modules, templates, deployment scripts and configuration templates. A pipeline can apply pre-deployment checks, take a database backup, place the site into maintenance mode if required, deploy files, run migrations and perform smoke tests. Store secrets in a secure vault, not in a repository or a copied web.config file.

For Australian teams, coordinate release times around the business rather than assuming every office works to Sydney time. A Brisbane-based operation may plan around AEST while Melbourne and Sydney move to AEDT, and Perth teams can be several hours behind during parts of the year. Document the release time in local time zones and include contacts for each office.

Protect data and plan the rollback

A rollback plan must cover both application files and database changes. Take a verified database backup, preserve the previous application package and confirm that backups can be restored to a separate location. If the upgrade includes irreversible schema changes, define a forward-fix procedure rather than relying on a simple file reversal.

Before production deployment, agree on go/no-go criteria. These may include a successful backup check, clean staging test results, available support staff, a maintenance notice and confirmation that critical integrations are reachable. Keep a release record containing the version, operator, start time, database migration status and validation results.

Schedule changes during a quiet service window, but account for Australian trading patterns. A national retailer, a school serving families in different states or a professional firm preparing BAS and GST reporting may have different low-traffic periods. Announce expected impact clearly and avoid a Friday afternoon release when specialist support will be difficult to reach.

Validate production and keep improving the process

After deployment, run a focused smoke test from outside the server network. Check the home page, key landing pages, login, search, forms, uploads, permissions, scheduled jobs and connected services. Review DNN logs, IIS logs, database alerts and monitoring dashboards for several hours rather than treating a successful installation screen as proof of success.

Ask business owners to verify their most important journeys. An accounts team might test invoice creation, an HR team may check a restricted document library, and a partner may confirm access to a portal workflow. Capture screenshots or automated test results so that acceptance is based on evidence rather than memory.

Keep the old package, release notes and test results for an agreed retention period. Review incidents, slow queries, broken links and support tickets after the change, then update the runbook. Over time, automated checks and infrastructure-as-code can make DNN upgrades faster without reducing control.

Aricie can help Australian organisations establish a governed DNN release process, assess custom applications and support compatible business solutions across development, staging and production. Prepare the environment inventory, backup evidence and extension list, then engage the team to plan a safer upgrade window.