A client, who lives 2000 miles away, has asked me for help transferring everything from his cir. 10-year-old MacBook Air to his new M2 Air. I've done some searching and found answers to my questions... but one. ........ Also, can someone recommend a VNC client I can use to log onto his machine if necessary?
Two parts. doing the VNC part first.
By default VNC is not encrypted. So unless you have some way of creating a VPN tunnel to that remote client's local LAN some 'random' VNC client is probably a bad idea if going to be administration tasks on the remote system.
Several VNC servers do offer encryption but only when paired between their server and their client. ( Some folks do ad hoc VPN by creating a SSH tunnel between client server. If remote client is on a LAN behind a router/firewall that also requires hoops to jump through).
I've used RealVNC over a VPN connection. The server side of the pair costs money to license (and if want to login via a cloud account path (through a firewall and not direct IP address that is likely behind a firewire need the enterprise license). The client is free ( but do not get encryption with other VNC servers ).
Apple's 'built in" screen sharing is suppose to be encrypted secure.
On your Mac, use screen sharing to connect to another Mac on your network and display its screen on your Mac.
support.apple.com
https://www.macworld.com/article/671414/how-to-remotely-access-control-a-mac-desktop.html
This can use Apple's "find by AppleID" servers to find the Mac. And is suppose to be using the same stuff as AppleRemoteDesktop software uses. Which is a bit "slim" on the encryption
" ... All Remote Desktop tasks—except Share Screen, and the copying of data and files using Copy Items and Install Packages—are encrypted for transit. This information is encrypted using the AES with a 128-bit shared key that was derived during authentication. ..."
https://support.apple.com/guide/remote-desktop/encrypt-network-data-apdfe8e386b/mac
keystrokes are 'safe' but giving free looky-loo at what is on the screen.
Apple's default, free VNC facilities are really intended for trusted LAN networks; not random coast-to-coast connections.
I assume Migration Assistant transfers all the Intel-based apps to the M2. Will he have to just go into each app and update it to the Apple Silicon version? Will the M2 automatically recognize the difference and download the AS version? I guess it doesn't matter if it's a universal file. Will something like
MacUpdater speed things up?
A good sanity check would be to have the client got to system report
Apple menu > about this Mac > System Report > Software > Applications
Then sort by "Kind" column. ( Apple , Intel , Universal , etc. ) and then select "Print..." and do a PDF > Save to File .
Everything 32 bit is a problem. The Universal stuff is zero problems ( there is a 'fat' binary there that has both versions). On an Intel system there really should be nothing "Apple" installed.
Apps that are managed by the Mac App store should either be Universal binary or "fix" themselves on the next update ( or simply delete/remove and redownload).
Migration Assistant (MA) should shovel all of the 32-bit apps into a pile in a folder , if I recall correctly. ( Those are 'dead' there is nothing to do for those ). "rescuing" data from those apps should be done on the Intel machine before you do the migration.
The non appstore apps may or may not have updated with a universal binary. Some developers are download on link A if you have macOS Intel and link B if you have macOS Apple Silicon. That... migration assistant is not going to deal with at all. MA isn't going to chase down every random decision that every random developer made.
If it is a general x86 app that the developers have been regularly updating ... it should just work (via Rosetta 2). Nothing special need to do.
What will happen is the first time that user runs an macOS Intel only app is that it is converted by Rosetta2 . So it is not MA's job to cover the specific task you are trying to tag it with. Rosetta2 will recompile the Intel binaries into a Arm binary that is hidden from causal view. That will be run the first time and the arm binary run after that. ( some apps load libraries dynamically... those can end up being recompiled dynamically. But still transparent. )
That said, there is some stuff that Rosetta2 does not do. If the user has 6-16 year old drivers for quirky hardware. Rosetta 2 is
not going to cover those. ( they are dead. ) . If the user is using a more modern app that only makes AVX calls. Rosetta 2 doesn't cover the whole x86-64 instruction set. Some x86-64 apps have code which will load slower alternative code if AVX is not present. That older, slower code will pass through the compilation process. So to some extent won't know until run the app. ( developers who are proactive probably would have sent email warnings if there was major Rosetta 2 hiccups. But with a 10 year old machine, there are also likely apps that no one is putting effort into anymore . )
If they are running any x86 virtualization software. That is largely dead also. Rosetta2 doesn't do that class of software either. If want to run Arm code in new Arm VM then likely need new software. ( There are some emulators to run x86 code but slower and generally more cumbersome. )
Also, if any of you have encountered any landmines or best practices beyond
Apple's Support Page I'd appreciate you passing them along. AFAIK the old machine is working fine besides a few out of disk space errors he's been getting from his 128G HD.
My recommendation would be to do two backup snapshots. One last one with this overstuffed disk drive. Second, do some very substantive house cleaning ( deinstall 32-bit apps lying around. Get rid of apps haven't barely used . rescue data from apps that are about to die (no app on modern macOS Apple Silicon supported., etc. ).
If there is any Antivirus software I would consider deinstalling that also before migration and do a completely fresh install after migrations with appropriate, fresh downloads. ( some Antivirus implementations have crufty x86 crap in them ( *cough* Norton) . Any kernel-extension/driver that is x86 won't work (and some install these to run their own firewall 'features' and other stuff. ) . And need to be able to download Rosetta 2 or other Apple mothership updates during the initial set up. )
There are also a number of things that Apple has warned about in the last 3-4 upgrades before Apple Silicon came out about QuickTime codecs that were going away . etc. If trying to snap shot a really old , stale macOS on Intel image over to a new system then current migration assistant may not hunt down all of those 'old' problems. MA is good at migrating from still supported to 'newest' ; not huge leaps.