Running it again
Re-running is safe and naturally incremental, which is the good news. The awkward news is that there is no way to say "just the ones that failed".
The only route back is Back to selection, which re-runs the whole scope. Narrowing has to be done by hand with a search filter.
#What happens on a second run
Already-converted pages drop out by themselves. Once a page's macros are converted it no longer matches the search, so it is not even read.
Unchanged pages create no versions. A page is only saved when its content actually changed.
Already-migrated assets are recognised and reused rather than duplicated.
Failed macros are still there because a failure leaves the macro exactly as it was, so a later run can convert it.
#Narrowing to the pages that failed
The hints in the grouped issues tell you which pages need another attempt. Turning that into a scoped run means writing a search filter that selects them, because the run itself only accepts a filter and not a list of page ids.
If the failures are | A workable filter |
|---|---|
In one space |
|
Recent content |
|
Identifiable by hand | Label the pages, then filter on the label |
Labelling is the practical trick. If a failure class spans a handful of pages, add a label to them and filter on it. It is the only reliable way to express "these pages" to the run.
#When re-running is the wrong answer
If the cause is a permission problem, fix the permission or activate the admin key first. If it is a diagram version or tab problem, the repair tools fix it forward without touching anything else, which is faster and safer than a whole second migration.
#A few things that catch people out
Pressing Back to selection wipes the results on screen. Download the log first.
Keep source macros changes this: a page that kept its source macro still matches the search, so it is revisited on every subsequent run.
Repair tools accept a pasted list of page ids. The migration run does not.
#Related
Safe to repeat. Awkward to narrow.
