Why this exists
Mantis Bug Tracker served many teams well for fifteen years – including one of ours, with more than a decade of tickets, comments and attachments in it. When development moved to Azure DevOps, the history had to come along: a bug from 2013 still explains a design decision in 2026.
The migration tools we found either needed a running Mantis server, dropped comments and attachments, or created duplicates when re-run. So we wrote our own and published it under the MIT licence.
What it does
- Reads the Mantis SQL dump directly – no live Mantis instance, no PHP, no plugin. Enum ids (status, priority, severity) are resolved to labels from your own
config_inc.php. - Creates Azure DevOps work items through the REST API with description, steps to reproduce and additional information.
- Keeps the conversation: every bugnote becomes a comment with the original author and timestamp; attachments are uploaded and linked, duplicates detected.
- Preserves provenance: a "Mantis Migration Metadata" comment records the original reporter, dates, status and assignee; the
Mantis-<id>tag links back to the source. - Respects the ADO workflow: items are created as New and then transitioned to Resolved or Closed the way the process template allows.
- Idempotent: re-run it any time – already migrated items are recognised by tag and, with
--force-update, updated instead of duplicated. Filter by Mantis project or migrate a single bug for a dry run.
Get it
github.com/mos379/MantisToAzureDevOpsMigration – Python 3.8+, three scripts (export_mantis_to_json.py, export_mantis_attachments.py, import_to_ado.py), a config.json for the organisation, project and a PAT with Work Items (Read & Write).
Need help with a migration?
Mapping users, custom fields and workflows is where every tracker migration gets specific. We do this as a fixed-scope service: assessment of the dump, a test migration into a throw-away project, then the real run – see Azure DevOps and cloud architecture or simply get in touch.