Upgrading OnDemand (Hosted) DNN Evoq Engage Staging from 09.06.07 to 09.13.10 and Aligning .NET Framework to 4.8

Solution

1) Upgrade planning (OnDemand/hosted)

Use an incremental upgrade path (do not single-jump)

Recommended upgrade sequence for Evoq Engage:

• 09.06.07 → 09.06.25
• 09.06.25 → 09.10.06
• 09.10.06 → 09.11.03
• 09.11.03 → 09.13.09
• 09.13.09 → 09.13.10

Best practices for the upgrade request

• Take and verify full backups (SQL database + full site file system) before changes begin.
• Rehearse on a staging/test copy to estimate downtime and validation effort.
• For web farms, perform upgrades with only one node enabled (as applicable to your topology) to avoid conflicts.
• Ensure the correct Evoq Engage upgrade package is used for each step.
• After each step, smoke-test key flows and review logs before continuing.

Downtime / scheduling expectations

• Downtime varies by database size, custom/third-party modules, validation scope, and environment complexity.
• For managed OnDemand scheduling, plan a buffered maintenance window (commonly up to an 8-hour window per instance to allow rollback if needed).
• Execution time may be shorter (for example, ~4 hours once the Infrastructure team is ready), but you should still reserve adequate buffer.

2) Submitting the OnDemand upgrade request (information required)

To schedule and execute an OnDemand (hosted) Evoq upgrade, provide the following to the Infrastructure/SaaS (OnDemand) team:

1. Device name(s) for each instance to be upgraded (format like dnn#####)
   • Often discoverable under Settings → Site Settings → Site Behavior → Site Aliases.
   • Hosted alias patterns may include dnn#####.evoqondemand.com depending on configuration.
   • If the device name is not visible in the UI, provide your staging URL(s) (for example, https://your_instance.domain.com/) so the device name can be determined via hosted/DNS mapping.
2. Environment type(s)
   • Example: Staging
3. Target version
   • Example: 09.13.10

Then coordinate your preferred upgrade window (weekend vs ASAP) so Infrastructure/SaaS can schedule the activity.

Hosted execution note: In OnDemand environments, the Evoq upgrade is executed by the Infrastructure/SaaS team. In one staged implementation following the approach above, the staging upgrade to Evoq Engage 09.13.10 completed successfully.

3) Post-upgrade: Framework requirement clarification (.NET 4.7 vs 4.8)

Recognize the symptom

After the upgrade, the staging environment may report:

• Evoq version shows: “Evoq Engage v. 09.13.10 (334)” (or similar)
• Framework shows: “.NET Framework 4.7” in the UI/About/Persona Bar

Impact: This commonly raises concern that the environment does not meet expected prerequisites (for example, customer standardization, component requirements, or governance).

What Evoq requires

• Per Evoq system requirements, Evoq 9.4+ requires a minimum supported .NET Framework version of 4.7.2.

Why the UI may still show “4.7”

• The Persona Bar/About display may not show the patch level (for example, it may show “4.7” even if the installed runtime is 4.7.2+).

Is .NET Framework 4.8 supported?

• Yes. .NET Framework 4.8 is above the minimum requirement and is compatible with Evoq Engage 09.13.10.

4) Requesting and implementing .NET Framework 4.8 on OnDemand staging

Recommended approach

1. Confirm Evoq’s minimum required version (4.7.2+ for Evoq 9.4+).
2. Request Infrastructure/SaaS to verify the actual installed .NET version on each web node (node-level verification is authoritative).
3. If required by organizational policy, request a change to upgrade the staging web nodes to .NET Framework 4.8.

Hosted implementation (performed by Infrastructure/SaaS)

• Upgrade the staging instance’s web nodes to .NET Framework 4.8 (applied to all relevant web nodes).
• Update the site configuration to target .NET 4.8.

web.config setting:

targetFramework="4.8"

Important: On hosted environments, customers typically cannot perform the OS/runtime upgrade themselves; this change is executed by the Infrastructure/SaaS team via a scheduled change request. In one staged implementation, Infrastructure/SaaS completed the .NET Framework 4.8 change and updated web.config to target 4.8.

5) Validation steps

After the staged changes complete:

1. Confirm application health
   • Site loads normally.
   • No new runtime errors observed during basic navigation.
2. Confirm Evoq version
   • Verify staging reports Evoq Engage 09.13.10.
3. Confirm .NET Framework 4.8
   • If the UI still shows “4.7”, request Infrastructure/SaaS to confirm the installed .NET release via system-level evidence (node-level verification is authoritative).
   • Confirm web.config includes targetFramework="4.8" (if you have access to the hosted file view/export).

6) Follow-up (separate issue): post-upgrade theme/skin/CSS/Visualizer rendering differences

If, after upgrading Evoq and .NET, you notice issues such as:

• Visualizer formatting changes (text formatting, link color)
• Skin/theme layout changes (misalignment)
• HTML rendering differences (“HTML does not output as expected”)

Use the following isolation steps in staging:

1. Switch a test page to a default DNN skin/container
   • If the issue disappears, the custom theme/skin CSS/JS likely needs updates for 9.13.x.
2. Compare rendered DOM/CSS
   • Use browser developer tools to compare markup and computed CSS.
   • Look for selector mismatches and specificity/order changes.
3. Check browser Console + Network
   • Identify JavaScript errors and missing/blocked CSS/JS assets (404/403).
   • Note that a single JavaScript error can cascade into UI/editor/Visualizer issues.
4. Clear client dependency caches and hard refresh
   • Stale combined/minified assets can cause mismatched CSS/JS after upgrades.

To continue investigation efficiently, collect and share the following diagnostics:

• Screenshots showing before/after differences
• Browser console output
• HAR capture (network trace)
• Resource.log from staging (if available)
• Any side-by-side evidence comparing pages/components impacted by the upgrade

Note: This follow-up theme/skin/CSS/Visualizer behavior requires additional investigation using the artifacts above.