Keep a Rollback Plan Ready Before Every Software Rollout
The question is never whether a rollout can go wrong — it is whether you can undo it in an hour. A rollback plan made before deployment is cheap. One improvised during a crisis is not a plan at all.
✍️ Technical Anshu🏢 Office IT⏱️ 7 minute read
🎥 Watch uninstall configurations — your rollback tool — in the video
Professional deployment teams treat every rollout as reversible until proven boring. The new version runs for a few days, the tickets stay quiet, and only then is the old version retired. Rollback in Endpoint Central is not a special feature — it is the same machinery aimed backwards: an uninstall configuration for the new version, plus the old version's package, which you kept. Kept is the operative word.
folder — rollback kit for one rollout, prepared in advance
New packageApp v12 — install configuration saved
Rollback step 1Uninstall configuration for v12
Rollback step 2App v11 package — tested, still in the console
Changed PCs listExported from the v12 deployment report
Four items, prepared before the rollout. When you need them, there is no time to prepare them.
1
Never Delete the Old Package Until the New One Is Boring
Keep the previous version's package and its install configuration in the console for at least one full business cycle after the upgrade
If the old installer came from a vendor download, keep the file itself too — vendors remove old versions from their sites without asking your permission
Note the old version's silent install and uninstall commands alongside the package while you still remember them
2
Build the Rollback as Configurations, Not Intentions
Before the main rollout, create both halves of the way back: an uninstall configuration for the new version, and an install configuration for the old version, each targeted at a group you can fill with exactly the PCs you upgraded. Pre-built and un-deployed, they cost you ten minutes. Built mid-crisis with the office manager standing behind your chair, they cost considerably more.
3
Know What Rollback Cannot Undo
Be honest with yourself and your boss about the limits:
If the new version migrated user data — new file formats, converted profiles, upgraded local databases — reinstalling the old program may not read the new data
Settings changed by the new version may persist after removal; a rollback restores the program, not always its configuration
This is the second reason the pilot ring matters: data-migration surprises are discovered on four PCs, where manual fixes are feasible
For genuinely data-critical software, back up the relevant folders as part of the pre-deployment activity
4
Decide the Rollback Trigger in Advance
Write down, before deployment, what would make you roll back: the app fails on a core task, failures exceed a small percentage of targets, a business-critical integration breaks. Deciding the trigger in calm conditions prevents the two crisis failure modes — rolling back in a panic over one loud ticket, or refusing to roll back while the evidence piles up. Share the trigger with whoever approved the rollout.
5
When You Roll Back, Roll Forward the Lessons
Execute the uninstall configuration to the changed-PC list, reinstall the old version, verify with the pilot users first, and announce the reversal plainly — users respect a fast honest undo far more than a stubborn silence. Then write down why it failed while you still know. Half of all rollback causes are package problems you can fix; the other half are facts about the new version that mean waiting for its next patch. Either way, the note you write today is the pilot checklist for the retry.
⏪ The rollback rule: if you cannot describe, right now, exactly how tonight's deployment gets undone — configurations, package, target list — the deployment is not ready. Ten minutes of preparation is the whole difference between an incident and an anecdote.
🎥 Watch the Full Deployment in the Video
See the uninstall and reporting tools your rollback relies on in the full video.
At least one full business cycle of the software's real use — a month for a monthly-closing tool, a week for a daily driver. Retire it only after the new version has survived the work it was upgraded for.
Does uninstalling the new version always restore the old setup?
It restores the old program, but data the new version converted may not convert back. That is why pilot rings and, for critical apps, a data backup before deployment are part of a real rollback plan.
Who decides to roll back?
Whoever owns the business impact — agree the trigger and the decision-maker before the rollout, in writing. In the moment, the admin executes; the decision should already have been made by the rule you set.
This guide is based on the Technical Anshu video on remote software deployment with ManageEngine Endpoint Central • Stuck on a step? Ask in the video comments and you will get a reply 🙏