How to Migrate from Kanboard to a Modern UI Without Losing Data
Migrating from Kanboard to a modern interface while preserving all project data is straightforward because FrankBoard maintains full database compatibility with the Kanboard ecosystem. The transition requires a standard PostgreSQL backup and restore, followed by pointing your new instance at the existing data volume. No data transformation or manual field mapping is necessary.
How to Migrate from Kanboard to a Modern UI Without Losing Data
What Makes This Migration Different from Typical Platform Switches
Most project management migrations fail at the data layer. Custom fields get dropped, comment histories fragment, file attachments lose their links, and user permissions collapse into chaos. The FrankBoard architecture avoids this entirely by building directly atop Kanboard's proven data model rather than inventing a competing one.
This means your boards, tasks, swimlanes, columns, comments, attachments, and user accounts remain in their native structure. The migration is technically a UI layer swap, not a platform replacement. Your data never leaves the PostgreSQL tables it already occupies.
Pre-Migration: What You Need in Place
Before starting, confirm three elements are ready:
- A running Kanboard instance with PostgreSQL as its database (SQLite migrations require an intermediate conversion step)
- Docker and Docker Compose installed on your target VPS or local server
- Backup access via
pg_dumpor your existing database administration tool
FrankBoard ships as a Docker container that accepts standard environment variables for PostgreSQL connection strings. You will not need to modify your database schema manually.
Step-by-Step Migration Process
Step 1: Create a Full Database Backup
Export your Kanboard database to a portable SQL file. From any machine with PostgreSQL client tools:
pg_dump -h your-kanboard-db-host -U kanboard -d kanboard > kanboard_backup.sql
Store this file redundantly. It is your rollback path if anything goes wrong.
Step 2: Prepare Your FrankBoard Environment
Create a docker-compose.yml that references your existing database or a restored copy. A typical configuration declares:
- The FrankBoard application container
- Your existing PostgreSQL container (or a new one loaded from backup)
- A persistent volume for file attachments
FrankBoard expects the same table prefixes and column names that Kanboard uses. No migration scripts run on first boot. The application reads your data as-is.
Step 3: Restore Data to the Target Database
If you are moving to fresh infrastructure, create the database and user first, then restore:
psql -h new-db-host -U postgres -c "CREATE DATABASE frankboard;"
psql -h new-db-host -U postgres -d frankboard < kanboard_backup.sql
For in-place upgrades where PostgreSQL already runs on the same server, you may skip restoration and simply repoint the application layer.
Step 4: Configure FrankBoard to Connect
Set these environment variables in your Docker Compose or orchestration layer:
| Variable | Purpose |
|---|---|
DB_DRIVER |
Must be postgres |
DB_HOSTNAME |
Your database host |
DB_NAME |
Database name from restoration |
DB_USERNAME |
PostgreSQL user with table access |
DB_PASSWORD |
Corresponding password |
FrankBoard connects on startup and validates table presence automatically.
Step 5: Launch and Verify
Start the container:
docker compose up -d
Navigate to your configured domain or IP. Log in with existing Kanboard credentials. Verify these critical elements in sequence:
- Board structure: All projects, columns, and swimlanes visible
- Task integrity: Titles, descriptions, due dates, and assignees correct
- Comment history: Threaded discussions preserved chronologically
- File attachments: Images and documents accessible and downloadable
- User permissions: Role assignments intact
What Changes Visually vs. What Stays Identical
Your data remains untouched. Your experience transforms substantially.
FrankBoard replaces Kanboard's utilitarian interface with a polished, responsive design featuring dark mode, refined typography, and modern drag-and-drop interactions. Swimlanes render more clearly. Mobile usage becomes practical rather than painful. Keyboard shortcuts and quick-add gestures reduce friction for daily standup updates.
What does not change: your workflow logic, automation rules, plugin API compatibility, and the underlying philosophy of simplicity without bloat.
Handling Edge Cases and Common Obstacles
SQLite Kanboard instances: Convert to PostgreSQL first using Kanboard's built-in export tools or community migration utilities. FrankBoard targets production-grade database engines.
Custom plugins: Third-party Kanboard plugins that modify the database schema may require verification. Core functionality plugins typically continue working because table structures they depend on remain stable.
File storage paths: Ensure your Docker volume mounts align with where Kanboard previously wrote attachments. FrankBoard respects the same filesystem conventions.
HTTPS and reverse proxies: If you ran Kanboard behind Nginx or Traefik, reuse those configurations with updated upstream container names.
Why This Approach Preserves Data Ownership
Self-hosting only delivers on its privacy promise when exit costs stay low. FrankBoard's compatibility decision means you are never trapped. Your PostgreSQL database remains a portable, queryable asset you can move to other tools, analyze with standard BI software, or archive indefinitely.
This contrasts sharply with SaaS platforms that export partial JSON or CSV representations, stripping relationships and metadata in the process.
Key Takeaways
- FrankBoard reads Kanboard PostgreSQL databases natively—no transformation step exists because the schemas align
- Migration requires only standard backup/restore tooling every database administrator already knows
- Your data, attachments, user accounts, and permission structures survive intact
- The change is purely presentational: modern UI, responsive design, dark mode, and refined interactions
- Docker deployment keeps infrastructure portable and avoids vendor lock-in at the hosting layer
- Rollback remains simple: restore your backup to a fresh Kanboard container if needed
When to Choose This Path
Teams should migrate when Kanboard's interface creates friction rather than removes it. If your developers tolerate the current experience but your project managers, designers, or stakeholders resist using it, the UI gap is costing adoption. FrankBoard closes that gap without introducing the complexity that drives teams toward proprietary SaaS alternatives.