Import and Migrate Schedule Definitions

Import PBRS schedule definitions into another installation, check their dependencies, and verify the migrated schedules before enabling delivery.

Schedule import transfers configuration. It does not automatically migrate reporting accounts, external report assets, credentials, templates, or filesystem permissions.

Before you begin

You need:

• Access to the source PBRS installation and schedule definitions.
• A configured destination PBRS installation.
• A running destination API service.
• A valid access token and permission to import schedules.
• Compatible exported schedule data.
• The reporting accounts, destinations, and other dependencies required on the destination.
• A controlled location for verifying imported schedules and test output.

Record the source and destination PBRS builds. Test compatibility with a representative schedule before migrating the remaining schedules.

Use HTTPS when transmitting schedule definitions and credentials.

1. Choose the transfer method

There are two workflows:

The PBRS interface workflow exports schedules one at a time. Follow Export Schedule Definitions for the wizard procedure.

If the wizard has already transferred a schedule to the destination, inspect that imported schedule. Do not submit it again through the API unless you intentionally want another import.

The API workflow in this guide requires a JSON definition compatible with the import schema. Do not assume another export file format can be posted directly as JSON.

2. Prepare a migration record

Create a record for each schedule you intend to migrate.

Keep an unchanged copy of the source definition and a separate working copy for destination-specific adjustments.

Schedule definitions can contain sensitive connection information, addresses, paths, and credentials. Restrict access to migration files and logs.

3. Understand the import contract

Send the definition to:

POST /api/Schedule/importScheduleJSON

Use these headers:

Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json
Accept: application/json

The request body is the exported schedule object itself.

Do not:

• Wrap the object in a property named model.
• Serialize the entire object into a JSON string.
• Submit a normal schedule create/update request.
• Submit a schedule read response as though it were a complete export.
• Combine multiple exported schedules into an array and assume the endpoint performs a batch import.

Exported attributes are a separate schema

Import definitions use collections and objects such as:

This table is an orientation to the schema, not a minimal request template. Preserve the collections required by the exported schedule.

Field names can differ from authoring models. For example, the import schema contains PackageAttr.PackageName; package authoring uses ScheduleName.

Do not rename exported fields to match a create/update example. Preserve their documented spelling, casing, types, and relationships.

The presence of a setting in an import definition does not establish a separate API for creating or updating that setting.

Schedule-family selection

The import operation selects a schedule family from the exported attributes. It does not use a single top-level ScheduleType discriminator.

Selection is evaluated in this order:

Start with a compatible export of the intended family. Do not populate unrelated family attributes to try to make an incomplete request valid.

Do not clear all exported identifiers indiscriminately. Some identify the schedule family or relationships between exported records.

4. Prepare destination dependencies

Review every dependency against the destination installation.

Do not assume an identifier from the source installation refers to the same resource on the destination.

Resolve references according to the relevant import schema and PBRS configuration. There is no universal account or folder mapping property that applies to every schedule family.

Importing a schedule does not grant access to its reports or destinations.

Control execution during migration

Arrange for imported schedules to remain inactive until verification is complete.

Review recurrence, enabled state, event activation, and any parent workflow that could execute the imported schedule. Do not assume import always disables every schedule family.

Use controlled destinations for initial testing. Keep production recipients and automatic triggers out of the test workflow.

Stopping a scheduler alone does not prevent every possible API submission or parent-triggered execution. Coordinate the applications and workflows that can start the migrated schedule.

5. Validate the working definition

Before submission:

1. Confirm that the file contains a JSON object.
2. Check it against the import request schema.
3. Confirm the intended schedule family.
4. Preserve required report, destination, task, and parameter collections.
5. Check relationships between exported records.
6. Review destination-specific account and resource references.
7. Confirm the intended inactive state and test destinations.
8. Record the exact working definition being submitted.

Valid JSON syntax does not prove that a definition is compatible with the destination PBRS build.

Do not replace populated collections with empty arrays merely to simplify the request. Empty, null, and omitted values are not interchangeable.

6. Submit the definition

The following PowerShell example reads a prepared JSON file and sends it directly as the request body.

Run it only after completing the preparation and duplicate checks.

$PbrsBaseUrl = (Read-Host "Destination PBRS HTTPS base address").TrimEnd("/")
$PbrsAccessToken = Read-Host "Access token"
$PbrsImportFile = Read-Host "Path to the prepared schedule JSON file"

$PbrsImportJson = Get-Content -LiteralPath $PbrsImportFile -Raw -Encoding UTF8

if ([string]::IsNullOrWhiteSpace($PbrsImportJson)) {
    throw "The import file is empty."
}

$PbrsImportDefinition = ConvertFrom-Json -InputObject $PbrsImportJson -ErrorAction Stop

if (-not $PbrsImportJson.TrimStart().StartsWith("{")) {
    throw "The import file must contain a JSON object."
}

$PbrsHeaders = @{
    Authorization = "Bearer $PbrsAccessToken"
    Accept = "application/json"
}

$PbrsImportResponse = Invoke-RestMethod `
    -Method Post `
    -Uri "$PbrsBaseUrl/api/Schedule/importScheduleJSON" `
    -Headers $PbrsHeaders `
    -ContentType "application/json; charset=utf-8" `
    -Body ([System.Text.Encoding]::UTF8.GetBytes($PbrsImportJson)) `
    -ErrorAction Stop

Enter the service origin as the base address, for example:

https://pbrs.example.com:9001

Do not append /api to the base address.

The command validates JSON syntax but does not perform full import-schema or dependency validation. It sends the original file contents without rebuilding the object through a JSON serializer.

Submit once. If the request times out or the connection is lost, reconcile the destination before running it again.

7. Interpret the response

A successful HTTP response contains an object with a returnModel string.

Its contents vary by schedule family:

• It can contain a success message.
• It can contain JSON-encoded diagnostic information.
• Automation diagnostics can contain imported attributes represented by Value and Type entries.

Do not assume that returnModel is already a nested object or always contains JSON.

To inspect the response from the preceding request:

$PbrsReturnModel = $PbrsImportResponse.returnModel
$PbrsImportDiagnostics = $null

if ($null -ne $PbrsReturnModel) {
    try {
        $PbrsImportDiagnostics = ConvertFrom-Json `
            -InputObject $PbrsReturnModel `
            -ErrorAction Stop
    }
    catch {
        $PbrsImportDiagnostics = $null
    }
}

$PbrsReturnModel

Failure to parse the inner string as JSON does not by itself mean the import failed. The string may be a message.

Store the response with the migration record, restricting access if it contains sensitive attributes.

Do not assume that the response supplies a universal top-level uniqueid, ExecutionId, or complete read-back definition. Determine the imported object's destination identifier and inspect the saved configuration.

Import destination IDs are assigned during import. Do not reuse source destination IDs as though they identify the imported destinations.

8. Locate and inspect imported objects

After submission:

1. Locate the imported schedule in the destination PBRS interface or through an applicable public read operation.
2. Record its destination identifier.
3. Verify its schedule family.
4. Confirm its name, folder, ownership, and inactive state.
5. Review its dependent reports, tasks, and destinations.
6. Compare the saved configuration with the migration record.

Do not assume the source ID is retained or that importing an existing ID updates the corresponding destination object.

Names alone are insufficient to identify an import when duplicate names are possible. Correlate the request time, schedule family, configuration, and available identifiers.

Verification checklist

Check scheduling against the destination server's time configuration. Do not infer the intended local execution time solely from a serialized timestamp.

A successful import response does not establish that every external dependency is usable.

9. Run a controlled execution

Before enabling normal delivery:

1. Confirm the imported schedule is using controlled destinations.
2. Run it from PBRS and inspect the result.
3. If an application will execute it through the API, test that execution path separately.
4. Verify every intended report and file.
5. Confirm the selected data, layout, package membership, and delivery.
6. Record any required corrections and repeat the affected checks.

For data-driven schedules, use a small set of known records. Verify filter values, recipient mappings, grouping, and missing or blank fields.

For automation or collaboration, inspect child execution and actual execution servers as well as the parent result.

Use Monitor, Recover, and Reconcile Executions when output is incomplete or the outcome is uncertain.

10. Cut over to the destination

Once verification is complete:

1. Confirm that the destination configuration is ready for production.
2. Coordinate the final execution on the source.
3. Disable or otherwise retire the source schedule's automatic execution.
4. Check for source executions still in progress.
5. Switch application references to destination schedule identifiers.
6. Restore the intended production destinations.
7. Enable the destination schedule and required triggers.
8. Verify the first normal execution and delivery.

Avoid leaving both source and destination schedules active unintentionally.

Confirm that event listeners, parent automations, and external applications no longer start the old schedule.

Retain the migration record and the original source definition for recovery.

Handle failures and duplicate imports

Import is not guaranteed to be transactional or idempotent.

A failed response does not guarantee that nothing was created. A repeated request can create additional objects.

After an error, timeout, or lost connection:

1. Inspect the destination for newly created schedules and related objects.
2. Compare them with the recorded request.
3. Determine whether the import completed, partially completed, or remains unresolved.
4. Correct the underlying dependency or configuration problem.
5. Decide whether to repair the imported objects or remove a verified incomplete copy before retrying.

Do not delete objects based only on a familiar name or a source identifier.

Use the PBRS interface or the applicable public operation for the imported schedule family. Confirm ownership and dependencies before removing anything.

Recover from an unsuccessful migration

If the destination cannot be used:

1. Keep its imported schedules and triggers inactive.
2. Check for active executions and completed deliveries.
3. Restore the source workflow only after accounting for destination activity.
4. Correct the destination configuration or perform a controlled re-import.
5. Repeat verification before another cutover.

Deleting an imported schedule does not recall delivered files. Recovery requires checking both configuration and execution outcomes.

Troubleshooting

Next steps

Use Create and Update Single Schedules or Create and Manage Report Packages for supported changes to imported schedules.

Use Operate the API and Scheduler to verify the destination environment.

Use Monitor, Recover, and Reconcile Executions to investigate uncertain execution or delivery outcomes.