In this guide 6 sections
Plan an upgrade around the working calendar, not the vendor’s. Choose a quiet window, test on a copy with real data, take a backup, brief staff, prepare a way back and keep support ready afterwards. Do the upgrade in stages where the system allows it, so only part of the work is affected at a time.
Start with what the upgrade changes
Ask the vendor for a plain list of changes. Which screens look different? Which reports change? Does the database change? Are other systems connected to this one, such as accounts or a website?
Then ask the business questions. Which teams use the affected screens? Which tasks are time-bound, such as billing, dispatch or month-end? Those tasks decide when the upgrade can happen.
Not every upgrade is needed now. Security fixes and end-of-support dates are good reasons to act. A new look alone may be able to wait for a quieter month.
- The list of changes from the vendor
- Teams and tasks affected
- Connected systems that may break
- Whether support for the old version is ending
Choose the timing around the business
Look at the working calendar. Avoid month-end, stock-taking, festival weeks, audits and major deliveries. A late-evening or Sunday window is often better than a weekday morning.
Agree how long the system will be unavailable and tell everyone early. Staff plan their work better when they know. Customers and suppliers who use any portal should be told too.
Where the system allows, upgrade one branch or one team first. A smaller group finds the problems. The rest keep working on the old version, which limits the harm and keeps most of the business running as usual.
Test on a copy with real data
Build a test copy of the system and load a recent set of real records into it. Upgrade the copy first. This shows how long the upgrade takes and what breaks before the live system is touched.
Ask a few daily users to run their usual tasks on the copy. Raising an invoice, closing a day and printing a report are good examples. Users spot problems that technical checks miss.
Keep a written list of what was tested and the result. The same list is used again after the live upgrade, so the two can be compared.
- Invoice, receipt and payment entry
- Main daily and month-end reports
- Printouts, labels and documents
- Links to accounts and other systems
Prepare the way back
Take a full backup just before the upgrade and check that it can be restored. Note the exact version being replaced. A backup that has not been checked is not a safe fallback.
Set a decision point. Agree in advance what failure looks like and who may call for a rollback. For example, if a main task cannot be done by a stated time, the team returns to the old version.
Keep a manual routine for the short period of downtime. Paper bills or a simple sheet can cover a few hours. Entries are keyed in once the system returns.
Support the first days after the change
Brief staff before the upgrade on what will look different. A short note with screen images works well. Hold a quick walkthrough for the teams with the biggest changes.
After the upgrade, have someone from the vendor or support team available. Staff should know whom to ask. Keep a log of questions and faults so that repeated issues are fixed once.
Review the upgrade after a week. Note what went well, what did not and what to change next time. Keep the notes with the checklist for the next upgrade.
Upgrade day checklist
A checklist of one page. It has four blocks: before, during, after and rollback. Before covers the change list, the test results, the backup and the staff notice. During covers start time, steps and decision point. After covers the user checks and the support contact. Rollback covers who decides and how.
Open a blank worksheet to printQuestions owners ask
How long should an upgrade window be?
It depends on the system and its size. A trial on a test copy shows how long the steps take. Add some spare time for checks and for a possible rollback.
Can we skip an upgrade?
Sometimes. Skipping is reasonable when nothing needed is lost. It becomes risky when security fixes are missed or support for your version ends. Ask the vendor which applies.
Who should test the upgrade?
A few daily users from each affected team, along with the person who owns the system. They know the usual tasks and notice problems that technical checks do not.
What if the upgrade fails during the window?
The team follows the rollback step agreed in advance. It restores the backup and returns to the old version. The upgrade is then rescheduled once the cause is found.