What should I expected?
Thank’s so far! 
So my new arm HaOS is running (not yet moved) and regarding external data drive I can see this:
It is not a partition but the whole drive. What does HA do with it? What filesystem? What commit interval? Does it take care of write amplification to don’t let the flash storage age unnecessary fast?
So many questions… 
Restoring my backup results in ha never coming back on port 8123 while reacting to pings 
I flashed HaOS again to sd card. The system is accessible but when I choose to restore my (full) backup on the onboarding page HA never comes back to a working state. Not even 5 hours later.
The host replies to pings but that essentially it.
Very frustrating…
So does HA even support changing architectures? Or what could be potential break points why things not work out (like they should)?
Restoring the backup on a different platform should work. It seems that something went wrong during restore. Try checking the logs in the console (ha supervisor logs).
What is the commit interval for the root filesystem in HaOS and what is taken for the external data drive? (@agners knows more maybe?)
The root file system in HAOS is read-only, so it never gets written to (unless you update to a new OS version of course).
As for the data partition: It is formatted with ext4 and uses default mount options. We don’t try to “optimize” something on our end. We rely on standard behavior of Linux and ext4.
It is not a partition but the whole drive. What does HA do with it?
HA is formatting the disk and set up a partition which then is automatically mounted as data partition. See also Common tasks - Operating System - Home Assistant.
Good know and what I actually was expecting because there were no “limitations” in all the docs I read.
Indeed, something goes wrong. But I’m not sure how I actually could access the logs? My device doesn’t have video out so I need to do this over network, but that is not (yet) possible at this stage because I would need to setup some ssh before 
…which is sadly stuck in the hard drive age. Default commit interval for ext is 5 seconds which can lead to heavy write amplification (high WAF) and resulting in a much higher wear out than necessary.
All flash storage suffer from this but specially “low grade” flash like sd cards and usb sticks can wear out very quickly and can have write amplification factors with 3 or even 4 digits (talking 100 or 1000 times faster wear out 
). SSDs also suffer a lot with the default commit of 5 seconds but typically can cope things better as they utilize internal cache and other techniques, still it will wear out the drive faster.
As an idea to be more flash friendly: armbian sets the commit interval to 600 seconds (10 minutes) and also uses a noatime flag to don’t write more data when only reading 
And one more time… Now after waiting for hours port 8123 actually is somewhat responding. Very very slow 
. Log in hardly works, but now I’m in for the first time 
The web interface is very slow… I’m trying to get my way to the supervisor tab to see logs and start the move to the external data disk… 
Let’s see… till now only full screen ads 
getting closer…
Finally some logs, green, yellow and red 
What would I do about them?
Moving data to external disk doesn’t work. The dialog closes before the process can be started:
supervisor logs:
ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/aiohttp/web_protocol.py", line 435, in _handle_request
resp = await request_handler(request)
File "/usr/local/lib/python3.9/site-packages/sentry_sdk/integrations/aiohttp.py", line 121, in sentry_app_handle
reraise(*_capture_exception(hub))
File "/usr/local/lib/python3.9/site-packages/sentry_sdk/_compat.py", line 54, in reraise
raise value
File "/usr/local/lib/python3.9/site-packages/sentry_sdk/integrations/aiohttp.py", line 111, in sentry_app_handle
response = await old_handle(self, request)
File "/usr/local/lib/python3.9/site-packages/aiohttp/web_app.py", line 504, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.9/site-packages/aiohttp/web_middlewares.py", line 117, in impl
return await handler(request)
File "/usr/src/supervisor/supervisor/api/middleware/security.py", line 139, in system_validation
return await handler(request)
File "/usr/src/supervisor/supervisor/api/middleware/security.py", line 205, in token_validation
return await handler(request)
File "/usr/src/supervisor/supervisor/api/utils.py", line 65, in wrap_api
answer = await method(api, *args, **kwargs)
File "/usr/src/supervisor/supervisor/api/store.py", line 120, in store_info
ATTR_ADDONS: [
File "/usr/src/supervisor/supervisor/api/store.py", line 121, in <listcomp>
self._generate_addon_information(self.sys_addons.store[addon])
File "/usr/src/supervisor/supervisor/api/store.py", line 81, in _generate_addon_information
ATTR_ADVANCED: addon.advanced,
File "/usr/src/supervisor/supervisor/addons/model.py", line 222, in advanced
return self.data[ATTR_ADVANCED]
File "/usr/src/supervisor/supervisor/store/addon.py", line 19, in data
return self.sys_store.data.addons[self.slug]
KeyError: '243ffc37_pigpio'
The system will initiate the restart when pressing move. Depending on the amount of add-ons etc. it could take a while until that actually starts.
The issue in the Supervisor logs seems like a bug, probably worth opening an issue in the supervisor repository.
Problem is the Dialog disapears before I can press the move button. After selecting the device the dialog vanishes immediately. It’s visible in the video I posted.