An Umbraco upgrade is easier to explain once you know what will not come with you. The date is the last decision, not the first.
Know the version you are leaving.
Write down the Umbraco version, the latest patch on that version, and whether the site is still receiving security fixes. A version that is already out of standard support is a reason to plan, not a reason to rush a weekend cutover.
The route is not the same from every starting point. A long-term support release can often move forward in one planned release. An older site, or one with a heavily customised backoffice, may need a new implementation and a content migration. Both are valid. They need different calendars.
List what was built around the CMS.
Templates, forms, integrations and backoffice extensions are the items that decide the size of the work. Packages need the same list. A package that has no supported release for the target version is a rebuild, even when the content itself is simple.
Ask who understands each custom piece. If the answer is a person who has left, or a supplier you no longer use, that item needs time in the plan. Cold Banana reviews this with teams in Dubai and the wider UAE before recommending a target release.
Rehearse on a copy.
Run the upgrade on a copy of the site, with a copy of the content. Editors should click through real pages, not a demonstration page created for the test. Forms, logins and the connections to other systems belong in that rehearsal.
Agree what would make you roll back, and who can make that call. A release window is only useful when the checks after go-live are written down as well.
Then choose the weekend.
Book the date once the test copy has been through the journeys that matter. Tell the editors when content needs to freeze, and when they can publish again.
If you are not sure whether the next step is an in-place upgrade or a new build, start with the version and the custom code. The upgrades page on this site sets out the kinds of route. A conversation can then put your site on one of them.
