Plane vs Redmine: when each one is the right choice
Choose Plane when you are starting agile delivery on a modern tracker and want a paid path with enterprise sign-in, and choose Redmine when an existing Redmine instance, its plugins and its wiki and repository links are central to how your team works. Plane's self-hosted Community Edition is AGPL-3.0 and matches the Cloud Free feature set, but SAML and OIDC on self-hosted Plane sit on the Pro plan and above, and LDAP and API-enabled audit logs are listed as Enterprise features, so you must first switch to the proprietary Commercial Edition before buying a plan. Redmine is GPL-2.0-or-later with no paid edition, and it brings flexible role-based access, Gantt charts, per-project wikis and forums, time tracking and Git, Subversion and Mercurial integration out of the box.
The decision turns on three questions. First, identity: if you need SAML or OIDC single sign-on, confirm which Plane tier and edition covers it, and if you need LDAP, confirm whether your Redmine LDAP setup already meets the requirement, since Redmine includes multiple LDAP authentication support. Second, the plugin estate: list every Redmine plugin your teams depend on and check whether each has a Plane equivalent or a Plane importer path, because Redmine's built-in importers for Trac and Mantis are marked obsolete and its third-party migration scripts for systems such as Jira are described as neither tested nor supported. Third, who runs upgrades: Redmine's upgrade procedure requires database and upload backups, plugin migration with redmine:plugins:migrate and a restart, and Redmine 7.0.x is the only fully supported line, so plan who owns that work and whether you want it inside a fixed-scope engagement.
Ask your Redmine administrator for an inventory of plugins, custom fields and repository links, then ask Plane for its current tier comparison in writing before you commit to a migration. If your Redmine data is mostly issues and wiki pages, the migration is simpler; if it is heavily customized, budget time for a proof of concept on a copy of the database rather than on production.
Which platform fits which team scenario
This table maps common team scenarios to the platform that fits each one better and names the condition under which the other platform would still win. Each row is a decision test to check against your own requirements and environment. The main takeaway is that Redmine suits teams with existing plugins, SCM history or a no-license-cost requirement, while Plane suits teams that want a modern tracker and can run more self-hosted components.
| Team scenario | Better fit and reason | When the other platform still wins |
|---|---|---|
| Agile product team starting fresh | Plane, for a modern issue tracker with a Community edition that matches Cloud Free features | Redmine wins if the team also needs Gantt charts, time tracking and a per-project wiki in one tool |
| Long-running Redmine shop with custom plugins | Redmine, because the documented upgrade path carries configuration, uploads and third-party plugins forward | Plane wins if the plugins are being retired and the team is willing to rebuild its workflows in Plane |
| Regulated team needing SSO and LDAP | Redmine for LDAP authentication without a paid tier; confirm its SSO options with your plugin set | Plane wins if SAML or OIDC is required, since those start on the Pro plan and LDAP is listed as Enterprise |
| Team with Git and Subversion history | Redmine, which lists built-in repository integration with Subversion, Git and Mercurial | Plane wins if repositories stay on a separate Git host and the team only needs issue tracking |
| Team with no in-house Ruby skills | Plane, which is deployed with Docker Compose or Helm and needs no Ruby knowledge to run | Redmine wins if the team can use a single relational database and avoids PostgreSQL, Redis, RabbitMQ and object storage |
| Air-gapped or disconnected network | Plane Airgapped edition, which is proprietary and built for offline installs | Redmine wins if the team prefers a fully GPL-licensed install with no proprietary edition to manage |
| Budget limited to software licenses | Redmine, which has no paid edition and is free under GPL v2 | Plane wins if its Community edition feature set covers the need and the team stays within the Free seat count |
| Team moving off Jira | Plane, whose Jira importer supports Jira Cloud and Jira Server or Data Center on the Commercial edition | Redmine wins only if the team accepts that third-party Jira migration scripts are untested and unsupported |
How Plane and Redmine are built and what that means for operations
Plane and Redmine make very different demands on the team that runs them. Plane is a multi-service stack with a choice of Docker Compose or Kubernetes, while Redmine is a single Ruby on Rails application that runs on several conventional databases. The cards below cover the components and deployment decisions that shape patching, backups and staffing for each.
Plane's service stack
A self-hosted Plane deployment uses PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage such as MinIO. Each of these is a separate service you must patch, back up and monitor, so the number of moving parts is the first operating question. Ask whether your team will run these components itself or point the Helm chart at managed services.
Docker Compose or Kubernetes
Plane documents Docker Compose for small and mid-size teams and Kubernetes with Helm for high availability. Compose keeps the footprint smaller but places recovery, scaling and node failure on your own runbooks. Helm adds cluster skills to the staffing requirement, and the Kubernetes guide installs the Commercial Edition, so confirm which edition you will run before choosing.
Redmine's Rails runtime
Redmine is a Ruby on Rails application, and Redmine 7.0 runs on Rails 8.1 with Ruby 3.2, 3.3, 3.4 and 4.0. It does not support JRuby. Your team must manage the Ruby version and the gem set, and plugins can depend on both, so a Ruby upgrade can reach into plugin compatibility. Confirm your Ruby build pipeline before you commit.
Redmine's database choice
Redmine supports PostgreSQL, MySQL 8.0 to 8.4 with READ COMMITTED isolation, SQL Server 2012 or higher, and SQLite. The installation guide says SQLite is not suited to multi-user production use, so it is only a fit for evaluation or personal instances. Your database standard largely decides how backups and failover are built, so match Redmine to the engine your DBAs already operate.
Patching and upgrade procedure
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 db:migrate and redmine:plugins:migrate before clearing the cache and restarting. Plane upgrades move a multi-service release at once. Plan a tested rollback for each platform, and check plugin and migration steps in a staging copy first.
Staffing for each stack
Plane asks for container and database operations skills across several services, and Kubernetes adds cluster operations. Redmine asks for Rails, Ruby and database administration, with plugin upkeep on top. Neither has a paid edition for operations support in Redmine's case, so the people who maintain the platform are the main recurring cost. Ask any implementation partner to scope backup, restore and upgrade work in writing.
How plugins, APIs and sign-in differ in practice
Redmine extends mostly through its plugin ecosystem, and that is where most of the integration risk sits. Redmine's core covers multiple projects, role-based access control, Gantt charts, per-project wikis and forums, time tracking and custom fields, but anything beyond that usually arrives as a third-party plugin that must be checked against the exact Redmine line you run. Before you commit, list every plugin your workflow depends on, confirm it has a release for Redmine 7.0.x or 6.1.x, and test it in a staging copy. The upgrade guide also expects third-party plugins to be copied to the new installation and migrated with redmine:plugins:migrate, so an unmaintained plugin becomes an upgrade blocker, not just a feature gap.
Redmine's REST API is off until an administrator enables it, which is a deliberate control you should document in your access baseline. Once enabled, it returns JSON or XML and authenticates with HTTP basic authentication or a per-user API key, passed as a parameter or in the X-Redmine-API-Key header. Core resources such as issues, projects, users and time entries are marked stable, but plugin-provided endpoints are not covered by that label. Plane's self-hosted API story is different: the researched facts list API-enabled audit logs as an Enterprise feature, but they do not describe the full Plane API surface for each edition. Confirm with Plane which endpoints your integrations need on your edition, and test the key-based authentication path in your own environment before you build on it.
Sign-in is where the editions diverge most. On self-hosted Plane, SAML and OIDC are available on Pro and above, while LDAP support is listed as an Enterprise feature, so an organization that relies on directory-based sign-in should price the Enterprise tier before choosing Plane. Redmine supports multiple LDAP authentication sources at no licensing cost, but SAML or OIDC single sign-on is not part of its listed core features, so you would need to confirm a plugin or a reverse proxy approach. Ask each vendor for the exact identity flows, group mapping and account provisioning behavior, and run a test login with a non-production directory before deciding.
Feature comparison: Plane and Redmine
This table compares Plane and Redmine on licensing, workflow, identity, source control, importers, databases and hosting stack. Where the supplied facts do not settle a capability, the cell tells you what to confirm with the vendor before you decide.
| Capability | Plane | Redmine |
|---|---|---|
| License and paid editions | Community Edition under AGPL-3.0; Commercial and Airgapped editions are proprietary and paid plans require the Commercial Edition | GPL-2.0-or-later with no paid edition; cost comes from hosting, plugins and upkeep |
| Issue and sprint workflow | Cycles and modules for sprint-style planning; confirm fit with your delivery method | Issue tracking with Gantt charts and calendars across multiple projects |
| Wikis, forums and time tracking | Confirm with the vendor which of these are built in for self-hosted use | Per-project wikis and forums, plus built-in time tracking |
| Custom fields and role-based access | Confirm with the vendor how custom fields and role scopes work in the Community Edition | Custom fields and flexible role-based access control set per project |
| SSO and LDAP | SAML and OIDC on Pro and above; LDAP listed as an Enterprise feature | Multiple LDAP authentication support; confirm SAML or OIDC support with the vendor |
| Source control integration | Confirm with the vendor which repository integrations are available | Subversion, Git, Mercurial, Bazaar and CVS integration |
| Importers | Jira importer for Jira Cloud and Jira Server or Data Center on Cloud and Commercial plans | Trac and Mantis importers are obsolete; third-party Jira scripts are untested and unsupported |
| Supported databases | PostgreSQL in the self-hosted stack, with Redis or Valkey, RabbitMQ and S3-compatible storage | PostgreSQL, MySQL 8.0 to 8.4, SQL Server 2012 or higher; SQLite is not for multi-user production |
What each license and edition includes and what it costs in license terms
Plane offers three self-hosted editions: Community, Commercial and Airgapped. The Community Edition is licensed under AGPL-3.0 and matches the feature set of the Plane Cloud Free tier. The Commercial and Airgapped editions are proprietary, so using them is governed by Plane's terms rather than by an open-source license alone. Each edition is built on a distinct codebase with its own release cycle, which affects how you plan upgrades.
- Community Edition: AGPL-3.0, with the feature set of Cloud Free and no license key required.
- Free plan on Commercial: Plane's Kubernetes guide installs the Commercial Edition, and its Free plan includes 12 seats with the Free feature set and no license key.
- Paid plans: To move to a paid plan, a self-hosted Community install must first switch to the Commercial Edition, which unlocks plans with a license key and counts seats by users with paid roles.
- Pricing: Plane's pricing page lists Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, with Enterprise Grid priced on request.
- Self-hosted features: SAML and OIDC are available on Pro and above, while LDAP and API-enabled audit logs are listed as Enterprise features.
Check whether your seat count falls on the Free plan or a paid tier, and confirm with Plane which edition your install uses before you buy. The switch from Community to Commercial is a step to plan, not an afterthought.
Redmine is licensed under GPL-2.0-or-later and has no paid edition. The software itself costs nothing to obtain, and the project is maintained by community volunteers, so there is no vendor contract that guarantees support response. Your license line is zero, but the project does not offer a vendor-backed support tier, so any support you need must come from your own staff or a service provider you hire.
- License: GPL-2.0-or-later, with no paid edition and no license key.
- Support model: Community-maintained, so fixes and advice come from volunteers, forums and your own or contracted expertise.
- Version 7.0.x: The fully supported line, receiving new features, bug fixes and security updates. It runs on Rails 8.1.
- Version 6.1.x: Receives only bug fixes and security updates, so plan to move forward before it ages out.
- Version 6.0.x: Receives only important security updates, and 5.1.x and older are unsupported.
License cost is zero for Redmine, but implementation, plugin selection, upgrades and day-to-day upkeep are not. Confirm which version line you will run and who on your side owns security patching on that line.
Redmine's license cost is zero, but the total cost of running it is not. Costs fall into one-time work, such as installation, plugin selection, data migration and configuration, and recurring work, such as hosting, upgrades, backups, security patching and plugin maintenance. Plane's paid plans add a recurring per-user subscription on top of the same infrastructure work, so the two products shift cost in different directions.
- Redmine costs: Hosting, implementation, plugins, upgrades and the staff who maintain the system.
- Plane costs: Per-user subscriptions on paid plans, plus hosting, storage and operations for the self-hosted stack.
- Upgrade effort: Redmine's upgrade procedure includes backing up the database and files, migrating plugins and running migration tasks, which is planned work each time.
- Recurring versus one-time: Subscriptions and hosting recur, while migration and initial configuration are usually one-time, though exact amounts depend on your scope.
- Quote request: Ask any implementation partner to itemize installation, plugin work, migration, upgrade support and any vendor fees separately.
To compare fairly, cost out your expected seat count on Plane's paid tiers against the staff hours you expect Redmine to need for upkeep.
What drives the running cost of each platform
Plane and Redmine cost different things to run. Plane's Community Edition has no license fee, but paid Plane plans are priced per user, while Redmine has no paid edition and its cost sits in hosting, upgrades and plugins. Compare the components below against a written scope before you decide which bill matters most for your team.
Hosting and infrastructure
Plane self-hosting uses PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage, and the Helm chart can point each of these at an external managed service. Redmine runs as a Ruby on Rails application on PostgreSQL, MySQL, SQL Server or SQLite, with SQLite not suited to multi-user production use. The recurring cost is the server footprint and managed services each stack needs, so ask the implementer to size both against your user count and availability target.
Upgrade and maintenance labor
Redmine's upgrade procedure calls for backing up the database and uploaded files, copying configuration, uploads and third-party plugins to the new installation, then running db:migrate and redmine:plugins:migrate before clearing the cache and restarting. This work recurs with every line you adopt, and it grows with each plugin you carry. Ask who performs and tests each upgrade, and whether the quote covers it as a one-time setup or a retainer.
Plugin development and maintenance
Redmine has no paid edition, so capabilities such as extra workflows or integrations usually come from plugins, which must be migrated during every upgrade. Plane's paid tiers carry more of the feature set in the product, but custom integrations still need build and test effort. Ask which plugins you need on day one, who owns their compatibility with each Redmine release, and whether the quote includes regression testing after upgrades.
Paid Plane seat fees
Plane's pricing page lists Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, with Enterprise Grid priced on request, according to Plane pricing. These fees recur for every paid seat, and the seat count drives the total more than any other input. Self-hosted paid plans also require switching to the Commercial Edition and a license key, so confirm which plan unlocks SAML, OIDC and LDAP for your identity setup before you commit seats.
One-time implementation fees
Implementation covers planning, installation, identity integration, the Redmine or Plane data migration, and handover documentation. It is usually a one-time cost, but migration effort rises with the number of projects, custom fields, attachments and history you keep. Redmine's own migration wiki describes third-party scripts for systems such as Jira as neither tested nor supported, so ask for a fixed-scope written plan that names the source systems, the data to keep and the acceptance tests.
How to move Redmine projects to Plane, step by step
This sequence turns a Redmine instance into a validated, staged move to Plane, with each project proven in a pilot before the old system is retired. Every step ends with a check that you can record as evidence.
Inventory every Redmine project and its dependencies
List each project, subproject, tracker, custom field, role, workflow, plugin, wiki, forum and repository link in the Redmine instance. Export the project list and the user and group list from the administration screens, and note which projects are archived, closed or still in use. Record the Redmine version in use, since 7.0.x, 6.1.x and 6.0.x are on different support levels. The step is done when you have a written inventory that the project owner for each project has reviewed and signed off.
Decide which history must survive the move
Agree with the business owners which data must be carried into Plane, such as issue history, journals, attachments, time entries, version targets and linked repository commits. Mark anything that can be archived as a read-only export instead. Keep the Redmine instance available for lookups during the transition. The step is done when each data category has a recorded decision, a named owner and a retention note that compliance or legal has accepted.
Map trackers, statuses and custom fields to Plane
Map each Redmine tracker to a Plane work item type, each Redmine status to a Plane state, and each custom field to a Plane property or a documented loss. Redmine workflows restrict which status changes are allowed, so record those rules too, because Plane does not carry them over by default. Confirm the mapping with one or two team leads who work the queues daily. The step is done when a signed mapping table exists and every unmapped field has an agreed fallback, such as a text field in the description or an archived export.
Confirm an export path, since Plane's documented importers cover Jira and Linear
Plane's documented importers are for Jira and Linear, and the Jira importer covers Jira Cloud as well as Jira Server and Data Center. Redmine is not on that list, and Redmine's own migration wiki marks its importers for Trac and Mantis as obsolete and lists third-party scripts, including those for Jira and Bugzilla, as neither tested nor supported. Ask Plane in writing whether a Redmine import path exists for your edition, or whether you will need a custom script or a service provider to build one. The step is done when you hold a written answer on what Plane supports for Redmine and what you must build or test yourself.
Run a pilot project end to end
Choose one active, moderately complex Redmine project and move it through the full chain: export, transform, load into a non-production Plane workspace, and review. Compare issue counts, statuses, assignees, dates, comments, attachments and relations between the two systems. Have the project team work in the pilot for a fixed review period and log every discrepancy. The step is done when the pilot reconciliation shows no unexplained differences and the team has accepted the mapping in writing.
Cut over attachments, wiki content and repository links
Move Redmine attachments to Plane storage, which on self-hosted Plane is S3-compatible object storage, and check that every linked file opens. Move wiki pages and forum content into the knowledge tool you have chosen, because Plane is an issue tracker and is not a replacement for a Redmine wiki. Rebuild repository links in the new issues so commit references still resolve against Git, Subversion or Mercurial. The step is done when a sample of attachments, wiki pages and commit links has been opened and checked against the source.
Freeze, cut over and verify the production load
Announce a write freeze on the Redmine projects in scope, run the final export, load it into production Plane, and reconcile counts and sample records against the frozen source. Set Redmine to read-only for the moved projects so no new work lands in the old system. Confirm user access, roles and notifications in Plane for every team. The step is done when the reconciliation report is signed by the project owners and users can open and update their issues in Plane.
Retire the old Redmine instance deliberately
Keep the Redmine database backup and uploaded files under your retention policy before you decommission anything, following the same backup-first discipline Redmine's upgrade guide describes. Remove plugins, integrations and scheduled jobs that pointed at Redmine, and update any links in documentation, runbooks and email templates. Record the decommission date and the location of the archive. The step is done when the archive is verified as restorable, the dependent integrations are repointed, and the old instance is switched off with approval from the system owner.
Where Plane and Redmine implementation projects usually run long
The longest Plane and Redmine projects usually run long for reasons that show up after the platform is already running, so the written plan should price those items explicitly. On the Plane side, the self-hosting setup is the first decision: a self-hosted Plane deployment uses PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage, and the Helm chart can point each of these at an external managed service. Each external choice moves backup, patching and availability work to a different owner, so ask who runs each dependency. Identity is the second risk. SAML and OIDC are listed for Pro and above, and LDAP support is an Enterprise feature, which means a Community install that needs single sign-on will first have to move to the Commercial Edition, as the Plane editions documentation describes. Confirm the plan tier before the identity design is signed off.
On the Redmine side, the largest unplanned cost is usually plugin compatibility. Plugins are often the reason a Redmine instance still exists, and each one must be checked against the target major version before the upgrade is scheduled. 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, so a host image that pins an older Ruby will need rebuilding first. Workflow mapping is the third risk for both platforms, because Redmine trackers, statuses and custom fields rarely map one to one onto Plane's cycles, modules and states. The built-in Trac and Mantis importers are marked obsolete, and the third-party scripts for Jira and Bugzilla are described as untested, so budget for scripted mapping and a test migration.
A fixed-scope written plan should name each overrun explicitly: plugin replacement or retirement with a per-plugin decision, a field-level data mapping document signed by the project owners, the identity integration with its plan requirement, and a defined parallel running period with an agreed cutover point. Ask for the plugin inventory, the Ruby and Rails versions each plugin supports, the database engine in use, and the acceptance tests that prove migrated issues, attachments and permissions match the source. Ask the implementer to state which items are excluded, and confirm with the Plane and Redmine maintainers any compatibility detail that the supplied documentation does not settle.
Questions buyers ask about Plane and Redmine
Is Redmine free to run, and what does it really cost?
Redmine has no paid edition. It is released under GPL v2, so the license cost is zero, but the cost of a deployment comes from hosting, implementation, plugins, upgrades and the people who maintain it. Those costs are mostly one-time for setup and recurring for hosting, staff time, and upgrades. Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0, so your team needs a Ruby stack that matches the supported line. Ask any implementation partner for a quote built from written scope covering installation, plugin selection, backups, upgrade cadence and who answers security fixes. DeployOpen does not publish prices, so a quote follows from the agreed scope.
Is the Plane Free plan enough for a small team?
The Plane Free plan is enough when your team stays within its 12 seats and needs only the Free feature set. On self-hosted Plane, the Free plan includes 12 seats and needs no license key, according to Plane's Kubernetes documentation. Once you need SAML or OIDC single sign-on, you move to Pro or above, which requires switching a Community install to the Commercial Edition first. Plane's pricing page lists Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month. Confirm the seat count, the sign-in method you require and whether your workflows depend on any paid feature before you choose.
How long does a Redmine to Plane migration take, and what does it depend on?
The duration depends on how much history you need to carry, how cleanly your Redmine data maps to Plane's model, and how much of the process your team can handle. Plane's Jira importer is documented, but no Redmine importer is listed in the supplied sources. Redmine's own migration wiki marks the built-in importers for Trac and Mantis as obsolete and not working, and describes third-party scripts as neither tested nor supported. Plan an inventory of projects, custom fields, roles, attachments and wiki content, then a trial import into a test instance. Ask the migration partner to state the mapping approach and the verification steps in writing before work begins.
Can an internal team run Plane or Redmine without outside help?
An internal team can run either platform, but the work it takes differs. Redmine is a Ruby on Rails application that supports PostgreSQL, MySQL 8.0 to 8.4, SQL Server 2012 or higher and SQLite, which the installation guide says is not suited to multi-user production use. Upgrades follow a procedure that backs up the database and uploaded files, copies configuration and plugins, then runs database and plugin migrations. Self-hosted Plane uses PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage, and can be deployed with Docker Compose or Kubernetes with Helm. Count the people who will handle upgrades, backups and security fixes, and confirm that they can cover them during an incident.
What does SSO require on self-hosted Plane?
On self-hosted Plane, SAML and OIDC are available on the Pro plan and above. LDAP support is listed as an Enterprise feature. To use these, a self-hosted Community install must first switch to the Commercial Edition, because paid plans are unlocked with a license key. Confirm with Plane which identity provider settings, group mappings and user provisioning behaviour apply to your plan, and test sign-in against a staging instance before cutover. Your identity team should also confirm how sessions expire and how accounts are removed when people leave.
Do Redmine plugins have equivalents in Plane?
Some Redmine plugin functions have counterparts in Plane, but the match is not one-to-one. Redmine ships with multiple projects, role-based access, Gantt charts, wikis and forums, time tracking, custom fields and LDAP authentication, and many teams add plugins for more. Plane's supported import and integration paths are documented for Jira and Linear, and its paid editions add SAML, OIDC, LDAP and API-enabled audit logs. Inventory every installed plugin, mark which ones are core features in Plane, and list the rest as gaps to rebuild, replace or drop. Ask the vendor or partner to confirm each gap before you commit.
Which platform is easier to upgrade over the next few years?
Both platforms have upgrade procedures, but their release rhythm and support windows differ. Redmine 7.0.x is the fully supported line, 6.1.x receives only bug fixes and security updates, and 6.0.x receives only important security updates, while 5.1.x and older are unsupported. Plane publishes Community Edition releases on GitHub, with v1.4.2 in August 2026, and runs the Commercial Edition on its own release cycle. Because the editions use separate codebases, confirm which line you will run, how long it will receive security fixes and how plugin compatibility is handled at each upgrade.
How DeployOpen helps teams choose, implement or migrate
DeployOpen helps teams decide between Plane and Redmine, then plans, implements and hands over the chosen platform inside the client's own infrastructure. We work from a written scope, so the decision, the migration and the run model are agreed before any installation begins.
How we scope
- Confirm which Plane edition fits the team, since a paid Plane plan requires the Commercial Edition with a license key.
- Map Redmine projects, plugins, custom fields and repositories to the scope before agreeing on a migration approach.
- Agree in writing which features, integrations and identity sources are in scope and which need vendor confirmation first.
How we build
- Install the chosen platform in your cloud account, data center or air-gapped network using the deployment method your team selects.
- Configure identity integration, backups and the Redmine or Plane database stack, then test restores before go-live.
- Run security testing on the deployed tracker and its integrations, and document the results against the agreed scope.
How we hand over
- Deliver runbooks for upgrades, backups and plugin or add-on maintenance written for your own operations staff.
- Document configuration, access roles and the migration mapping so that later changes can be made without us.
- Walk your administrators through the handover and record which items remain open at the end of the engagement.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work is complete.
- Track Plane and Redmine release lines so that upgrades follow the vendor's supported versions for your environment.
- Agree support boundaries, response expectations and upgrade windows in writing before the retainer starts.
