How to present an upgrade?

When upgrading an off-the-shelf application or service that is configured for a client, rather than code customized, you would expect the supplier to provide a script that is executed to convert all necessary data and configurations. A script like that must of course be executed a couple of times and proper testing done in each iteration by both the supplier and the client.

This is all fine and well, but if the customer also wants to take advantage of new functionality or if new features force the client to make additional configurations, then the upgrade has to be planned more carefully. When upgrading software that is a configured service there is always the element of client and supplier activities and expectations that have to be aligned and met. Still, a project like this is small and well defined which should make it easy to plan and execute.

Considering these facts one might wonder why these projects fail so often and why the client seem surprised every time an upgrade like this fails. In my experience, the villain of the piece is - as usual when something fails - communication. The supplier presents the upgrade as a walk in the park and the client communicates internally about all new fancy functionality that will be available with almost no effort. Nothing could be more wrong - maybe it lies within the human nature to be naive when presented with the possibility to make a process smoother through new or improved features?