Verify Schedules After a Transfer
Inspect transferred configuration, test the output and coordinate destination activation.
Check schedules that have already been transferred to another ATRS installation using a supported transfer process. Verify their dependencies and output before enabling normal delivery.
This is a post-transfer verification procedure. Obtain the supported transfer instructions for your source and destination versions from Support before moving definitions. It does not submit an API import or construct an export format.
Before you begin
- Complete the migration inventory.
- Keep the original source configuration and any genuine export files unchanged.
- Record the transfer method, time and resulting destination identifiers.
- Keep destination recurrence and other automatic triggers inactive while testing.
- Use controlled recipients and output folders for initial tests.
1. Locate the destination schedules
Use folder discovery and the ATRS application to identify each resulting schedule. Correlate its family, configuration and transfer time with the inventory.
Do not assume the original IDs were preserved or identify objects by name alone. Record destination schedule and destination-entry IDs separately.
2. Compare saved configuration
Retrieve each single schedule with SingleSchedule/Get, or inspect an existing package using Create and Manage Report Packages.
| Check | Confirm |
|---|---|
| Tableau selection | Correct configured account, report/item and access. |
| Report settings | Parameters, rendering and expected output format. |
| Packages | Every member, order, merge settings and destination. |
| Processing dependencies | Data sources, drivers, calendars, tasks and supporting files. |
| Delivery | Correct recipients, server-side paths and permissions. |
| Recurrence | Intended local time, next run and inactive test state. |
Compare read responses with the ATRS application and retained intended configuration. Omitted fields do not mean settings should be cleared.
3. Test execution and delivery
Run the Quick Start on the destination using its own credentials and the destination schedule ID.
Save the execution ID, inspect the result and open the output. Check every package member and each data-driven recipient scope where applicable. Record results in the inventory.
If the result is incomplete, retain evidence and use monitoring and recovery before another run.
4. Coordinate cutover
- Confirm the destination’s output and dependencies pass the planned checks.
- Disable the source’s recurring delivery and coordinate parent/event/application triggers.
- Enable destination recurrence deliberately using the lifecycle procedure.
- Confirm next-run time and the first normal delivery.
- Retain the original source configuration and migration record for recovery.
Avoid leaving both installations delivering unintentionally. If the destination cannot be used, keep it inactive and restore source delivery according to the agreed cutover plan after checking partial output.
If a transfer is interrupted
Inspect destination objects and delivery evidence before repeating the transfer. Do not assume an error means nothing was created, or that repeating an import updates an existing schedule. Confirm the supported recovery process for the transfer method in use.
About the API import reference
The importScheduleJSON reference is not sufficient to establish a compatible export producer or a runnable transfer workflow for an installation. Confirm implementation and payload compatibility with Support before integrating it. A schedule GET response or normal create request is not an exported definition.
Updated about 8 hours ago