Patching & Upgrades – How Nevermore Avoids Breaking Everything with One Click

In the last post, we talked about dependencies—those delightful little webs that hold your solution together (and sometimes choke your deployments).

Now we’re talking about updating solutions. Because once your apps are live, the only thing more dangerous than doing nothing… is doing the wrong thing in Prod.

Nevermore learned early on that patching a solution isn’t the same as fixing the problem—especially if you forget where that patch is going, or what it’s replacing.

First: What Are Your Options?

There are three main ways to update a solution:

1. Unmanaged Editing (NOPE)

Don’t even think about it. Making changes directly in Production or Test without going through ALM? That’s not patching—that’s sabotage.

2. Patches

A patch is a lightweight change on top of a managed solution. It can add or update components, but it can’t remove anything. Think of it like a sticky note on top of your solution.

Good for:

• Emergency bug fixes
• Incremental changes that don’t need full regression testing

Bad for:

• Long-term maintainability
• Complex releases with multiple components

More here: Solution Patching Guide

3. Upgrades

This is the clean option. You export a new versioned managed solution, mark it as an upgrade, and when imported, it replaces the original solution—including removed components.

Good for:

• Major version releases
• Cleaning up old fields, views, forms, and logic
• Maintaining a clear layer structure

Nevermore’s Rules for Patching vs Upgrading

Use patches only when:

• A single hotfix is required
• The change is isolated (e.g. one flow, one field)
• It’s a blocker in Production and can’t wait for a full release

Use upgrades when:

• Multiple changes need to go together
• Solution layers have become tangled
• Components need to be removed cleanly
• It’s part of a regular release cycle

Nevermore’s Upgrade Process (The “Proper” Way)

1. Changes are made in Dev, inside an unmanaged solution
2. Solution is exported as managed, versioned e.g. 3.1.0.0
3. Pipelines run pre-deployment tests in Test and Pre-Prod
4. A release plan is prepared: who’s impacted, what’s changing, what’s being removed
5. Upgrade is imported to Production during a scheduled release window
6. If something breaks? Rollback plan is ready, with the previous .zip stored in source control

Every upgrade includes:

• Release notes
• Screenshots for UI changes
• Dependency report
• List of impacted users

No guesswork. No winging it. No panicked Teams calls.

What Happens If You Don’t Upgrade?

If you keep stacking patches, you create a layer cake of madness.

• Form changes stop applying correctly
• Plugins from different patches start overlapping
• Environment variables get duplicated or lost
• The base layer becomes irrelevant—because it’s buried under five other tweaks

Nevermore ran into this with an app that had been patched seven times in three months. The result? A table that couldn’t be deleted, a view that only showed in one environment, and a rollback that took four days.

Cleanup Tip: Remove Old Patches

After upgrading, old patches become detached—they’re no longer connected to your active solution.

Use the Solution History to clean them up safely:

1. Go to Solution Explorer
2. Click the vertical ellipsis (⋮)
3. Select “Solution History”
4. Delete detached patches (as long as they’re not in use)

Don’t hoard your patches. This isn’t a loft conversion.

Bonus: Use Semantic Versioning

Nevermore follows this format: Major.Minor.Build.Revision (e.g. 2.3.0.1)

• Major: Big business or architectural change
• Minor: New features
• Build: Fixes or tweaks
• Revision: Emergency patch or rollback fix

It’s simple. It’s meaningful. And it avoids naming your files final-final-NEW-fixed.zip.

TL;DR – Slow is Smooth, Smooth is Fast

• Patches are for quick, minor updates
• Upgrades are for structured, stable progress
• Always use version control
• Don’t stack patches unless you enjoy chaos
• Upgrade regularly to avoid hidden conflicts
• Document everything—so your future self isn’t emailing your past self angry questions

Coming Up: Blog 10 – Security, Compliance, and ALM

In the next blog, we’ll look at how Nevermore manages security, permissions, and compliance across 20 environments. Spoiler: it’s not just giving everyone System Admin and hoping for the best.