 |
| macOS Catalina (source: Apple) |
| Application Name | Application Owner | Min. Version Required | Catalina Ready? | Notes |
|---|---|---|---|---|
| Google Chrome | Mac Eng | TBD | ☐ | 20190619 - Version 75.0.3770.100 functions as expected, unsure about notarization requirements (@EKW) |
| "AV Software" | @Security Person | ☐ | 20190618 - Version 1.2.3 appears to be functioning normally, waiting on confirmation of support from $vendor | |
| "Random Internal App" | @Developer Person | RIP ☠️ | ☐ | It's dead, Jim |
| etc. ... | ☐ |
Breaking down each column:
- Application Name: Pretty straightforward, this is the name of the application, service, or feature that you're testing. The focus here are services and applications that you serve to your customers, or are required for security compliance. Going after every bit of software is pretty much impossible, especially if Mac users at your org are admins and can install whatever they need. Go after the big fish.
- Application Owner: This is probably the most important column of this table. Here, use whatever tagging/shaming methodology available in your internal CMS to call out who is responsible for that app and vendor relationship at your org. Listing them here and tagging them so they get a notification helps drive home the fact that you are relying on them to pressure vendors to be ready for the new version of macOS before it is released. Use this opportunity to build a good relationship with that person/team, and let them know that you want this to be an opportunity for them to deliver a great customer experience to Mac users at your org. The last thing you want is for that team to look like it's their fault your customers can't upgrade to the newest macOS version on release day.
- Min. Version Required: Some vendors never publish a specific version that is required for compatibility with a new OS, but some do. If they do, put that version number here, and make upgrading to that version number a minimum requirement for anyone prior to upgrading to the new version of macOS on release. If a vendor doesn't release a minimum version number, use your best judgement to determine what that minimum version should be based on your testing and user feedback from early adopters.
- Catalina Ready?: This column is simply a checkbox column so people (customers and partners in other departments) can see at a glance if an application is ready for the new OS. The example here is Catalina, but you can replace that with any version you're aiming for (hopefully you're always aiming for the newest OS).
- Notes: Pretty self-explanatory, but this is where you can put testing notes, relevant correspondence regarding compatibility from vendors, if something is like super busted, or whatever else. We like tagging ourselves when we add notes so it's clear who added it and who to follow up with on notes/issues that arise.
We store this list on our internal documentation/CMS (happens to be Confluence here) and share out the link. We also create a #version-readiness channel on Slack that early adopters, support, partners from other departments, and curious customers can join to see the testing and evaluation status of the new OS.
Leading up to the release of Catalina, and as we gather more information, we put together a group of policies that function as our customer-facing "readiness" updates prior to upgrading and throw all of that in Self Service.
Let me know if you find this template useful, or if you have some other way to track readiness prep at your organization in the comments section.
Mac do-gooder, knitter, cinephile, jaded punk, comic & toy collector, Chicago sports obsessed, console gaming, vegan, sxe lady with a PhD and lots of tattoos.
