Inventory
addly app versions, its configuration and data, automations that depend on it, owners, and documented dependencies.
Gate 1An app migration starts with what the team must be able to abandon.
A responsible migration path supplies a method, not a vague Cloud promise. This playbook structures inventory, rehearsal, rollback, and validation for a addly add-on only.
No active migration service
addly does not migrate Jira, Confluence, or the Atlassian ecosystem. The current concepts have no Server or Data Center install base and no customer data; this playbook defines the evidence expected if a real addly app later needs its own configuration or data migrated.
The playbook in five passes.
Each phase produces a verifiable artifact and an exit condition. A cutover can never compensate for an incomplete inventory.
Decide
Keep, replace, retire, or defer each app capability and record the reason.
Gate 2Prepare
Permissions, field mapping, backup, test environment, stop conditions, and rollback.
Gate 3Rehearse
Run a dry run, reconcile counts, exercise critical paths, and document every difference.
Gate 4Cut over
Freeze the scoped data, transfer, verify, communicate, and monitor the addly add-on.
Gate 5Rollback is a feature of the plan.
A addly add-on migration is not ready until the team knows when to stop, which app data or configuration to restore, and who makes that decision.
- 01Stop thresholds and the person authorized to decide.
- 02A verified backup before cutover.
- 03A coexistence window and one named source of truth.
- 04A restoration procedure tested in the target environment.
- 05User communication prepared for either success or rollback.
The first rehearsal should fail usefully.
Copy the playbook, adapt its gates to the addly app and your environment, then contact app support only after gathering logs, counts, and differences.