![Code42 upgrade](https://cdn2.cdnme.se/5447227/9-3/5_64e61dfa9606ee7f6350b87c.png)
![code42 upgrade code42 upgrade](https://payload.cargocollective.com/1/1/34526/9812154/Code42-8_1680.png)
![code42 upgrade code42 upgrade](https://datajar.co.uk/wp-content/uploads/2018/12/mobi_code42.png)
Microsoft Office 2011), it’s a separate item in Munki altogether, which means we also had to remove the old version from the client’s SelfServeManifest before installing the new version (otherwise, the old version would just reinstall). Since CrashPlan 6.5 isn’t just an update but an actual upgrade for us (think Microsoft Office 2016 vs.So I changed CrashPlan 4 and 6.5 to use an installcheck_script instead. Keeping the installs array would (without managed_updates) prompt users to upgrade to CrashPlan 6.5 or, worse, just upgrade them automatically (with managed_updates). We couldn’t use an installs array any more to tell Munki whether CrashPlan was installed or not.I’m not sure a jump from 4 to 6.5 would have been possible as just an installation upgrade anyhow. We had some added complications to our “upgrade” process, because our new CrashPlan server is a completely different server, and we weren’t migrating everyone at once, so we couldn’t just change the DNS to point to the new server. Now you have to use a deploy.properties file instead of custom.properties and userInfo.sh files. We recently made the jump to CrashPlan 6.5, though, and that workflow no longer applies.
![code42 upgrade code42 upgrade](https://netextend.de/wp-content/uploads/2015/08/bundle.png)
I had a great workflow for installing CrashPlan with Munki for older versions of CrashPlan (we were on versions 3 and 4 before).
![Code42 upgrade](https://cdn2.cdnme.se/5447227/9-3/5_64e61dfa9606ee7f6350b87c.png)