Moving from Redmine
There is no Redmine importer. You set up the structure by hand and bring over tickets, comments and time with a script of your own against the REST API. This page shows what maps to what, what you lose and how to plan the move.
What maps to what
| Redmine | Lalabase |
|---|---|
| Project | Project in an organisation. Agencies usually keep one organisation per client |
| Subproject | No equivalent. Use separate projects, or one project with tags |
| Issue | Ticket |
| Tracker | Ticket field of your choice, for example a select field "Type" |
| Status, priority | Ticket fields, configured per project |
| Custom fields | Ticket fields: select, multi-select, checkbox, text, date. There are no fields on projects or users |
| Category | Select field, which a script can fill, or a tag |
| Target version | Select field. There are no version or roadmap pages |
| Subtasks | Sub-tasks, one level deep |
| Related issues | Ticket relations |
| Watchers | Followers |
| Roles | Roles, per organisation |
| Wiki | Knowledge, with versioned notes |
| Files, documents | Documents |
| Time entries | Time tracking, each entry billable on its own |
| Repositories | Connected repositories |
What Lalabase does not have
Check these first. If you depend on one of them, Redmine may stay the better choice.
- Creating tickets by mail. Lalabase sends mail, but reads none.
- Gantt chart and calendar. There is a list and a board.
- Forums and news.
- Plugins. There is no plugin system. Instead there are the REST API and MCP for your own tools.
- Time activities. A booking has a description, but no activity type such as "Design".
What a script can carry over
The REST API lives at /api/v1 and uses an access token that
may write. It has no public reference yet. Every write counts as the owner of the token, and
you are limited to 60 requests per minute per token.
| Data | Over the API | What gets lost |
|---|---|---|
| Tickets | POST /api/v1/projects/:project_id/tickets: title, description, parent, assignees, fields |
Author and creation date: you become the author, today the date. Numbers are assigned anew |
| Comments | POST /api/v1/tickets/:ticket_id/posts, as HTML or with format: plain |
Author and date, as for tickets |
| Time | POST /api/v1/tickets/:ticket_id/time_sessions with date and duration |
The person: every booking lands on the token's owner |
| Tags, ticket relations | Not possible | Use a select field instead of tags, and set relations by hand. Bulk edit helps with tags |
| Attachments | Not possible | Upload them by hand, or link them |
| Wiki | Not possible | Copy the important pages by hand |
| Projects, fields, users | Not possible | Set them up in the web app first |
| Change history | Not possible | The history of status changes stays behind |
Three things save trouble later:
- Create a text field "Redmine ID" and fill it, so that old numbers can still be found.
- Write the original author and date into the first line of each description and comment.
- Convert Textile or Markdown to HTML in your script. Lalabase does not read either.
To keep the bookings per person, run the time import with one token per person. Each person creates their own token.
Plan the move
- Try it on one project. Pick a small, finished one and judge the result with your team.
- Set up the structure. Create organisations, projects, ticket fields and roles, and invite people. Their invitations need working mail.
- Decide how much to bring. Open tickets and the time of the current billing period are often enough. Keep the old Redmine read-only for everything else.
- Run the import, ticket first, then comments, then time. Log which Redmine ID became which ticket, so that a failed run can resume.
- Check and switch. Compare the number of tickets and the booked hours per project with Redmine, then make Redmine read-only.