Redmine or MantisBT: which fits your team's tracker work
Choose Redmine when the tracker has to serve several projects at once and the work needs planning as well as issue handling. Redmine bundles multiple projects with role-based access, Gantt charts, per-project wikis and forums, time tracking, and Git, Subversion, Mercurial, Bazaar and CVS integration in one application under GPL v2, with no paid edition. Choose MantisBT when the main job is bug and defect handling with a strict workflow, email notifications on issue updates, resolutions and comments, and customizable issue fields and workflows. MantisBT is also released under the GNU General Public License. Each fit holds only if your team actually uses the planning features or the bug-centric workflow; if most users just log defects, the extra modules in Redmine add little, and if you need Gantt views or time tracking across portfolios, MantisBT will push you toward add-ons or other tools.
Four decision drivers should settle the choice. First, project scope: count how many projects share one tracker and whether they need cross-project roles, since Redmine's model is built around that. Second, identity needs: both support LDAP, and MantisBT can create accounts on first login for users found in the directory, but confirm which single sign-on methods and group mappings your identity provider requires, because these are not covered by the features listed for either product. Third, database standard: Redmine supports PostgreSQL, MySQL 8.0 to 8.4 with READ COMMITTED isolation, SQL Server 2012 or higher, and SQLite, which the installation guide does not recommend for multi-user production use. MantisBT supports MySQL or MariaDB and PostgreSQL, recommends MySQL, and lists SQL Server and Oracle as experimental. Match these against the database your operations team already runs.
The fourth driver is the migration path, and it is the one most likely to surprise you. Redmine's built-in importers for Trac and Mantis are marked obsolete and not working, and third-party scripts for other systems are described as neither tested nor supported. If your current tracker is MantisBT, plan the data move as a project of its own: export issues, attachments, users and custom fields, test the mapping on a copy, and validate counts and history before cutover. Ask any implementation partner to state in writing who owns that script, how it is tested, and what happens to closed issues and attachments. Review the Redmine migration guide before you commit to a target.
How licensing and editions differ between Redmine and MantisBT
Redmine is released under the GNU General Public License v2, and the project describes its license as GPL-2.0-or-later. The software has no paid edition, so the license carries no subscription, seat or feature fee. The money you spend goes to everything around the code: hosting, setup, plugins, upgrades and the people who keep the installation running.
- No paid edition: the feature set on the download page is the feature set in every deployment, so there is no tier to upgrade into.
- Volunteer maintenance: Redmine is maintained by community volunteers, so response times and roadmap priorities are not set by a contract with a vendor.
- Support windows: Redmine 7.0.x receives new features, bug fixes and security updates, 6.1.x receives only bug fixes and security updates, and 6.0.x receives only important security updates. The line you choose sets how often you must upgrade.
- Third-party plugins: plugins have their own authors and licenses, so each one must be checked against the Redmine version you run.
Confirm the license file in the exact release you plan to deploy, and check which support line it belongs to before you commit to a version.
Because the license is free, Redmine's cost comes from recurring and one-time work that someone must be paid for, whether that is your staff, an implementation partner or a hosting provider. Costs go up with the number of plugins, the size of the user base, the number of integrations with identity systems and the frequency of upgrades. Costs fall when the configuration is standardized and the upgrade routine is documented and rehearsed.
- Hosting: compute, storage and a supported database in your own cloud accounts or data center, paid on a recurring basis.
- Implementation: one-time configuration, LDAP authentication and migration work, ideally agreed in a written, fixed scope.
- Plugins: a one-time selection effort, followed by recurring compatibility checks at each upgrade.
- Upgrades: the documented procedure backs up the database and uploaded files, copies configuration, uploads and plugins, runs the migration tasks, clears the cache and restarts.
- Staff time: recurring administration, monitoring and backup verification.
Ask any implementation partner to price these five lines separately and to state which Redmine support line the quote assumes.
MantisBT is open source and released under the terms of the GNU General Public License. The supplied material does not state the exact GPL version, so confirm it in the LICENSE file of the release you intend to deploy. The current stable line in the supplied material is 2.28, with 2.28.4 listed as the latest stable version on the project home page.
- GPL terms: the project names the GNU General Public License in its materials, but the version must be verified in the release files.
- The 2.28 line: the repository tags show 2.28.0 through 2.28.4, following 2.27.3, which gives you a clear starting point for planning.
- Upgrade path: if you run an earlier 2.x installation, plan the move to the 2.28 line and test your custom fields, workflows and notification settings first.
- Plugin compatibility: confirm that any plugin or patch you need is maintained for the 2.28 line before you rely on it.
Check the release tags and the home page on the day you plan the deployment, because the latest stable number changes over time.
This comparison does not list any paid MantisBT edition. The facts used here cover the open-source distribution and its released versions. If your team has been offered a paid support, hosting or add-on arrangement, treat it as a separate purchase that needs its own review, and confirm the terms with the vendor before comparing it with Redmine's no-fee license.
- No edition listed: no commercial tier is named on this page, so do not assume one exists or is included.
- Support sources: determine whether support comes from the project community, a vendor or a third party, and what each one commits to in writing.
- Hosted services: if a hosted offering exists, confirm what it covers, where data is stored and who operates the platform.
- Add-ons: ask which features are commercial and which are part of the open-source release you would deploy.
Ask the vendor for a written statement of editions, license terms and support windows, and file it with your procurement record before you make a decision.
GPL-2.0-or-later and the wider GPL family differ in license version and in the details of distribution obligations. Legal teams should review how each license applies to their plans, including internal use, modifications, redistribution to customers or affiliates, and bundling with proprietary tools. This page does not provide legal advice, and the points below are questions for counsel.
- Version differences: GPL-2.0 and GPL-3.0 are separate license versions with different terms, so any mix of projects under both needs a documented review.
- Internal use: running software inside your organization carries different obligations than distributing it to outside parties.
- Modifications and plugins: determine whether custom code or plugins will be distributed, and under which terms.
- Hosted services: confirm the obligations that apply when the platform is offered as a service to others.
Give legal the exact release, the LICENSE file for that release and your distribution plan before any deployment decision is final.
Which tracker fits which team scenario
This table maps common team situations to the tracker that usually fits better and the condition that tips the balance. Read each row as a starting point for your own requirements, then confirm the details against the current release notes and your own environment before deciding.
| Scenario | Better starting fit | Condition that makes it so |
|---|---|---|
| Multi-project software portfolio needing Gantt charts and per-project wikis | Redmine | Choose it when planners need cross-project issues, Gantt views and a wiki per project in one tool, and the team can keep up with Rails-based upgrades and plugin compatibility. |
| QA or defect-led team needing a bug-focused workflow and email notifications | MantisBT | Choose it when the main work is triaging defects through a configurable lifecycle with email notifications on updates, resolutions and comments. Confirm that its issue workflow matches your triage steps before committing. |
| Organization authenticating users against an LDAP or Active Directory directory | Either, after testing | Both support LDAP-based sign-in. Redmine lists multiple LDAP authentication support, and MantisBT can create accounts on first login for directory users. Test group mapping and account creation with your directory schema. |
| Team already standardized on MySQL or PostgreSQL operations | Depends on the database you run | MantisBT recommends MySQL and also supports PostgreSQL, with Microsoft SQL Server and Oracle listed as experimental. Redmine supports PostgreSQL, MySQL 8.0 to 8.4 and SQL Server. Check the exact database versions each release requires. |
| Team migrating existing Mantis data into Redmine | Plan a custom migration | The built-in Mantis importer is marked obsolete and not working, so budget for a scripted or consultant-led migration and test it on a copy of the data first. |
| Team that needs email to create issues | Confirm before choosing MantisBT | MantisBT's Admin Guide says reporting issues by email requires third-party patches. Redmine lists email-based issue creation as a built-in feature, so verify it in your own setup. |
| Team that relies heavily on API-driven automation | Either, after testing | Redmine's REST API is enabled by an administrator and covers core resources such as issues and time entries. MantisBT offers SOAP and REST APIs with per-user tokens. Confirm the endpoints your automation needs. |
How each tracker is built and what that means for operations
Redmine and MantisBT both run on web stacks you host yourself, so the database, web server and language runtime decide most of the operating work. The cards below cover what each stack supports, where the support limits sit, and what runtime upgrades mean for the people who run them.
Redmine runs on Rails
Redmine is a Ruby on Rails application, so your team inherits a Ruby runtime and Rails release line alongside the tracker itself. Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0, and it does not support JRuby. Check that your Ruby version sits inside the supported range before you plan an upgrade, because the runtime is the usual reason a Redmine upgrade stalls.
Redmine database choices
Redmine supports PostgreSQL, MySQL 8.0 to 8.4, SQL Server 2012 or higher and SQLite. MySQL must run with transaction isolation set to READ COMMITTED, which is a server setting your DBA has to confirm. SQLite is not suited to multi-user production use, so treat it as a trial environment only.
MantisBT runs on PHP
MantisBT is a PHP application that needs PHP 8.1 at minimum, and the Admin Guide recommends PHP 8.4 or later. Because the language runtime is the first thing you upgrade, confirm that your hosting image, operating system packages and any patches you apply still work on the newer PHP version before you commit to a version.
MantisBT database choices
MantisBT supports MySQL or MariaDB and PostgreSQL in production. Microsoft SQL Server and Oracle are listed as experimental, and the Admin Guide recommends MySQL. If your organization standardizes on PostgreSQL, confirm the minimum version of 9.2 against your own support policy and test your backup and restore path on it.
Web server options differ
Redmine is typically deployed behind a Rails-capable server, while MantisBT lists Apache 2.4.13 or later, nginx 1.10 or later, lighttpd 1.4 and IIS 7.5 or later. Confirm which web server your security team already hardens and monitors, because a unsupported combination adds integration work on both sides.
Runtime upgrades drive the schedule
Both trackers need their language runtime, database and plugins to match each new release, and a runtime upgrade can force a platform upgrade in the same window. Redmine's upgrade procedure includes running database migrations and plugin migrations before restarting. Plan a staging rebuild for each runtime change and agree on who signs off on the result.
Capabilities compared side by side
This table sets Redmine and MantisBT against the capabilities most teams ask about first, from multi-project structure to API authentication. Where the supplied research does not confirm a detail, the cell says what to verify in a test instance before you rely on it. Read the rows as a checklist for a proof of concept, not as a complete feature audit.
| Capability | Redmine | MantisBT |
|---|---|---|
| Multi-project support | Built around multiple projects with their own issues, wikis and members | Organized around projects with per-project roles; confirm how sub-project hierarchies behave for your structure |
| Role-based access control | Flexible role-based access control across projects | Per-project role-based access control |
| Issue workflow and custom fields | Custom fields and issue tracking; confirm workflow transitions for your process | Customizable issue fields, notifications and workflows |
| Gantt charts and calendars | Included, with Gantt charts and calendars | Not covered in the supplied facts; confirm before relying on it |
| Wikis and forums | Per-project wikis and forums included | Not covered in the supplied facts; confirm before relying on it |
| Time tracking | Included as a core feature | Not covered in the supplied facts; confirm before relying on it |
| Email notifications | Issue notifications by email; confirm the events you need | Email notifications for issue updates, resolutions and comments |
| Email-based issue creation | Supported, with email-based issue creation listed as a feature | Not supported out of the box; requires third-party patches |
| LDAP and Active Directory authentication | Multiple LDAP authentication sources supported | Own database or LDAP and Active Directory, with account creation on first login for directory users |
| SCM integration | Subversion, Git, Mercurial, Bazaar and CVS | Not covered in the supplied facts; confirm before relying on it |
| REST and SOAP APIs | REST API must be enabled by an administrator; JSON and XML formats | SOAP and REST APIs available |
| API token authentication | Per-user API key sent as a parameter or X-Redmine-API-Key header | Per-user API tokens for the REST API |
Moving from one tracker to the other without losing history
This sequence sets out what must survive a move between Redmine and MantisBT, how the data is exported and mapped, and how the result is proven on a copy before anyone cuts over. Redmine's built-in Mantis importer is marked obsolete and not working, so the migration is a planned custom or vendor-assisted project rather than a button press.
Inventory projects, users and fields
The migration lead lists every project, subproject, user account, group, custom field, workflow, and attachment store in the source tracker, and records which ones are active. Compare the list against the target's model, since Redmine organizes work around multiple projects with role-based access while MantisBT uses its own project and access structure. The step is done when the inventory is signed off by the project owners and the gaps between the two data models are written down.
Decide which history must survive
Business owners, auditors and the security team agree which records must move with full fidelity: issue descriptions, journals, comments, attachments, time entries, and closed issues that drive reporting or audit trails. They also decide what can be archived read-only instead of migrated. The output is a written retention decision per data type, approved before any scripting begins, so the scope of the export is not decided by whatever the tool happens to support.
Script or contract the export
Choose between an in-house script and a vendor-assisted export, because the built-in Redmine importer for Mantis cannot be relied on and third-party migration scripts are described as neither tested nor supported. Confirm the export covers issue history, attachments and user identities against the source database, and ask for the export method in writing with the scope and acceptance criteria. The step closes when a sample export of one project has been produced and reviewed by the project owner.
Map roles, statuses and workflows
Build a mapping table that pairs each source role with a target role, each source status with a target status, and each custom field with a target field of matching type. Flag mappings that lose meaning, such as a status with no equivalent or a permission that does not exist in the target. The mapping is signed off by the process owner, and any unmapped value is either resolved or explicitly accepted as a loss.
Migrate users and access without duplicates
Bring user accounts across through the directory where possible, since both platforms support LDAP authentication, so identities are not recreated by hand. Confirm how each platform treats accounts that already exist, and check that group memberships and project roles are assigned to the right people. The check is a reconciliation report listing every source user, the matched target account, and any user left unresolved.
Test the full run on a copy
Run the complete export and import against a copy of the production database and a copy of the attachment store, never against live data. The team checks issue counts, journal entries, attachment checksums, time entries, and sample issues picked at random from each project. Record every defect and rerun until the copy matches the approved mapping. The step is done when a repeatable run produces the same result twice.
Validate with users and sign the cutover
Project owners and a small group of daily users work through their own open issues on the migrated copy, then confirm that history, assignments and notifications behave as expected. Agree a freeze window and a rollback plan in writing, including how the source stays readable after cutover. The output is a signed acceptance record that names the owners, the validated checks and the rollback owner, which becomes the reference for the production move.
Where tracker migrations and rollouts usually run long
Moving between Redmine and MantisBT, or upgrading either one, tends to stall on the same handful of details rather than on the core install. The cards below cover the mapping, identity, history, plugin and training work that a team should scope and test in its own environment before committing to a date.
Custom field and workflow mapping
Both trackers let administrators define custom fields and status workflows, but the field types, required flags, allowed transitions and list values rarely line up one for one. Export a full sample of each project, list every custom field and status, and decide which ones map, merge or retire. Confirm how each tracker handles multi-value fields and default values before any bulk import runs, since a wrong mapping is easy to miss in a small test set.
LDAP group and role mapping
Redmine supports multiple LDAP authentication sources, and MantisBT authenticates against its database or LDAP and Active Directory with automatic account creation on first login. Group membership does not translate automatically into project roles in either tool. Confirm which directory groups map to which project roles, who approves exceptions, and how disabled directory accounts are handled so that former staff do not keep access to historical issues.
Attachment and history transfer
Issue attachments, journal entries, watchers and timestamps are the records auditors and project managers ask for after cutover. Redmine's built-in importers for Mantis are marked obsolete and not working, and third-party scripts are described as neither tested nor supported, so this step usually needs custom work. Ask the implementer to show, on a copy of your data, how attachments, history and original reporter fields arrive and how file storage paths are preserved.
Plugin compatibility during upgrades
Redmine plugins often carry the most migration risk because each plugin must match the target Redmine version and the Rails and Ruby versions it requires. Inventory every plugin on the current install, confirm whether each one has a release for the target line, and test them on a staging copy before the production window. Plan for a replacement or removal decision for any plugin that has no maintained version.
Redmine upgrade sequence
The Redmine upgrade guide calls for backing up the database and uploaded files, copying configuration, uploads and third-party plugins to the new installation, then running the database and plugin migrations before clearing the cache and restarting. Skipping or reordering a step is the most common cause of a failed cutover. Confirm who owns each step, where backups are stored, how long a restore takes in your environment, and whether a rollback path exists.
User training on a new interface
Moving a team from one tracker to the other changes where people create issues, how they search, what the status names mean and which notifications they receive. Teams that skip this step see duplicate tickets, lost watchers and fields left empty. Plan short role-based sessions for reporters, developers and project managers, publish a field and status guide, and set a window where both systems stay read-only for reference.
What drives the running cost of each tracker
Neither Redmine nor MantisBT carries a license fee, so the running cost of either tracker is almost entirely the work and infrastructure around it. Redmine is GPL v2 with no paid edition, and MantisBT is released under the GNU General Public License, so the budget line that matters is the one you pay people and providers for: the hosting, the database and web server, the staff who upgrade and patch the application, the plugins you depend on, and any external implementation partner. The recurring costs are the ones to plan for first, because they continue after go-live.
On the infrastructure side, Redmine supports PostgreSQL, MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED, SQL Server 2012 or higher, and SQLite, and the installation guide says SQLite is not suited to multi-user production use. MantisBT supports MySQL or MariaDB and PostgreSQL, recommends MySQL, and lists Apache, nginx, lighttpd and IIS as web servers, with PHP 8.4 or later recommended. Ask your team which database engine and web server they already run and support, because a stack that matches existing operations skill is usually cheaper to keep running than one that needs a new skill set. Confirm current minimum versions against the installation documentation before you size a server.
The most predictable recurring work is the upgrade. Redmine's upgrade guide requires a database and file backup, copying configuration, uploads and third-party plugins to the new installation, then running db:migrate and redmine:plugins:migrate. Every plugin you rely on is a maintenance item, so count them during scoping. Ask any implementation partner to quote separately for initial setup, data migration and customization, which are one-time, and for upgrades, backup and restore testing and support, which recur. Ask for the restore test to be included in the written scope, because an untested backup is a risk your auditors will also question.
Questions buyers ask before choosing Redmine or MantisBT
Does Redmine have a paid edition?
No. Redmine is released under the GNU General Public License v2 and has no paid edition, so the software itself costs nothing to license. What you pay for comes from hosting, implementation, plugins, upgrades and the staff who maintain the deployment. Redmine is maintained by community volunteers, so ongoing support has to come from your own team or from a third party you contract directly. Before you compare totals, list each plugin you need, confirm whether its authors charge for it, and ask any implementation partner for a fixed-scope quote in writing. DeployOpen does not publish a price list, and a quote follows from the written scope.
Does MantisBT support LDAP or Active Directory login?
Yes. MantisBT can authenticate users against its own database or against LDAP and Active Directory, and it can create accounts automatically on first login for users who already exist in the directory. Redmine also supports multiple LDAP authentication sources, so directory sign-in does not separate the two on its own. The detail that matters is how directory groups map to MantisBT access levels and project roles. Confirm that mapping, the attribute names your directory uses and the behavior for disabled accounts in a test environment before you rely on it. The MantisBT Admin Guide is the place to check the configuration keys for your release.
Does the Redmine importer for Mantis still work?
No. Redmine's migration notes mark the built-in importers for Trac and Mantis as obsolete and not working. The third-party migration scripts listed for other systems, such as Jira and Bugzilla, are described as neither tested nor supported. A move from MantisBT to Redmine therefore needs a custom export and transform step. In practice, that means extracting issues, users, attachments, notes and history from the MantisBT database, mapping statuses, priorities and custom fields to Redmine equivalents, and loading the data through the Redmine REST API or database tooling. Run the full pipeline on a copy of production data and verify issue counts, attachments and user mappings before you schedule a cutover. The Redmine migration notes list the options.
How much effort does a migration take, and what drives it?
The effort depends on the data you carry across and how closely the target must match your current workflow. The main drivers are the number of issues, attachments and history records, the number of projects and custom fields, the complexity of your status and workflow mapping, how users and permissions translate, and whether email-based intake or integrations must continue to work after cutover. Each driver adds scripting, validation and review time, and none of them is measured in the researched facts for this comparison, so no duration is given here. Ask for a written scope that includes a sample dataset, a test migration, a reconciliation report and a cutover and rollback plan. Ask the vendor to name the assumptions behind their estimate.
Can our team run Redmine or MantisBT ourselves?
Yes, both are self-hosted applications that a capable internal team can operate, provided it has the runtime and database skills. Redmine 7.0 runs on Rails 8.1 with Ruby 3.2, 3.3, 3.4 or 4.0, and it supports PostgreSQL, MySQL 8.0 to 8.4 with READ COMMITTED isolation, SQL Server 2012 or higher, and SQLite, which the installation guide says is not suited to multi-user production use. Its upgrade procedure is documented: back up the database and files, copy configuration, uploads and plugins, run db:migrate and redmine:plugins:migrate, clear the cache and restart. MantisBT requires PHP 8.1 at minimum, with PHP 8.4 or later recommended, and it recommends MySQL. Check the MantisBT Admin Guide for the database and web server combination you plan to use.
What skills and roles do our staff need to run either tracker?
Both platforms need a named application owner, someone who can administer the database, and a systems administrator for the web server, TLS, backups and patching. Redmine adds a Ruby on Rails runtime to manage, so the team needs to handle Ruby versions, gem dependencies and plugin compatibility checks at each upgrade. MantisBT adds a PHP runtime and web server configuration, and it sends notifications through PHPMailer, so outbound mail settings need an owner too. Both need restore testing, not just backups, and a person who reviews LDAP or directory configuration and access levels. If these roles do not exist in-house, you can contract them, but the scope, handover and ongoing responsibilities should be written down before work starts.
How long does a rollout usually take?
The researched facts for this comparison do not give a typical duration, so no timeline is stated here. Rollout length depends on the number of projects and users, whether data must be migrated, how many integrations and authentication sources must be connected, how many approval steps and change windows apply, and how much user training is needed. Ask any implementation partner for milestones, deliverables and acceptance criteria in a written, fixed-scope agreement before work starts. DeployOpen agrees scope, deliverables and timelines in writing for most engagements, and it does not publish a price list, so a quote follows from that written scope.
What to confirm with each vendor before you sign
Start by confirming the database versions you can run in your target environment, because the answer decides the platform's operating cost more than any feature list. Redmine supports PostgreSQL, MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED, SQL Server 2012 or higher, and SQLite, though the installation guide says SQLite is not suited to multi-user production use. MantisBT's Admin Guide supports MySQL or MariaDB and PostgreSQL, lists Microsoft SQL Server and Oracle as experimental, recommends MySQL, and sets minimums of MySQL 5.5.35, MariaDB 5.5.35, PostgreSQL 9.2 and PHP 8.1. Check these minimums against your own database and PHP standards, and ask whether your database vendor's current release is in the supported window for the release line you pick.
Confirm plugin availability for every feature you need before you assume it exists. Redmine's core covers multiple projects, Gantt charts, wikis, forums, time tracking and custom fields, but anything beyond that depends on plugins that you must check against the exact Redmine version, since the upgrade guide requires plugin migration on every upgrade. For MantisBT, confirm whether the workflow, notification and email-to-issue behavior you need is in core. The Admin Guide says reporting issues by email is not supported out of the box and needs third-party patches, so ask the community or your implementation partner to show the patch's maintenance status before you rely on it.
Verify the identity and notification configuration on a staging instance rather than relying on documentation alone. For Redmine, confirm the LDAP authentication settings, how user accounts are created on first login, and whether the REST API is enabled by an administrator for the integrations you plan to run, since authentication uses per-user API keys sent as a parameter or the X-Redmine-API-Key header. For MantisBT, confirm the LDAP and Active Directory settings, the auto-creation behavior for directory users, and whether the SOAP or REST API with per-user tokens meets your integration needs. Test mail delivery end to end, including comment and resolution notifications, using your own mail relay.
How DeployOpen helps choose, implement or migrate your tracker
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. For Redmine vs MantisBT, we start from your project, workflow and identity requirements, then deliver a written plan you can review before any work begins.
How we scope
- Written scope covers which tracker fits your workflows: multi-project planning or bug-focused triage.
- Scope lists identity needs, such as LDAP or Active Directory sign-in, and which accounts are created automatically.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We install the chosen tracker in your cloud account, data center or air-gapped network.
- We configure roles, custom fields, notifications and workflows, and test API access for your integrations.
- We validate the database choice against your supported engine and web server, and document the setup.
How we hand over
- If you migrate, we map issues, users and attachments and test the import against a copy before cutover.
- Handover includes runbooks for backups, upgrades, plugin checks and the database and uploaded files.
- We document configuration and evidence so your team and any independent auditor can review the setup.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover planned upgrades to supported release lines and review of security updates.
- Confirm response expectations and upgrade scope in the written agreement, since they vary by retainer.
