The table below shows the different stages of the process. These stages are highlighted in the Status column.
The meaning and the estimated time in each stage is given in the table below:
|Pending||A newly submitted request is in the Pending stage. It will move from this Stage to the submitted, only when the admin clicks the Start or Start All button.|
|Verifying||A request moves into this stage when the user clicks on Verify or Start. In the Verifying stage, the request parameters are validated.|
|Invalid||A request with invalid parameters is moved to the Invalid stage after the Verifying stage.|
A verified request moves to the Submitted stage. Here the request enters a queue of requests that are to be scheduled. A request will remain in the submitted phase until it can be scheduled for the processing which in turn depends on the number of requests in the submitted, scheduled, or processing stage.
The number of requests that can be scheduled concurrently, is controlled by a threshold value. For example, if the threshold is 5, only 5 simultaneous requests can be running. Therefore, the time to move to the next stage will depend on the number of requests being currently executed. If the number of running requests has reached the threshold, then your request will be submitted once the running requests and the requests in the queue before yours have completed.
A request in the Scheduled stage is just waiting on the resources to start processing and will start in 1 - 15 minutes.
When a request moves to the processing state, an email notification is sent to the email id specified in the request definition.
A request in the Processing stage is processing the input data and converting it into destination data. The time the request will remain in this stage depends on the size of the request and the method of migration.
Typically, an IMAP request will migrate 3 GB / hr, migrating from a PST/EML or MBOX file from an S3 bucket will have a rate of 600 MB/ hr.
A request in the processing state may get suspended and be automatically Re-submitted for processing.
This happens when the resources allocated for the request are re-allocated to another higher priority request.
Once the request is re-submitted, it will have to wait for resources similar to a submitted request.
Once the resources are available, the request will move to the scheduled state and then the processing state.
In the processing state, the request will resume from where it was suspended.
This whole flow is automatic and no intervention required from you.
|Processed||A request which has completed successfully will be in the Processed stage. A mail with the details will be sent.|
|Failed||A request which terminated with failures. Details of the failure will be sent by email. Such a request can be resubmitted.|