Skip to content
  • There are no suggestions because the search field is empty.

Migrate Schedules Through the PBRS REST API

Migrate schedules between PBRS environments with inventory, transformation, staged verification and rollback.

Review status: Draft for Development and Support review. Routes and models labelled validation required must be tested against the supported PBRS build before publication.

Plan the migration

Define source and target builds, supported schedule families, authentication, maintenance window, acceptance criteria, rollback owner and the validated operations required for create, update, parameter update and delete.

Migration workflow

  1. Inventory: export an independent manifest of schedules and dependencies.
  2. Map: translate account, workspace, report, folder, credential and destination identifiers.
  3. Transform: apply environment-specific values and remove source secrets.
  4. Stage: create a small representative batch.
  5. Read back: compare persisted target models with the manifest.
  6. Execute: test rendering, artifacts and controlled destinations.
  7. Cut over: migrate in waves and monitor queue capacity.
  8. Reconcile: compare counts, identities, parameters, destinations and outcomes.
  9. Rollback: keep source definitions active or recoverable until acceptance.
  10. Retire: perform deletion only with a validated contract and explicit approval.

Idempotency

Until PBRS documents a native idempotency key, use client-owned deterministic naming or keywords, read-before-create, post-timeout reconciliation and duplicate cleanup. Never retry a write blindly.

The PBRS GUI export wizard remains a separate administrator procedure and is not a substitute for an API migration contract.

Validated capability gate

Migration action Current evidence Publication rule
Inventory/read Power BI and paginated schedules Published read operations Verify models and filters by build
Create Power BI/paginated schedules Published operations Require complete recurrence/destination examples
Update Power BI schedule Published operation Read back all preserved fields
Update paginated parameters Support-evidenced operation Build/auth/schema validation required
Delete single/paginated schedule Controller/permission failure observed Do not use until Development supplies contract
Bulk migration Claims and support fixes exist Require batch, partial-failure and rerun contract

Reconciliation report

For every migrated item, record source and target identities, model hash or normalized field comparison, mapped dependencies, enabled state, next run, controlled execution result, artifact checks and destination results. Keep unresolved differences visible; do not mark the migration complete based only on HTTP status.

Documentation standard: Record the PBRS build used for verification, test in a non-production environment, redact credentials and customer data, and confirm the saved PBRS state after every write.