TempoMaster
In many organisations Tempo is the system billing depends on — and the one the native migration path covers least. The TempoMaster moves the complete Tempo world, with a way back as a safety net.
- The complete Tempo world: accounts, teams, plans, worklogs
- Cloud state secured before the first write
- Way back: an import run can be rolled back
- Dry run before every write
- Checked against Data Center after every stage
- Nothing is written until you approve it
- A traceable final report for every run
With billing-relevant data nothing may be lost. The TempoMaster moves accounts, account links, categories, permissions, plans, teams including working-time and holiday schemes, work attributes and the worklogs themselves — in a seven-stage pipeline. Writing steps run through the central gateway, with a dry run as the default and a clear switch between sandbox and production.
The difference lies in stage 1 and 7: before the first write the cloud state is secured, after the last it can be restored. A Tempo migration is thus not a one-way street — with billing-relevant data the precondition for being allowed to start at all.
What a standard migration leaves open
After a standard migration
- Tempo is left behind in the move
- A Tempo migration is a one-way street
- Account field and automation quietly go wrong
- Unclear whether worklogs arrived in full
With this tool TempoMaster
- The complete Tempo world in the cloud
- Cloud state secured, a way back in place
- Jira wiring carried over and repaired
- A count comparison across all three states
Seven stages with a way back
Secured before the first write, restorable after the last.
-
1
Pre-check & backup
Check reachability and configuration, measure user and issue coverage, load the mapping tables and secure the current state of the cloud before anything is touched.
Verified: Cloud state secured before anything is written.
-
2
Read out
Eight read-only steps fetch the complete Tempo structure from the Data Center: accounts, links, categories, permissions, plans, teams, work attributes and the worklogs.
Verified: Read-only, complete.
-
3
Remap
Project references are remapped from DC keys to cloud IDs and the entire data state is validated before writing.
Verified: What stands out stands out before it is in the cloud.
-
4
Import
The same eight object types are created in the cloud — each as its own, individually triggerable step with a dry run in front.
Verified: A dry run per step, not all or nothing.
-
5
Jira wiring
The Tempo account field is carried over and the automation rules that react to account edits are repaired.
Verified: The quiet break points of a Tempo migration closed.
-
6
Proof
A count comparison across all three states, a content check DC against cloud, a check that work attributes sit on the right fields, and a targeted search for duplicate worklogs.
Verified: Proven, not claimed.
-
7
Way back
A dedicated safety step rolls back an import run deliberately or non-destructively resets to the previously secured cloud state.
Verified: Not a one-way street.
What it does
The complete Tempo world
Accounts, account links, categories, account permissions, plans, teams including working-time and holiday schemes, work attributes and the worklogs themselves.
A secured way back
Before the first write the cloud state is secured; an import run can be rolled back deliberately. Not a one-way street.
Sandbox or production
Writing steps run through the central gateway, with a dry run as the default and a clear switch between sandbox and production.
Individually triggerable steps
The eight object types are imported individually, each with a dry run in front — not as one big run you can only do all or nothing.
Jira wiring repaired
The Tempo account field is carried over and the automation rules that react to account edits are repaired — the spots where a Tempo migration otherwise quietly goes wrong.
Proof across all states
A count comparison across Data Center, imported and cloud, a content check and a targeted search for duplicate worklogs prove the result.
Common questions before migrating
What if something goes wrong during import?
Before the first write the cloud state is secured, and a dedicated step rolls back an import run deliberately or non-destructively resets to the secured state. With billing-relevant data this way back is the precondition for starting at all.
Can we test against a sandbox first?
Yes. Writing steps run with a dry run as the default, and you switch explicitly between sandbox and production. As a rule you migrate and verify against the sandbox first.
Does the automation around Tempo come along too?
Yes. The Tempo account field is carried over and the automation rules that react to account edits are repaired — exactly the spots where a Tempo migration otherwise quietly goes wrong.
How is it ensured that the worklogs are complete?
A count comparison across Data Center, imported and cloud, a content check and a targeted search for duplicate worklogs prove the result.
In control — from start to final report
Reading separated from writing
Reads come from a read-only data layer; writes go through a single controlled channel. Read access never burdens your Cloud.
A test run before every write
The dry run shows exactly what would happen. Nothing is written until you explicitly approve it.
Repeatable without risk
Every step can be run again without doing harm. An interruption is no problem, and a second run creates no duplicates.
One isolated stack per customer
All tools run on the Jira Migration Manager platform, fully separated per engagement. No mixing of data.
The final report names every item individually: repaired, to review, skipped or failed. Nothing is silently processed wrong.
Runs on the Jira Migration Manager
This tool does not stand alone. It runs on the platform that unites every tool: a read-only read layer pulls Data Center and Cloud into a versioned snapshot, and every change goes through a single, controlled write gateway.
More on the Jira Migration ManagerMore tools
Migration platform
Jira Migration Manager
The platform that brings every migration tool under one roof and makes a Jira DC-to-Cloud migration safe and repeatable: separate read and write paths, rate-limited into the Cloud, credentials encrypted, one isolated stack per customer.
- Read-only read layer and rate-limited write channel kept strictly separate
- All tools on one shared data base, chainable into pipelines
- Token-secured perimeter, encrypted keystore, one stack per customer
Assets Migration
Asset Relink
Migrates Insight/Assets to the Cloud in full: fields and contexts, AQL filters, screens and the object values on every issue. Exactly where standard tools lose the links.
- Create fields, contexts and screens in the Cloud
- Translate AQL filters from Data Center to Cloud
- Relink object values on every issue
Managed Migration
Jira Migration Helper
JCMA migrates the bulk of your data but leaves configuration broken or unmigrated. Jira Migration Helper closes these gaps module by module and, with Managed Migration, runs the right fixes for each finished project automatically — every one dry-run by default and verified against the live Cloud API.
- Repair filters, dashboards, fields, roles and permissions that JCMA leaves open
- Managed Migration: automatically run the right fixes per project as it finishes
- Web UI or CLI, every module dry-run by default and secured by the idempotent write gateway
A fit for your migration?
Describe your case in a few lines — I'll tell you honestly whether and how this tool helps.
Book a callAtlassian ends support for Data Center on 28 March 2029. If you are moving a large, deeply connected environment, plan early rather than late.