> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Scheduled Migrations in StagingPro for BigCommerce
> Schedule a bulk, selective or True Replica migration for a date and time in any timezone. StagingPro starts it for you, keeps two large migrations from running on the same store at once, and emails you the outcome.
Any migration you could start with the **Start** button can instead be scheduled for later. Pick a date, a time and a timezone, and StagingPro starts the migration at that moment with exactly the options you chose. Use it to run a large catalogue refresh overnight, to line up a production push for a quiet window, or to hand a migration to a colleague in another timezone without anyone staying up for it.
Scheduling is included for every organisation on StagingPro V2. It works for Bulk Content Migration, Selective Content Migration and True Replica runs, and it replaces the calendar scheduling of the classic app. Dry runs and Verify runs cannot be scheduled: run them now, then schedule the real migration.
## When to schedule
| Scenario | Schedule it? |
| ------------------------------------------------------------------------------ | --------------------------------------------------------- |
| Large catalogue bulk migration that would slow the store during business hours | Yes, schedule it for the overnight window |
| Production-equivalent UAT refresh before a release | Yes, schedule it for the quiet window before the test day |
| A migration your team wants to review together first thing in the morning | Yes, schedule it to finish before the review |
| Quick selective product update | No, run it now |
| Hotfix migration | No, run it now |
## Schedule a bulk migration
1. Open **Bulk Content Migration** and set it up exactly as you would for an immediate run: source and destination, storefront mapping, data treatment strategy and entities.
2. Click **Start Migration**. The confirmation dialog opens.
3. Click **Schedule for later** instead of **Confirm & Start Migration**.
4. In the **Schedule migration** dialog, pick the **Date**, the **Time**, and the **Timezone**. The dialog opens pre-filled with the earliest allowed time (5 minutes from now) in your browser's timezone; change it to the time you want, and pick another timezone only when you are scheduling on someone else's behalf.
5. Check the **Starts** line. It shows the exact start in the timezone you picked and in UTC, with a countdown, so you can confirm you have the right moment before you save.
6. Click **Schedule migration**.
The schedule details open straight away (see [after you save](#after-you-save) below), and the schedule appears at the top of the **Migration History** list, with any other pending schedules, soonest first.
A True Replica run is scheduled the same way, from its own confirmation dialog.
## Schedule a selective migration
1. On **Selective Content Migration**, pick the source and destination, open one of the six tabs and tick the items you want. A schedule holds the picks from one tab; switching tabs clears them.
2. Click **Schedule for later** (between **Dry Run** and **Start Selective Migration**; it is greyed out until you have ticked at least one item).
3. For product picks, the **Selective Product migration options** popup opens first, exactly as it does for an immediate start. Choose which sub-components ride along, then click **Continue to schedule**.
4. Pick the date, time and timezone, and click **Schedule migration**.
Your picks, product options, storefront mapping and stores are saved with the schedule. Only the time and timezone can be changed later.
## The rules the dialog applies
| Rule | Detail |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Earliest start** | At least 5 minutes from now. |
| **Latest start** | At most one month ahead (the same calendar day next month, in the timezone you picked). |
| **Timezone** | Any timezone in the list (standard city names such as Europe/London or Asia/Kolkata). The time is stored together with the zone you picked, and every screen shows it in that zone. |
| **Clock changes** | A time that does not exist on that date (the hour skipped when clocks go forward) and a time that happens twice (the hour repeated when clocks go back) are both refused. Pick a time outside that hour. |
| **Two heavy migrations on one store** | StagingPro calls bulk and True Replica migrations *heavy* and selective migrations *light*. A heavy schedule is refused when another pending heavy schedule uses either of the same stores (as source or destination) 12 hours or less from it. The message names the other schedule, its time and who requested it. |
| **A heavy migration already running** | You can still save the schedule. It is accepted with a warning that it will wait for the running migration to finish (see [what happens at the scheduled time](#what-happens-at-the-scheduled-time)). |
Selective migrations are light and are exempt from the two collision rules, both ways: they never wait, and they never make another migration wait.
The dialog checks these rules as you type and disables the **Schedule migration** button with the reason shown, so you find out before you click, not after.
## After you save
The schedule's details open as soon as it is saved. You can reopen them at any time from **Migration History** with **Details →**.
The popup shows:
* **Schedule number** in the header (*Schedule #13*). Quote it to the helpdesk: a schedule has no migration id until it starts, and the run it becomes carries the same number in its id (`SR-13-` followed by a code).
* **Status**: **Scheduled**, **Waiting**, **Starting**, **Could not start**, **Missed** or **Cancelled** (see the [status table](#the-statuses-a-schedule-moves-through)).
* **Starts**: the moment it starts, in its timezone, with a countdown.
* **Requested by** and **Requested on**.
* **History of this schedule**: every step so far, from *Scheduled by …* and *Start signal registered with the scheduler* through to the start, a reschedule, a cancellation, or the reason it could not run. Emails sent about the schedule are listed here too.
* **Cancel schedule** and **Reschedule**, while the schedule is still pending.
In the **Migration History** list a pending schedule shows **Scheduled** with a countdown in the **Migration ID** column, the migration's source, destination, mode and entity count, and its start time in the **Created** column. A **Could not start** or **Missed** row shows who requested it in place of the countdown:
Anyone in your organisation with access to StagingPro can see, reschedule or cancel a pending schedule. The history of the schedule shows who scheduled and rescheduled it; a cancellation removes the row, so its record is only available through the helpdesk.
## Reschedule or cancel
**Reschedule** changes the time or the timezone and nothing else. Open **Details →**, click **Reschedule**, pick the new time and click **Save new time**. The same rules apply as when you first scheduled it, and the change is recorded in the schedule's history with the old and the new time.
To change *what* migrates (stores, strategy, entities or picks), cancel the schedule and create a new one.
**Cancel schedule** asks you to confirm, then removes the schedule from the list. Nothing runs and no email is sent. A cancelled schedule cannot be brought back; create a new one instead. If a schedule you made has disappeared from Migration History before its time, a colleague cancelled it; the cancellation and who made it are kept on our side, so ask the helpdesk if you need to know who.
Both are available while the schedule is **Scheduled** or **Waiting**. Once it has started it is an ordinary migration, with the usual **Pause**, **Resume** and **Cancel** controls on its run detail.
## What happens at the scheduled time
At the scheduled moment StagingPro re-runs every check the **Start** button runs, against the stores as they are right then: the stores are still connected, the options are still valid, and the [safety rails](/vortex-apps/staging-pro/whats-new-v2#13-built-in-safety-rails) still pass.
Then one of four things happens:
* **It starts.** The schedule becomes a migration. Its Migration History row turns into the run itself, with a run id that starts with `SR-`, and it opens like any other run, with live progress and the run detail. The person who scheduled it receives a **started** email.
* **It waits, because the stores are busy.** If a bulk or True Replica migration is still running on either store, a bulk or True Replica schedule **waits** rather than starting on top of it. The row shows **Waiting**, the details name the migration it is waiting for, and it starts as soon as that migration finishes, for up to 2 hours after its scheduled time. A paused migration counts as still running, so resume or cancel it if you want the schedule to start. If the stores are still busy 2 hours after the slot, the schedule is marked **Missed** and is never started late.
* **It could not start.** A check failed: for example the destination store is no longer connected, or an option is no longer allowed. The row shows **Could not start**, the details show the reason under **Why**, and the person who scheduled it receives an email with the reason and what to do. Nothing is changed on either store.
* **It was missed.** If the migration could not be started within 15 minutes of its time, because no start signal reached StagingPro (for example during a maintenance window) or because the migration service did not answer the start request in time, it is marked **Missed** rather than started late, so a migration never surprises you hours after the window you chose. The person who scheduled it and the StagingPro helpdesk both receive an email, so the cause can be checked. Nothing is changed on either store.
**The start signal lines in the history.** When you save, StagingPro books a wake-up call for the exact minute you picked. The history records it as *Start signal registered with the scheduler*, and *Start signal received* when it arrives. StagingPro also checks for due schedules itself every 2 minutes, so if the wake-up call could not be booked (the history says *Start signal could not be registered*) the migration still starts, at most 2 minutes after your time. Whichever arrives first starts the migration; the other is recorded as *Duplicate start signal ignored*. A migration is never started twice. *Migration service did not answer, will retry* means the start was retried; the retries still count against the 15 minutes.
## The statuses a schedule moves through
| Status | Meaning | What you can do |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- |
| **Scheduled** | Waiting for its time. | Reschedule, cancel |
| **Waiting** | Its time has come, but a bulk or True Replica migration is still running on one of its stores. It starts when that finishes, up to 2 hours after its time. | Reschedule, cancel |
| **Starting** | The start is in progress. Momentary, and shown only in the details popup. | Nothing, it becomes a run within seconds |
| **Could not start** | A start-time check failed. The reason is in the details and in the email. Stays in the list for 30 days. | Fix the cause, then schedule again |
| **Missed** | It could not be started within 15 minutes of its time (no start signal reached StagingPro, or the migration service did not answer the start request in time), or the stores were still busy 2 hours after its time. Never started late. Stays in the list for 30 days. | Schedule again for a new time |
| **Cancelled** | Cancelled by a user before it started. The row leaves the list. | Schedule again if needed |
Once a schedule has started, the row carries the migration's own status (`queued`, `in_progress`, `completed` and so on), exactly as described in [Migration History](/vortex-apps/staging-pro/migration-history#migration-history-tab).
**Could not start** and **Missed** rows stay in the list for 30 days and then drop off; the email is your record after that. Pending schedules are listed soonest first.
## Two heavy migrations never share a store
Two bulk or True Replica migrations running on the same store at the same time compete for the same BigCommerce API allowance, and both slow down or fail. StagingPro treats **bulk** migrations (a running dry run or verify run counts too) and **True Replica** runs as heavy, and **selective** migrations as light. Two migrations share a store when the source or destination of one is the source or destination of the other.
| Moment | What StagingPro does |
| ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| You save or reschedule a heavy schedule within 12 hours of another pending heavy schedule on a shared store | Refused, naming the other schedule |
| You save a heavy schedule while a heavy migration is running on a shared store | Accepted, with a warning that it will wait |
| A heavy schedule's time arrives while a heavy migration is running on a shared store | It waits, for up to 2 hours, then is marked Missed |
| You click **Start** on a heavy migration while a heavy migration is running on a shared store | Refused: the message says the stores are busy and names the running migration |
| You click **Start** on a heavy migration while a heavy schedule on a shared store is due within the next 2 hours | Refused: the message names the schedule, so the scheduled run keeps its window |
The same refusals apply to migrations started through the [Migration API](/vortex-apps/staging-pro/api/create-migration). Selective runs are exempt in every row of this table.
## The emails
The person who scheduled the migration receives an email at each outcome. Each email says what happened, why, and what to do next. Its **Open Store Migration** button opens StagingPro V2 on the Migration History tab.
| Subject | When | Who |
| ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------- |
| `[StagingPro] Your scheduled migration has started (
4. In the **Schedule migration** dialog, pick the **Date**, the **Time**, and the **Timezone**. The dialog opens pre-filled with the earliest allowed time (5 minutes from now) in your browser's timezone; change it to the time you want, and pick another timezone only when you are scheduling on someone else's behalf.
5. Check the **Starts** line. It shows the exact start in the timezone you picked and in UTC, with a countdown, so you can confirm you have the right moment before you save.
6. Click **Schedule migration**.
The schedule details open straight away (see [after you save](#after-you-save) below), and the schedule appears at the top of the **Migration History** list, with any other pending schedules, soonest first.
A True Replica run is scheduled the same way, from its own confirmation dialog.
## Schedule a selective migration
1. On **Selective Content Migration**, pick the source and destination, open one of the six tabs and tick the items you want. A schedule holds the picks from one tab; switching tabs clears them.
2. Click **Schedule for later** (between **Dry Run** and **Start Selective Migration**; it is greyed out until you have ticked at least one item).
3. For product picks, the **Selective Product migration options** popup opens first, exactly as it does for an immediate start. Choose which sub-components ride along, then click **Continue to schedule**.
4. Pick the date, time and timezone, and click **Schedule migration**.
Your picks, product options, storefront mapping and stores are saved with the schedule. Only the time and timezone can be changed later.
## The rules the dialog applies
| Rule | Detail |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Earliest start** | At least 5 minutes from now. |
| **Latest start** | At most one month ahead (the same calendar day next month, in the timezone you picked). |
| **Timezone** | Any timezone in the list (standard city names such as Europe/London or Asia/Kolkata). The time is stored together with the zone you picked, and every screen shows it in that zone. |
| **Clock changes** | A time that does not exist on that date (the hour skipped when clocks go forward) and a time that happens twice (the hour repeated when clocks go back) are both refused. Pick a time outside that hour. |
| **Two heavy migrations on one store** | StagingPro calls bulk and True Replica migrations *heavy* and selective migrations *light*. A heavy schedule is refused when another pending heavy schedule uses either of the same stores (as source or destination) 12 hours or less from it. The message names the other schedule, its time and who requested it. |
| **A heavy migration already running** | You can still save the schedule. It is accepted with a warning that it will wait for the running migration to finish (see [what happens at the scheduled time](#what-happens-at-the-scheduled-time)). |
Selective migrations are light and are exempt from the two collision rules, both ways: they never wait, and they never make another migration wait.
The popup shows:
* **Schedule number** in the header (*Schedule #13*). Quote it to the helpdesk: a schedule has no migration id until it starts, and the run it becomes carries the same number in its id (`SR-13-` followed by a code).
* **Status**: **Scheduled**, **Waiting**, **Starting**, **Could not start**, **Missed** or **Cancelled** (see the [status table](#the-statuses-a-schedule-moves-through)).
* **Starts**: the moment it starts, in its timezone, with a countdown.
* **Requested by** and **Requested on**.
* **History of this schedule**: every step so far, from *Scheduled by …* and *Start signal registered with the scheduler* through to the start, a reschedule, a cancellation, or the reason it could not run. Emails sent about the schedule are listed here too.
* **Cancel schedule** and **Reschedule**, while the schedule is still pending.
In the **Migration History** list a pending schedule shows **Scheduled** with a countdown in the **Migration ID** column, the migration's source, destination, mode and entity count, and its start time in the **Created** column. A **Could not start** or **Missed** row shows who requested it in place of the countdown:
Anyone in your organisation with access to StagingPro can see, reschedule or cancel a pending schedule. The history of the schedule shows who scheduled and rescheduled it; a cancellation removes the row, so its record is only available through the helpdesk.
## Reschedule or cancel
**Reschedule** changes the time or the timezone and nothing else. Open **Details →**, click **Reschedule**, pick the new time and click **Save new time**. The same rules apply as when you first scheduled it, and the change is recorded in the schedule's history with the old and the new time.
To change *what* migrates (stores, strategy, entities or picks), cancel the schedule and create a new one.
**Cancel schedule** asks you to confirm, then removes the schedule from the list. Nothing runs and no email is sent. A cancelled schedule cannot be brought back; create a new one instead. If a schedule you made has disappeared from Migration History before its time, a colleague cancelled it; the cancellation and who made it are kept on our side, so ask the helpdesk if you need to know who.
Both are available while the schedule is **Scheduled** or **Waiting**. Once it has started it is an ordinary migration, with the usual **Pause**, **Resume** and **Cancel** controls on its run detail.
## What happens at the scheduled time
At the scheduled moment StagingPro re-runs every check the **Start** button runs, against the stores as they are right then: the stores are still connected, the options are still valid, and the [safety rails](/vortex-apps/staging-pro/whats-new-v2#13-built-in-safety-rails) still pass.
Then one of four things happens:
* **It starts.** The schedule becomes a migration. Its Migration History row turns into the run itself, with a run id that starts with `SR-`, and it opens like any other run, with live progress and the run detail. The person who scheduled it receives a **started** email.
* **It waits, because the stores are busy.** If a bulk or True Replica migration is still running on either store, a bulk or True Replica schedule **waits** rather than starting on top of it. The row shows **Waiting**, the details name the migration it is waiting for, and it starts as soon as that migration finishes, for up to 2 hours after its scheduled time. A paused migration counts as still running, so resume or cancel it if you want the schedule to start. If the stores are still busy 2 hours after the slot, the schedule is marked **Missed** and is never started late.
* **It could not start.** A check failed: for example the destination store is no longer connected, or an option is no longer allowed. The row shows **Could not start**, the details show the reason under **Why**, and the person who scheduled it receives an email with the reason and what to do. Nothing is changed on either store.
* **It was missed.** If the migration could not be started within 15 minutes of its time, because no start signal reached StagingPro (for example during a maintenance window) or because the migration service did not answer the start request in time, it is marked **Missed** rather than started late, so a migration never surprises you hours after the window you chose. The person who scheduled it and the StagingPro helpdesk both receive an email, so the cause can be checked. Nothing is changed on either store.
