Moving from Redmine to an ERP, project by project

OutsourcingVN is operated by Netbase JSC, and legacy application modernization is the service that scopes a move like this as a project, so read this guide with that interest in mind. The mechanics are the same ones incremental modernization without a rewrite sets out for any legacy system; this page covers the Redmine-specific seams that method meets on the way to an ERP: its projects and trackers, its custom fields and time-tracking activities, and its own REST API.

Contents

• When has Redmine become your project accounting system?
• Which Redmine records map to which ERP module?
• How do you cleanse and migrate the data?
• Which ERP fits the gap Redmine leaves?
• The Redmine to ERP migration pipeline
• Worked scenario: a hypothetical engineering consultancy whose Redmine became its project ledger
• Where does AI fit in a Redmine to ERP migration?
• What has Netbase delivered that bears on a Redmine to ERP move?
• Which questions should you ask a migration vendor?
• What goes wrong in a Redmine to ERP migration?
• How this guide is sourced and where it stops
• Common questions
• From project tracker to ERP project

When has Redmine become your project accounting system?

A CRM or a ledger that outgrew its role raises the same kind of question from a different starting point; the Vtiger CRM to ERP migration guide covers the CRM side and the QuickBooks to Odoo migration guide covers the accounting side. Redmine raises it from project and issue tracking.

A deployment failing two or more of these signals has become the project and time-tracking system of record in practice, whatever it was bought to do.

Which Redmine records map to which ERP module?

Redmine organises a deployment around projects and their subprojects, trackers, issues, time entries and wiki pages, each scoped by project membership; an ERP keeps a similar project shape, so the mapping is mostly a naming and ownership exercise.

Redmine's own documentation describes custom fields as a way to add additional information to several types of data, including issues, spent time entries, projects, versions, users and groups, in formats including boolean, date, float, integer, list, text, link, user and version; a tracker defines the nature of an issue, and Redmine ships three by default — bug, feature and support — so a deployment that renamed or added its own needs each one read, not assumed, before it is mapped. A role is a collection of permissions a project member holds, a member with several roles gets the combination of their permissions, and groups can be added as project members just like users, with the same roles, and a user added to a group inherits the group's privileges; an equivalent access rule, not a single migrated user record, carries that pattern forward. The project and timesheet decisions this mapping feeds are the ones ERP and back-office operations maps more broadly, and a project whose cost and time roll up into one place is the structure legacy data migration planning expects before any module is chosen.

How do you cleanse and migrate the data?

Legacy data migration planning sets out the general discipline: profile what the old system actually holds, agree in writing what moves, archives or stays behind, and accept the result on reconciliation evidence rather than a clean-looking log. Redmine's own REST API documentation lists Issues, Projects, Users and Time Entries as stable resources, with Wiki Pages, Roles, Groups and Custom Fields still at alpha status, and supports both XML and JSON; a migration script authenticates with an API key and pages through each resource, since a request returns 25 items by default and at most 100. Wiki pages carry a full revision history, which Redmine's own documentation says is kept for every change made to a page, so a decision is needed on whether that history moves across or only the current version does.

If the destination is Odoo, its documentation describes the matching half: the import tool uses an External ID, kept apart from Odoo's internal database ID, to avoid duplicates on a second import pass and carry a Redmine record's identity forward; because a timesheet line refers to a project and an employee, the related records import first.

Which ERP fits the gap Redmine leaves?

That destination choice is separate from the migration itself. Odoo vs custom ERP compares configuring Odoo, extending it with a custom module, and building a custom ERP from zero, by process fit, integration load and who owns the result; the Odoo platform page covers where Odoo fits before that choice. Where the organisation's own work is itself project-based, such as an energy or engineering operation booking cost and time to a project, Odoo for energy and engineering projects picks up from that decision.

Worked scenario: a hypothetical engineering consultancy whose Redmine became its project ledger

A mid-size engineering consultancy started on Redmine for issue tracking on one client project. Four years on, its live projects nest subprojects for phases and sites, custom trackers classify work beyond the default bug, feature and support set, and groups scope which subcontractors see which project, none of it planned; it accumulated one request at a time. The inventory step finds a dozen nested subprojects and locked wiki pages nobody remembers protecting. The custom trackers become task tags, since the new system already classifies tasks; the group-based access becomes a short list of access rules, since nothing replicates project membership automatically. The busiest project runs in parallel for three weeks before cutover, since that is where a missed time entry would be noticed first; finished projects cut over last.

Where does AI fit in a Redmine to ERP migration?

The clearest use sits in the inventory and mapping steps: reading a Redmine tracker's issues to draft a first-pass classification of the work it represents, for a person to confirm, and generating a candidate field-mapping table from a sample export for a person to check line by line. None of that assistance decides whether a mapped project is correct or signs off a cutover. Netbase's delivery lifecycle: discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; ongoing support.

What has Netbase delivered that bears on a Redmine to ERP move?

Netbase's own ERP consultancy and development experience includes Redmine to ERP development, for an organisation that stays unnamed.

Separately, where Odoo is the destination, the Odoo implementations record records Odoo consultancy and customisation delivered in Vietnam with a local Odoo implementation partner.

A further published record, the multi-tenant cloud ERP SaaS platform, is the closest example of work and project management built beside other ERP modules: since 2020 Netbase has worked as offshore development and managing partner on it, and work and project management is among its first-phase modules.

Which questions should you ask a migration vendor?

• Which Redmine projects, trackers and custom fields are in scope, and who reads the access rules line by line rather than assuming the project list is complete?
• What happens to a project's wiki page on cutover day, not just to its issues and time entries? Most Netbase projects are agreed as fixed-scope contracts after discovery, and this is the kind of detail discovery should fix in writing.
• If the destination is Odoo, which import method is used for each module, and how are duplicates avoided on a second pass?

What goes wrong in a Redmine to ERP migration?

• Treating a tracker as self-explanatory. A renamed or added tracker nobody reads before mapping becomes a task classification that means something different in the new system.
• Migrating a wiki page without its attachments. A specification or sign-off that only exists as an attachment is lost if the script follows issues and time entries alone.
• Assuming project membership is the whole access picture. A group assigned to several projects with different roles needs several access rules, not one.
• Cutting over before reconciliation holds. A project switched on optimism rather than evidence generates the first missed time entry after go-live.

How this guide is sourced and where it stops

Redmine's projects, trackers, custom fields, time entries, activities, roles, groups, wiki pages and REST API facts are read from Redmine's own wiki and developer documentation on the dates cited; the Odoo import facts are read from the documentation for Odoo 18.0. The pipeline and the worked scenario above are editorial guidance for planning the move, not a duration or scope claim for any one project.

From project tracker to ERP project

Legacy application modernization scopes a Redmine to ERP move as a project, with the inventory, the mapping, the parallel run and the cutover staged as separate milestones. Bring your project list, your busiest custom tracker and the wiki content you cannot afford to lose, and submit a project; a person will reply with the fit. OutsourcingVN is Netbase's own outsourcing-services platform.

Related services and solutions

Sources

• Redmine, Custom fields
• Redmine, Roles and permissions
• Redmine, Groups
• Redmine, Project settings
• Redmine, Issues
• Redmine, Time tracking
• Redmine, Wikis
• Redmine, REST API
• Odoo, Import and export data, documentation for Odoo 18.0