The best way to migrate to my new MacBook Pro M1 Pro

Currently I use a late 2013 MBP retina, 16 GB RAM, 512 GB SSD.

Any day now my new 2021 MBP M1 Pro, 32 GB RAM, 1 TB SSD will arrive.

What’s the easiest, least time consuming, most reliable way to migrate to my new MBP?

I have prepared USB C connectors and hub ports.

I have a Time Machine backup and a CCC clone on external drives. My Photos library is on an external SSD and I’d like to bring that internal.

I also have iCloud, with Desktop, Documents, and Photos synced.

And there is a Backblaze complete backup.

I would like to not lose my local svn repositories for programming I do.

So what’s the best way to proceed when my new MBP arrives?

Migration Assistant.

Thanks. I’ll take a look.

Funny you should ask that. Howard Oakley just posted an article about the migration process:

Key points include:

  • Create a new admin account (same name as your old Mac’s admin account) and use it to upgrade macOS to 12.0.1 before you try to migrate anything.
  • If you were in the Monterey beta program, you may want to exit it. Otherwise Software Update will try to install the latest beta updates instead of the latest released updates.
  • Use Migration Assistant.
  • After migration, you might find yourself re-enrolled in the beta program if the original computer was enrolled. Unenroll for real. The article describes some things to try, if you need to.

My own personal experience (migrating from a 2011 Mac mini running Sierra to a 2018 mini running Catalina) is that Migration Assistant mostly works, but it glitched for me. For reasons I’m not 100% clear about, it migrated my apps and all of the login accounts on the computer except for mine. My account ended up blank (like a new account).

I (sort of) resolved this by manually copying the entire contents of my home directory from a Time Machine backup to the new computer. It put all my documents and such in order, but I had to manually re-set-up some apps (like telling Music and Photos to use the libraries I copied over instead of new blank libraries).

Looking back, I suspect I could have used Migration Assistant to manually re-migrate my account, but that didn’t occur to me at the time.

Surprisingly, Migration Assistant correctly copied over the contents of the /usr/local directory, where I install all of the Unix utilities that I manually compile for myself. And everything just worked (because they were already 64-bit).

And, weirdly, it created a home directory for the macports user. I don’t know why. That account is one that nobody ever logs in to. It was created by the MacPorts system, and is only accessed via the MacPorts build system.

And, speaking of MacPorts, if you use it, you need to reinstall it and re-install your ports. You need to do this whenever you install a major update to macOS (e.g. from Catalina to Big Sur). Otherwise, when you try to use it, the port command will give you an error:

> sudo port selfupdate

Error: Current platform "darwin 20" does not match expected platform "darwin 19"
Error: If you upgraded your OS, please follow the migration instructions:
OS platform mismatch
    while executing
"mportinit ui_options global_options global_variations"
Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform mismatch

The solution is to do what the error tells you to do. Follow the official migration procedure: Migration – MacPorts :

  • Install/update Xcode, including the Xcode CLI tools. Be sure to accept the license (launch the GUI or run a CLI command to do it)
  • Download and install the MacPorts system for your OS (Big Sur, in my case). It looks like the Monterey version is not out yet, so you might need to wait until it is released if you get a brand new Mac.
  • sudo port -v selfupdate, so MacPorts will update itself to its latest build.
  • Remove and reinstall the ports (a sequence of CLI commands - see the above link)

I’m taking a very different approach. My current 2015 MBP has always been migrated from previous machines - from as far back as I can remember. I retired earlier this year so I’m using the new MBP purchase as an opportunity to start again with a clean machine and only install what I actually need.

At work I needed things like Word and Excel but I have zero need for them now. Same for the Adobe Creative Suite products and things like Preps, CTP specific apps, TeamViewer, Fiery and many other company specific apps (many of which i wrote) which are no longer needed.

I’ll move my existing Desktop and Documents folders to iCloud which will automatically make them available on the new machine. Anything outside those folders I can easily handle and I have extensive backups in case of problems. I’ll have a major clean out of Mail knowing I still have my old machine if I desperately need to restore something from 10 years ago.

Most of the apps I still require will come back via the App store. There’s a handful which aren’t on the App store (XOJO, Capture One etc) but they’re registrations are handled with online accounts so no concerns of lost serials.

I’m looking forward to the catharsis. Now I just need the machine to arrive…

In my case I really can’t afford to lost anything. The Machine-to-Machine migration described in the support apps recommends both Macs having the same OS. That’s impossible in my case, so I guess I’ll attempt the Time Machine migration.

I know you can’t migrate a newer macOS to an older macOS, but with a new M1 MBP this shouldn’t be an issue. As Howard Oakley notes, you’ll want to first update the new MBP before you actually migrate. Once that is done, the new MBP will at the very least be on the same macOS (12.0.1) as any existing older Mac. From there on it should be smooth sailing.

I am the world’s Least Intuitive Human. (Just ask my wife! :wink:) Howard wrote a fantastic article, he even followed up with a clarifying question I had, and I still managed to screw it up. For whatever reason, I read the above as “create a new account named ‘admin’”. It didn’t sink in that my old account was the admin account being referred do. Doh!

So I did that, and then updated to macOS 12.0.1 as ‘admin’. And then I realized…oh, if I keep going and do the Time Machine restore via Migration Assistant, my old account is going to be the subordinate admin account, not the primary. And that (apparently) is bad, or at least sub-optimal.

Fortunately, nothing lost, except some time and a tiny bit of pride (the latter probably a good thing). Tried the Erase Assistant, freaked out when it declared “Select a Wi-Fi network from the menu” and there was no menu (honest!). Finally got into recovery mode for real, reinstalled the OS (at least it was 12.0.1!), created my one-and-only, same-as-before admin account, and now I’m ready to move forward with the migration.

Telling this tale in hopes that there might be one other person out there who might be heading in the same direction. Unlikely, but…you never know.


Since I actually wanted to use the Setup Assistant rather than the Migration program, I used a slightly different path for my new MacBook Pro. I initially started it up with a throwaway admin id and postponed everything I could (i.e no Apple id and no other setup) except connecting to my WiFi network. If I plugged in an Ethernet cable, I could have avoided even that. Then I upgraded it to the current system release 12.0.1. Finally, from System Preferences, I used the new Erase All Content and Settings item to return it to factory-new condition except with the correct version of the operating system. From here I performed a setup by the book.

That’s exactly what I did. For unknown reasons, the Erase Assistant demanded I “select a Wi-Fi network from the menu,” but would not show the Wi-Fi menu (and believe me I looked for it), so that’s where I got stuck. Maybe I clicked the wrong button somewhere, or…who knows?

Not clear what the throw-away account is supposed to achieve. You can set up a real account, do the sys update, and only then configure all remaining things like iCloud etc. after the fact.

FWIW, my normal account is not an administrator account.

I have a separate account (which I did call “admin”) with administrative privileges. I almost never log-in to that account. The account I normally use (and the ones for other members of my family) are not administrator accounts.

When I need to do something that requires administrative permission, macOS prompts me for both the name and password of an administrative account. For example:

Screen Shot 2021-11-12 at 11.30.19

The only downside to this approach is that non-administrators aren’t automatically granted permission to use the sudo command from terminal sessions. Instead, you must either first switch to an administrative account or update the /etc/sudoers file to grant yourself permission.

  1. Traditionally because migration would not overwrite existing accounts and my old computer had a later release of the OS than the new one shipped from the factory, I would need to perform the system update before migration. Because I wanted my migrated administrator account to be account ‘501’, the only way to do this was sign-in with the shipped OS, upgrade it and then use recovery to ‘reinstall’ the upgraded OS and do setup[ with my ‘real’ account. I didn’t fully trust that one could use Migrate to overwrite the initial account used for setup.

  2. I wanted to test the ‘Erase All Settings and Content’ option of System Preferences as I will need to use it before passing my old MacBookPro on to other family members. It seemed to me that since there was no need to essentially install the OS twice, it wouldn’t be more time consuming than using Migrate after initializing the system.

I’m not arguing for superiority of my method, but I figured there was no cost to doing it.

I just migrated from my late 2013 MBP running Big Sur to my new MBP running Monterey and let the migration assistant take care of it. It ran about 5-6 hours and that was that. That was the easiest part of the process.

I’m not sure that having the ‘migrated administrator account’ be 501 vs being 50something_else is really necessary…since all admin accounts are essentially created equal…much like FSMO roles replaced Primary Domain Controllers and Backup Domain Controllers over in Windows when Active Directory was invented. Since creating the first admin account on the new machine with the same account name then just replaces the home directory of that user on the new machine with the migrated home directory…and since all users are logged out while MA does it’s work…I assume it’s just copying the contents of ~/original_computer_501_user into the same named directory on the new machine and then fixing the permissions. Other admin users are created and migrated…and while the 50whatever numbers of the new extra admin accounts might not be the same as the 50whatever numbers of the old extra admin accounts it’s a simple matter for MA to just fix the permissions.

Speaking of admin accounts…I wonder if I’m the only user that has 4 admin accounts on all my machines? The first one, and then additional admin accounts for both my wife and I outside or our daily driver non admin accounts, and then an extra admin one for myself. I did this on all my machines.

In any case…I followed Howard’s guide and created the first admin account with the same name and let MA do it’s thing. I wish that any modified sudoers file would not get put in Relocated Files and left alone so remodification of that file isn’t necessary. I don’t do it a lot but using sudo from my daily driver account when needed is easier than su to admin and then issuing the command. I also enable the root user just in case…but it rarely if ever gets used.

In the Unix/Linux world, file ownership is determined by two integers - the user ID and group ID and nothing else.

If you copy files to external storage (if it is formatted in a way that supports permissions and ownership), then your UID/GID numbers will be applied to the files. If you later connect that storage device to a different computer where your UID/GID is different, you will see that the files are owned by some other account (which may not even exist).

I don’t know if this is a problem with Apple file systems (HFS+ and APFS), but until I learn otherwise, it’s something I’m going to think of.

Yep…that’s true in the unix world and having some experience with the back before I became a retired bum I know about those numbers…but this is macOS and while it’s based on unix it ain’t quite unix and I’m sure that Apple was smart enough to figure the permissions out. But it really doesn’t matter as if you create the first account on the new machine it will get 501…and then MA will log 501 out after authenticating and migrate the user accounts from the old machine including the same named 501 and MA then asks if you want to merge the user accounts or erase the old ~ contents and migrate from the old machine…and then it fixes the permissions which I’m pretty sure includes user and group IDs. If they had not done that…there would be numerous issues reported over the past many years of OS X and macOS…so clearly it’s not a problem. I’ve seen numerous reports from users that connect to unix servers in various forums, web posts, blog posts and the like and if the user ID was an issue we would have heard about it by now.

Nobody on macOS or OS X before cared about user ID or group ID…so it’s again pretty sure that all of that was already taken into account.

I’ve trusted Migration Assistant to do exactly that and been successful three times over the years, most recently from an old computer running Big Sur to a new one running Monterey. The migrated account has a UID of 501, just as it did on the old computer, so Migration Assistant handled the migration correctly.

Note: I have always set up the initial account using the same name and “short username” as the account on the old computer, which may not be necessary but seems like a good idea.

That’s not my experience if the account names and “short usernames” on both computers are identical. MA doesn’t ask anything, it just does the right thing.

There were numerous reports years ago about this problem; presumably Apple fixed Migration Assistant at some point and recent versions deal with the issue properly.

As I recall, one problem was accessing external drives which had “enable ownership on this volume” (or something similar) enabled. I don’t even see that as an option anymore; maybe disk encryption has made it obsolete.

There were also problems for people who kept photo or video libraries on volumes other than the startup volume. I’m not sure MA deals with that properly unless it propagates the “short username” correctly. It couldn’t possibly deal with it if the data is on an external drive which is not attached!

Same here.

If you use the same short username MA will offer the option to properly overwrite the account with the admin account you’re migrating from. The account will end up with 501. Even in cases where the account you migrated from wasn’t 501.

Howard Oakley recently wrote up a nice summary of exactly this process. In his example, the idea was to set up an admin account first without migration, only to update to 12.0.1. He laid out how to then use MA after updating to migrate on top of that account. The whole process works like a charm. MA these days is a mighty fine tool. :+1: :slight_smile:

Migration Assistant from time machine also “just worked” for me. And I had my Photos library on an external drive, which I then moved to my larger, internal drive.