Asking for a heads up on major upgrades

AppleScript
#1

Hi, As some of you may recall our systems and IT departments have always dragged their heels on allowing us to upgrade our macs system software and application software. So I’ve been using 10.11 os; InDesign CS6 and Office 2011.

Our new owners have new policies and their plan is to upgrade everyone before March 31.

I have literally thousands of scripts I’ve written over the years, dozens used every day by me and other users. Some are applets, some droplets and most are scripts run from menus, palettes or called from within applets or droplets.

So my questions are: What roadblocks will I be facing as I try to upgrade all at once?

Currently I’m not using code signing and not notarizing and not even altogether sure what those are and if I need to.

I’m also no clear on how much the Adobe, Office, and mac dictionaries have changed over the years. I’m hoping my scripts don’t all break.

Any suggestions or advice?

As for Adobe inDesign specifically we have a vendor who provides a plug in that’s mission critical that only works with CS6. They’re promising to upgrade, but they’ve been promising that for years.

Does anyone know if I’ll even be able to install CS6 on the newer Mac OS?

Thanks for any advice!

#2

Whatever you do, do NOT upgrade all at once. It will likely be a disaster, and you will likely be blamed. :wink:

Here are my suggestions:

  1. Develop an Upgrade plan and schedule that minimizes the impact to the business
    • Make sure you involve and discuss with senior management, and all major stakeholders
    • Ask if there are going to be any windows that are critical to business workflow, and any that provide the best opportunity for “down time”.
    • Tell them to expect problems, especially unexpected problems.
      .
  2. Establish a small pilot project of just a few users
    1. Make sure you have at least one user for each app that might be affected
    2. Start with one user, maybe yourself, who is most receptive to testing the upgrades
    3. Do a FULL backup on that user’s Mac.
      • Make sure you know how to do a full and a partial restore before proceeding.
    4. Perform ONE app or OS upgrade at a time, and have the user fully test his/her workflows, testing all major apps
    5. Proceed to upgrade of the next app ONLY when all is working well with the prior app.
    6. Keep copious notes, and ask the user to do the same. You could even prepare a form (MS Word or Pages) that list each step and have a column for the user to fill in with comments. It is important to record successes (no problems) as well as failures.
    7. If the user encounters anything unusual or suspect, have them immediate do a screenshot of the region where the message or issue occurs, and list everything they were doing just prior to the issue
      .
  3. Create small groups of the remaining users to be upgraded after you have a successful Pilot Project, with all of the users successfully upgraded, then
    1. Again, a full backup of each users Mac before you start
    2. Make sure you follow the revised upgrade process you learned from the Pilot Project
    3. Upgrade and test the OS upgrade
    4. The upgrade and test one app at a time.

Here is an alternate approach.

  • I don’t know if this is possible/feasible with Macs, but back during my Windows days we would create a fully tested and working hard drive image that has everything upgraded as you need it to be.
  • Then, it becomes a simple matter of pushing that hard drive image out to each users machine.
  • Of course, a major issue to overcome is dealing with each user’s individual data (that is kept only on his/her hard drive) and with account/app logins.
    • This was easily supported in a Windows Server environment, but since I’ve never managed a Mac network of multiple users, I’d don’t know what tools Apple offers.
    • But if Apple does have the right tools, this could be the best approach, since the hard drive image you are pushing out has been fully tested and everyone knows it will work.
    • This could minimize the risk and downtime of the business.

Good luck, and let us know how it goes.

#3

This is the approach we’ll be taking. Unfortunately their timetable doesn’t allow the kind of careful and deliberate process you described. Luckily we don’t have a large number of users with a large number of scripts. A few users are running a lot of scripts most users only run a couple scripts.

#4

CS6 won’t run under Catalina.

Most of your InDesign scripts should work OK with the latest version, or only need minor tweaks. Your Office scripts might face some permissions/sandboxing issues.

Whether you need to notarize will probably depend a bit on company policies, but it only applies to applets/droplets.

I suggest you look around some of the Mac admin sites for more general advice about upgrading.

#5

With the greatest respect for what you have been able to accomplish with having developed thousands of scripts with dozens in daily use, of various types, I would like to offer some thoughts having worked through a variety of organizations and software development projects large and small, and having done lots of scripting myself on various platforms:

This feels to me like it probably will become a much more complicated, time-consuming, resource-intensive, and demanding project than I think you may perhaps realize and be preparing for.

To emphasize ShaneStanley’s point, if you’re mission-critical with outside scripts that can only run with CS6 and your organization is planning to roll out a major upgrade to Catalina, may want to anticipate a showstopping problem that will involve re-planning the entire upgrade. Timetables -can- be changed in the face of new information.

You’ll need to get buy in -and involvement- with your top planners and decision makers, as well as your end-users.

Your few users who run the majority of your scripts will probably be heavily impacted by the process of upgrading to Catalina, and by migrating the scripts to the new platform.

JMichalTX’s points (2) 6. and 7. are -very- good advice.

It’s genuinely hard to know what users are experiencing from a verbal description, even if you are all close together in time and space.

Expect the unexpected. Expect things you can’t anticipate to eat up a lot more time than you can plan for.

Develop some kind of a system to record problems. It doesn’t have to be a full defect tracking system, but you will need at least a spreadsheet or some kind of a document to track input from users, dates, affected scripts, what machines have which versions of what scripts and when they were deployed, etc.

Aparently there are some apps in Catalina that have serious bugs involving their scripting interfaces.

Do you have any documentation? Test plans and procedures? Measurable objectives for what constitutes success? Timelines with identified critical paths? Thse are all basic elements for a successfull rollout.

This might be a good time to think at least a little about your entire scripting architecture, and consider how your choices of scripting languages and design will play out in the future.

If you don’t already have an Apple Developer account that would be a very good thing to invest in.

Lastly, consider bringing in some help. This could greatly increase your chances of success in an accelerated schedule. You’re wearing a lot of hats here - requirements, design, development, debugging, testing, integration, systems, user support, planing, project management. Someone with solid experience in this area could help take a lot of weight off of your shoulders, and this project might not even be feasible for one person to do, even if there were a more realistic schedule.

#6

Thanks, everyone, for the good advice. Right now the ball is not in my court.

#7

Imaging on macOS is effectively dead in the sense you’re talking about, especially for T2-equipped macs.

I cannot, can. not. recommend strongly enough that step one of this upgrade be to implement some form of MDM system. There are more than a few out there, JAMF, MS Intune, gobs of them. (Which one you should go with is highly specific to your setup, there’s no way to advise on that without way more information including budget.)

A proper device management system will make hundreds of potential problems literally disappear. It will make application updates orders of magnitude easier, and help avoid a lot of the warning dialogs unmanaged Macs get.

Including updating operating systems correctly (read not machine images.) Apple has a ton of documentation on this in their business section.

I’ve had to deal with your situation before. Doing it manually will cause no end of pain.

#8

I’ve done this for InDesign scripts for Mojave and soon will for Catalina but with only dozens of scripts… these were my main hurdles:

InDesign, sometimes the dictionary says one thing but it no longer works,
InDesign’s Applescript after CS6 (or was it CS5?) stopped supporting “as text” for operations like “set myVariable to myOtherVariable as text”
Instead you have to manually change it to “set myVariable to myOtherVariable as string” (search for “as text” and replace with “as string” in your scripts or it will error out. (ALL my scripts used “as text”, ugh!)

InDesign scripting of Data Merge is now buggy and broke our scripts for replacing images (not text) with Data Merge (ask me for workaround details if that is something you do).

That’s all that hit my InDeign workflow for plain scripts.
If you run them from InDesign’s script panel and they are saved as scripts or text, you won’t need to sign them.
Also can run them from from FastScripts or Script Editor.

Not sure about script bundles, but saved as “Application” will have some issues without signing and Notarizing by Apple. In Mojave and I think in Catalina, you can work around them in System prefs and by carefully saying “yes” to permission prompts (“Let myApp talk to InDesign?”). One wrong answer will lock that script-app out forever (it won’t ask again, just deny access) without resetting all prompts in terminal. If it is an Application (or a Bundle?), there are new restrictions about what can go in which folders inside the bundle.

You’ll may get those permission prompts if your script talks to other apps, like Word, etc. but only the first time you talk to that app in InDesign.

If your scripts call any 3rd-party helper apps or load libraries, they have to be 64-bit (fairly recent), not 32-bit and location/path of libraries might need updating, which Script Debugger now makes easier.

You can’t really use any 3rd -party Scripting Additions anymore, need to replace with a (new) AppleScript library or AppleScript Objective-C.

#9

Thank you , that’s also very helpful

#10

@estockly,

I was not sure that “MDM” meant, but a bit of searching turned up this:
Master Data Management Software – a review of various MDM vendors

Please let us know which approach and management SW you end up using.

#11

I have no choice. I am but a super user in a large network.

At best I’m hoping to be able to test all the software I need in advance.

I thought MDM meant mobile device management.