Moves your Jooto projects, tasks, comments and attachments into Backlog. Runs on your own machine with a browser-based interface.
English | 日本語の説明はこちら
⚠️ This is an unofficial tool with no affiliation to PR TIMES, Inc. or Nulab Inc. Neither company supports or endorses it. Use at your own risk.
PR TIMES has announced the end of general availability and the discontinuation of the Jooto business (announcement, 6 August 2026, in Japanese).
Extract your data early, even if you migrate later. Close to the deadline, many organisations will be migrating at once.
Under Jooto's terms of service (art. 12(2)), cancelling may delete your data, with no stated grace period. Stopping payment can also lead to deletion after a period (art. 5(1)).
Cancel only after all of the following:
- You have reviewed the migrated content in Backlog
- You have manually uploaded the files that cannot be migrated automatically
- You have kept a copy of the local
workfolder somewhere safe
PR TIMES has said it will provide "guidance on data export and migration". If an official route exists, prefer it — it will be more reliable and supported.
| What you need | |
|---|---|
| Jooto | A Business plan subscription |
| Organization administrator rights (to issue an API key) | |
| Backlog | A destination space |
| Space administrator rights (to add statuses) | |
| Computer | Windows / macOS / Linux — no installation required |
❌ The Starter plan is not supported. It allows only 100 API requests per month for the whole organization, far below the few thousand a migration needs. Plan upgrades stopped on 6 August 2026, so switching to Business is no longer possible. Wait for Jooto's official export instead.
| Jooto | Backlog |
|---|---|
| Project | Project |
| Task | Issue |
| Comment | Issue comment |
| Images and files attached to tasks or comments | Issue attachments |
| Label | Category |
| List (kanban column) | Status |
| Checklist | Folded into the issue description |
| Item | Why, and what to do |
|---|---|
| Jooto "Files" | Backlog's shared files have no upload API. Files are saved locally; upload them by hand. A list and instructions are generated for you |
| Author and creation date | The Backlog API cannot accept them. Everything will appear as created by you, today. The original author and timestamp are recorded at the end of each issue |
| Second and subsequent assignees | Backlog allows one assignee. The rest are noted in the description |
| Task ordering, follow state, activity log | No equivalent in Backlog |
The author and date change is a hard limit of the Backlog API, not a defect. Tell your team before migrating so nobody is surprised afterwards.
Get the file for your machine from the Releases page.
| Machine | File |
|---|---|
| Mac (M1 or later) | jooto2backlog-darwin-arm64 |
| Mac (Intel) | jooto2backlog-darwin-amd64 |
| Windows | jooto2backlog-windows-amd64.exe |
Double-click the downloaded file. Your browser opens automatically with the interface.
⚠️ macOS: "not opened" / "developer cannot be verified"
macOS quarantines anything downloaded from the internet, and these binaries are not signed, so it refuses to run them.
Option 1: one line in Terminal (reliable)
cd ~/Downloads
xattr -d com.apple.quarantine jooto2backlog-darwin-arm64
chmod +x jooto2backlog-darwin-arm64After that, double-clicking works. On an Intel Mac, substitute
jooto2backlog-darwin-amd64.
Option 2: System Settings (no Terminal)
- Try to open the file, then dismiss the warning
- Open System Settings → Privacy & Security
- Scroll down; a note about the blocked file appears with a button to allow it
- Open the file again
The exact wording varies by macOS version. If you cannot find it, use option 1.
The warning appears because the binaries carry no Apple signature (which
requires a paid Apple identity). You can confirm the download is intact using
SHA256SUMS from the release page:
shasum -a 256 -c SHA256SUMS⚠️ Windows: "Windows protected your PC"
- Click More info
- Click Run anyway
🔐 Verify your download (optional)
The binaries are not yet code-signed, so each release also ships a SHA256SUMS
file. To confirm your download was not corrupted or tampered with:
# macOS / Linux — run in the folder holding the download and SHA256SUMS
shasum -a 256 -c SHA256SUMSOn Windows, compare the output of
certutil -hashfile jooto2backlog-windows-amd64.exe SHA256
with the matching line in SHA256SUMS.
Jooto: Organization settings → API keys → Add API key Backlog: Personal settings → API → Register a new key
🔒 Keys stay on your machine and are never transmitted anywhere. They are held in memory only, so you will re-enter them next time.
Pick which Jooto project goes to which Backlog project.
Jooto lists (the kanban columns) become Backlog statuses.
Backlog allows only eight custom statuses per project, on top of the four built-in ones. When a board has more lists than that, this screen is where you decide which ones become statuses.
| Choice | What it does |
|---|---|
| Create | Adds a custom status named after the list (eight maximum) |
| An existing status | Assigns the list to a status that already exists — this does not use up any of the eight |
| No status | Tasks land on the project's default status |
💡 If you go over the limit, fold similar lists onto existing statuses. Those cost nothing, so all eleven lists on a board can still be mapped. You can also merge several lists onto one status.
You cannot continue while over the limit: migrating anyway would silently drop the status of every task in the surplus lists.
Match each Jooto member to exactly one Backlog user. People with matching email addresses are paired automatically.
- Choose do not assign when there is no counterpart
- Assigning several people to the same Backlog user is allowed, with a warning
You will see how much will be migrated and what will not be. Review it, then start.
Try a small number of issues first.
Issues 412/1203 Comments 890/3051 Attachments 34/200
[████████░░░░░░░░░░░░] 34% elapsed 28:14 about 55:00 remaining
Current: MYPROJ-412 "Refactor authentication"
⏳ You may see "waiting 43 seconds for the rate limit". This is not a fault. The tool deliberately paces itself to avoid overloading Jooto and Backlog. Let it continue.
Interrupting is safe. Run it again and it resumes where it stopped. Closing the browser does not stop the migration.
The completion screen offers two things.
| Button | What it does |
|---|---|
| View the log in detail | Opens each item that did not go through, with the reason and the original Jooto record, so you can redo it by hand |
| Start over | Returns to the beginning. Nothing saved is deleted, and your API keys are kept |
Work continues in Jooto while the move is arranged, so a migration is rarely a single event. Running the tool again brings over only what is new or edited.
October Migrate 1,200 tasks
↓ people keep working in Jooto
December Run again → 23 new and 47 changed tasks only
the other 1,180 are left alone, not duplicated
The second run shows you what it is about to do:
Incremental migration (last run: 2026-10-15)
New 23 tasks added since the last run
Changed 47 edited in Jooto
Unchanged 1,180 nothing will be sent for these
⚠️ Conflicts 3 changed on both sides (see below)
⚠️ Vanished 2 no longer in Jooto
Estimated: about 2 minutes (a full re-run would take about 41)
If somebody edited a migrated issue in Backlog, that work is protected.
When both sides changed, it is reported as a conflict and, by default, nothing is written. You choose what happens:
| Option | Behaviour |
|---|---|
| Leave it (default) | The Backlog edit stands |
| Overwrite from Jooto | Jooto becomes authoritative |
| Add a note | The body is untouched; the Jooto change is added as a comment |
Tasks that no longer appear in Jooto are reported only, never deleted. A failed fetch is hard to tell from a real deletion, and deletion cannot be undone.
⚠️ Do not delete theworkfolder. It holds the record of which Jooto task became which Backlog issue. Lose it and the next run recreates everything, producing duplicates.
All settings live in a single .env file. Copy the template and fill it in:
cp .env.example .envJOOTO_API_KEY=your-jooto-key
BACKLOG_URL=example.backlog.com
BACKLOG_API_KEY=your-backlog-key
You can also enter the keys in the browser interface; .env just saves you
retyping them. It is git-ignored.
If your network requires a proxy, add it to .env. Both Jooto and Backlog
traffic goes through it.
PROXY_URL=http://proxy.example.co.jp:8080
PROXY_USER=alice
PROXY_PASSWORD='p@ss word#1'
NO_PROXY=internal.example.co.jp,.corp.local
A bare host:port works too — the scheme is filled in for you.
Try without any of this first. The standard HTTPS_PROXY, HTTP_PROXY and
NO_PROXY environment variables are picked up automatically, so an existing
corporate setup usually needs no configuration at all.
A proxy is entirely optional; omit these and the tool connects directly. Proxy passwords stay in memory and never appear in logs or on screen.
Shown on screen before you start. Roughly:
| Size | Extract | Load into Backlog |
|---|---|---|
| ~100 tasks | under a minute | ~10 minutes |
| ~1,000 tasks | ~6 minutes | ~90 minutes |
Loading is slow on purpose: issues are created one at a time so that a network hiccup cannot produce duplicates.
After a migration the tool writes readable reports into work/report/:
| File | What it contains |
|---|---|
migration-report.md |
Which Jooto task became which Backlog issue, a state summary, and everything that could not be migrated |
manual-upload.md |
The files to upload to Backlog by hand — only created when there are any, so its presence is itself the signal that action is needed |
Advanced users can run a read-only reconciliation from the command line. It
confirms every recorded issue really exists in Backlog, settles anything left in
an uncertain state, compares the Jooto and Backlog counts, and writes
work/report/verify-report.md:
./jooto2backlog verifyIt writes nothing to Jooto or Backlog. The command line offers the same migration as the browser for automation and scripting — see docs/06-cli-spec.md.
Everything is recorded, together with the complete original Jooto data.
- Raw record:
work/logs/failures.ndjson - Readable summary:
work/report/migration-report.md
Once Jooto is gone the source is unrecoverable, so enough detail is kept to recreate each item by hand.
| Mark | Meaning | What to do |
|---|---|---|
| 🔴 | Unknown whether it was created | Check Backlog; create it manually if absent |
| ❌ | Failed | Recreate manually from the recorded data |
| Partially migrated | Add the missing pieces (e.g. attachments) | |
| ⏭️ | Skipped | Review the recorded data |
The tool is free, but note:
Under Jooto's API terms art. 5(3), charges may apply if request volume or data transfer exceeds Jooto's expected baseline. For large organizations, check with Jooto beforehand.
The projected request count and data volume are shown before you start.
- Your data is never sent anywhere. The tool talks only to Jooto and Backlog
- No telemetry
- API keys are held in memory only and never written to disk
- Jooto is only ever read from, never modified
- The interface listens on
127.0.0.1only
Delete the work folder once you have verified the migration — it contains your
colleagues' names and email addresses.
- Logs are under
work/logs/ - Report problems via Issues
It retrieves your own data, using an API key you issued yourself, through Jooto's public API. It does not automate the Jooto user interface.
- Read-only against Jooto; nothing is ever modified
- Stays within the published rate limits (80% of the ceiling by default)
- Sends no keys or data anywhere
Should PR TIMES request that use of this tool cease, distribution and use will stop immediately, in line with Jooto's API terms art. 10(1).
See LICENSE.
Design documentation for developers is in docs/ (Japanese).