I also have many Gb of Arc 3 data that Arc 4 is holding back from deleting and presumably failing to migrate - “The old app’s databases contain data that hasn’t been migrated to Arc Timeline 4. Use ‘Migrate from Arc Timeline 3’ in Settings before deleting.”
I want to add an additional observation in case it is useful. Namely, when I watch the Importing timeline data process it appears to attempt to go through three stages. The first two get to 100%, the first (importing timeline items) very quickly, the second (Importing locomotion samples) in a few minutes, the third (unnamed) however just sits at 0% for a while and then the migration terminates.
Maybe this is normal, maybe this is normal for the known issue, or maybe this is a useful additional data point . Hopefully not wasting your time.
I’ll leave it to Claude to reply properly, because their code assessment will be more reliable than mine in terms of matching what you’re seeing. But I can say that we’ve just submitted 1.7.0 to the App Store today, which has hopefully the necessary fixes! As long as Apple don’t muck about with the App Store review process that should be going live tomorrow.
But yeah, Claude will be able to explain in better detail both what that release contains that’s relevant, and what the behaviour you’re seeing means. (And whether it’s expected behaviour or not - I suspect it is normal/expected, even if a bit weird. But yeah, Claude’s reply will be the more authoritative answer on that).
@GCameron00 Not a waste of time at all — that three-stage description decodes cleanly, and it’s useful, because it tells us your migration is finishing properly each time.
What the three stages are. The two named stages are the copy passes: timeline items (fast on a re-run, because every item already exists and is skipped) and locomotion samples (the bulk of the data, hence the minutes). The unnamed third stage is the wrap-up: importing any notes, re-indexing dates, re-checking what’s left in the old database, and re-linking HealthKit workouts. Those steps don’t report progress, which is why the bar sits at 0% with no label until the screen closes — and the screen closing is the migration completing. If it had actually failed you’d see a different screen: an orange “Import couldn’t be completed”, with Send Logs and Try Again buttons.
So why does Storage still say there’s unmigrated data? Because on the version you have, the check that decides that has a known blind spot (BIG-664). It uses the dates of a particular slice of the data as a proxy for “has everything come across”, and for some data shapes that proxy stays unsatisfied even after a migration that ran to completion — which matches what you’re describing, and it’s the same shape as the thread you linked from. Running Migrate again on this version won’t change it: the migration is doing its job; it’s the check that’s wrong.
What 1.7.0 changes. That check is replaced with a direct one — the old database’s records are compared against what’s actually in Arc Timeline 4, rather than inferred from dates. Once the update reaches you, open the app, give it a moment, then have a look at Settings → Storage. Two possible outcomes:
The Delete button is available, or the note under it has changed — everything was across all along. If the note now says it’s waiting on the old app to go quiet, that’s the last gate: recording off in Arc Timeline 3, and it clears within the hour.
The note still says unmigrated data — this time it means it: the new check has found records the old one couldn’t see. Run Migrate once more (1.7.0 asks you to confirm first) and it will fetch them; the button unlocks after that.
If neither happens, say so here — on 1.7.0 the Debug Logs carry a line stating exactly what the check found, and that would tell us which case you are.
Nothing in your old data is at risk in the meantime. The only thing blocked is the Delete button, and that’s by design.
Update: 1.7.0 became available to me and I just updated (I have thoughts on - every upgrade does a database update - but for a different thread). I’m pleased to report a delete button is now available for me. So 1.7.0 resolves that issue for me, and obviously considers my migration was already complete. I’ve attached a couple of images showing Storage before / after in case anyone needs a reference point.
Before hitting delete, I went browsing around old history in my timeline. I noticed that dates from 2013 / 2016 (random examples), which are presumably from old Moves import, only have the locations and not movement between them. I literally see Arc open the date with, say, six locations and then fill in ‘data gaps’ between them.
Is this normal? Is it worth opening a separate thread on this new observation?
Good to hear 1.7.0 unlocked the Delete button, and thanks for the before/after Storage shots.
On the 2013 and 2016 days: what you’re watching is the new app’s processing at work rather than something happening to the data. When it opens a day and finds two items with a stretch of more than 15 minutes between them and no recorded movement in that stretch, it marks the stretch explicitly as a data gap. The old app never marked those, so days from the Moves era, where the export carried the places but little or no movement between them, are showing their empty stretches drawn in for the first time. The gap items are labels on stretches that were already empty, not new holes. Nothing needed from you on it, and no separate thread needed.
. Hopefully not wasting your time.
