DutchDaemon said:
make delete-old and make delete-old-libs clear up the remnants of old versions. They should be invoked routinely when upgrading to the next major version (thought the latter only after reinstalling your ports or installing a compat port).
In general, they do a surprisingly good job, sort of like
mergemaster does in the opposite direction. However, both are reliant on the user being confident of what is needed and what isn't. Otherwise, a shared library not used by the system but used by one or more user application might get deleted, or the application might itself depend on an older library version that
make delete-old-libs wants to remove.
That's why I find it easier to set up a new box, install the desired new major version on it, then copy over all of the user / application data that I
THINK is needed. The existing box is still running, serving customers or whatever it does. I can then test on the new box until I'm confident that everything is working properly, copy over any data that was updated on the production box since my initial copy, then swap the IP addresses between the boxes, making the new version the new production box and retaining the old production box until all the users are happy. Then the old box can be repurposed or recycled. This also has the advantage of keeping up with newer hardware, which is more energy-efficient, more reliable (than hadware that's N years old, regardless of how good it was when new), and faster.
That's the method I use. The last release where I upgraded-in-place was 5.21 to 6.0. I deployed a couple of 7.x test boxes but never really got anywhere with them. The big push around here is to get everything on 8-STABLE less than a week old. I finished up most of that this weekend. Out of 80-odd systems, I an now down to 3 that are out-of-date / out-of-support. 1 is being shut down within the next 2 weeks, one is being sent before the end of June to the outside developer for a specific application one of our clients uses, with a note saying "Put the whole thing in one of
your colo facilities, or pull your application off and host it with some other provider". That leaves one server, which has some disgustingly complex in-house applications on it. Those are being moved off as quickly as I can code replacements with modern tools. So the old box is basically dying of attrition. These days, most of it's work is serving meta refresh responses to get clients to go use the new box.
I expect I'll make the jump from 8.last to 10.newest about 6 to 9 months before the 8.last EOL. Hopefully that will be 10.1 or 10.2.
I have a fair amount of practice with this - I have an visual editor I've been dragging around since 4.2BSD, with stops at Ultrix-11, SunOS, 4.4BSD, BSD/386 (BSD/OS) and eventually FreeBSD. It is the ugliest code you could ever hope to [not] see, but it still compiles and runs on each new release. It has had to be changed - for example, it relies on peeking inside
stdio structs to see what might be coming in soon, and the Great Stdio Shuffle around 4.4BSD required a bit of code changes.
Maybe start your next question on a different tack.