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.
. Hopefully not wasting your time.