Scheduled Date
Section titled “Scheduled Date”The Scheduled Date is the date and time a job may start. A Ready job is not claimed before it, so you can set jobs to Ready today for a migration wave that starts at the weekend. A new job's scheduled date is the moment it was created, so it can start as soon as it is set to Ready.
The actual start can come later than the scheduled date: the server runs at most four jobs at a time, and takes the waiting ones in order of priority and scheduled date.
The Jobs table has no Scheduled Date column: rest the pointer on a job's title to see it, and set it in the job dialog. Change selected jobs … in the Actions menu, with the Scheduled Date switch on, gives every ticked job a new one — tick a group's box in the tree for the whole group. See Change many jobs at once
Recurrence: repeat a job
Section titled “Recurrence: repeat a job”Recurrence repeats a job on a schedule: None, Daily, Weekly or Monthly. When a recurring job's run finishes, the job goes back to Ready instead of Finished, with its scheduled date moved to the next occurrence, and waits for that date.
- The time of day is kept. Every occurrence is counted from the job's own scheduled date, so a daily job set for 02:00 runs at 02:00, across daylight-saving changes too.
- Missed occurrences are skipped. A job that could not run for a while — the server was stopped, the job was disabled — runs once as soon as it can, and then carries on from the next occurrence, instead of catching up on every one it missed.
- Month ends are respected. A monthly job on the 31st runs on the last day of a shorter month, and returns to the 31st the month after.
- Run now counts as the next occurrence. A recurring job set to Run now before its scheduled date runs at once, and that run takes the place of the one it was scheduled for: the schedule carries on from the occurrence after it.
- A cancelled run stops the cycle. The job ends Canceled instead of going back in the queue: someone asked for it to stop. Set it to Ready again to resume.
A recurring migration is incremental by nature: with the default rule, Add New Overwrite Existing By Newer, each run copies what is new or changed since the last one. See Rules for adding and overwriting files
To have each run also read only what changed, switch on Incremental (only files changed since the last successful run) under From Date: the job's From Date then moves on after every successful run. See Incremental runs: only the files changed since the last run
Recurring jobs for a standing copy
A recurring job keeps a regularly refreshed copy of a library in Nextcloud — for a long coexistence period, or as an independent copy of the documents a critical business function depends on. Match the recurrence to how fast the content changes: daily for active document sets, weekly for reference material.
Selected libraries, not a backup
Microsoft 365 throttles heavy and frequent reads, so recurring jobs cannot keep a whole tenant in sync. Keep the recurring scope to fewer than 20 libraries of under 50,000 files each as a rule of thumb, never more than about 50 libraries in all. A standing copy protects selected libraries for an emergency; it is not a backup of SharePoint Online, SharePoint Server or file shares to Nextcloud.
Read more in Digital Resilience Operation (DORA) and Cutover: Traditional and Enhanced Migration
Priority: which Ready job goes first
Section titled “Priority: which Ready job goes first”When more jobs are Ready than the server can run at once, Priority decides which it takes next, and the scheduled date decides among jobs of the same priority. A job set to Run now comes before all of them, whatever its priority and scheduled date — see Job status
| Priority | When to use it |
|---|---|
| High | Claimed before anything of a lower priority. For a job that has to go first. |
| Medium | The default. With every job on Medium, the scheduled date decides on its own. |
| Low | Goes last, once nothing else is waiting. For jobs that can run whenever there is room. |
Four jobs at a time
Section titled “Four jobs at a time”The SMART Migration server runs at most four jobs at once. A fifth job set to Ready waits until one of the four has finished, then starts. A long list of Ready jobs is therefore normal during a migration wave, not a fault.
See also