How to keep Monterey when upgrading to Ventura

For some, the best insurance policy when upgrading to the annual new version of macOS is to keep the old alongside the new, so you can switch between them until you’re happy that the new macOS can do everything you want. This article explains how you can do that.

There are now four main choices:

  1. install a fresh copy of Ventura in the same container as Monterey, on your Mac’s internal storage;
  2. install a fresh copy of Ventura in a separate container from Monterey, on your Mac’s internal storage;
  3. install a copy of Ventura on an external bootable disk;
  4. install Monterey in a Virtual Machine, and upgrade your main system to Ventura.

Of course, if you’re prepared for the extra work, you could transfer your current Monterey installation to an external bootable disk and upgrade the internal storage to Ventura.

Internal storage

Apple recommends the first option, in which you create separate boot volume groups for the two systems within the same container on your regular internal startup disk, and many users have done that successfully in the past. The most difficult step is in the Ventura installation, which can’t be an upgrade performed through Software Update, but must use the full Ventura installer app, and must ensure that it doesn’t replace Monterey. What you should then end up with is two complete boot volume groups, each with its own Recovery volume, which you can switch between using the Startup Disk pane in System Preferences, or its equivalent in Ventura’s new System Settings.

The process is fairly simple, and described here. Using Disk Utility, you add a regular APFS volume to the container your existing system is in. You then download the full installer for the version of macOS you want to install there, and when it asks you to select the volume on which it’s to be installed, click Show All Disks and select the new volume you just created. Cross your fingers, and that version of macOS should be installed as a new volume group there.

The advantage of doing this is that the two system installations share the same free space in that volume, so they can grow and shrink as you wish. As you become more confident of the new version of macOS, you can add more apps to it, and remove them from the old system. However, it’s more complicated, with a hidden Recovery volume for each system, and you may find the two systems competing for the same space. If anything goes wrong with that container, then you’re likely to lose both boot volume groups.

In the second option, instead of creating a new volume in Disk Utility, you create a new container, which involves repartitioning the disk. Provided that there’s ample free space, that should work without destroying anything in the original container, but if the disk is quite full it may not be possible. You then use the same option in the macOS Installer to select the volume in your new container as the destination of that system installation.

External storage

Creating an external bootable disk containing the new version of macOS has long been a popular choice, as it leaves internal storage alone. However, even that isn’t as simple now as it used to be. The process remains largely unchanged for Intel Macs without a T2 chip, but if your Mac does have a T2 chip, then you need to start by entering Recovery mode and then using Startup Security Utility to downgrade its secure boot to allow that Mac to start up from an external disk. Once that’s complete, it’s a matter of formatting the external disk and running the full Installer to complete the process.

Apple silicon Macs don’t require any change to be made to their Secure Boot, which is always able to start up from compatible external disks. However, for them to do so they need an owner and macOS can then create a LocalPolicy for them to be able to boot that Mac. Some users report great difficulties in getting this to work reliably, so I have written a step-by-step guide which I believe to be reliable.

In an emergency, it’s perfectly possible to boot an Apple silicon (or Intel) Mac from an external hard disk, but in practice you won’t want to wait a couple of minutes every time for that to happen. For more regular use, you’ll need an NVMe SSD connected by Thunderbolt to see boot times of around 20 seconds, only slightly slower than booting from an internal SSD.


Support for virtualising macOS also differs markedly between Intel and Apple silicon Macs. Intel models provide complete virtual machines in the major virtualising apps, including both Parallels Desktop and VMware Fusion.

That approach doesn’t work on ARM processors, and the only current way of virtualising macOS on Apple silicon Macs is using the macOS lightweight Virtualisation framework in macOS Monterey and Ventura, which is limited in its capabilities but much of the time delivers native performance. Specific shortcomings include:

  • Apple ID login isn’t available, so
  • third-party App Store apps can’t be run, and
  • iCloud connection isn’t possible.
  • Virtualised threads can’t be assigned to run on physical E cores.
  • Some features aren’t available on Monterey hosts, and require hosting in Ventura.
  • Big Sur and earlier aren’t available as guests.

Virtualising Monterey and Ventura isn’t available in VMware, but works very well in Parallels Desktop, UTM, and VirtualBuddy, as well as my more humble Viable.