How to Migrate from Kanboard to a Modern UI Without Losing Data or Vendor Lock-in
Moving from Kanboard to a modern interface while preserving your data and avoiding vendor lock-in is straightforward with FrankBoard, which uses the same open-source database schema and file structure. The migration requires a database dump, file transfer, and container redeployment—no proprietary conversion tools or paid migration services needed. Your existing plugins, attachments, and project history remain intact because FrankBoard maintains compatibility with Kanboard's underlying architecture.
How to Migrate from Kanboard to a Modern UI Without Losing Data or Vendor Lock-in
What Makes This Migration Different from Typical Platform Switches
Most project management migrations force painful choices: export to CSV and lose history, pay for official migration tools, or accept proprietary formats that trap your data. The Kanboard-to-FrankBoard path avoids all three. Because FrankBoard is built directly on Kanboard's foundation, your PostgreSQL or SQLite database requires no schema transformation. User accounts, task comments, file attachments, swimlane configurations, and automation rules all transfer as-is.
This architectural continuity means zero vendor lock-in. Both platforms use the same open-source license (MIT), store data in standard formats, and run on infrastructure you control. If you ever want to move back to vanilla Kanboard or fork your own variant, nothing stops you.
Pre-Migration: What to Back Up and Verify
Before touching production data, confirm three elements are exportable:
- Database: Full SQL dump from PostgreSQL, MySQL/MariaDB, or SQLite file
- Data directory: Board attachments, thumbnails, and plugin files (typically
/var/www/kanboard/data) - Configuration:
config.phpfor database credentials and custom settings
Verify your current Kanboard version. FrankBoard maintains broad compatibility, but knowing your baseline helps if you encounter edge cases with older plugins or custom themes. For a complete checklist on self-hosted board preparation, see The Best Self-Hosted Kanban Board for Small Teams: A Complete Guide.
Step-by-Step Migration Process
1. Halt Writes to the Source Board
Put Kanboard into maintenance mode or schedule downtime. Any tasks created during migration will not appear in your transferred database.
2. Export the Database
For PostgreSQL:
pg_dump -U kanboard -h localhost -Fc kanboard > kanboard_backup.dump
For SQLite, simply copy the .sqlite file after ensuring no active connections.
3. Transfer Files and Attachments
Archive the data directory:
tar -czf kanboard_data.tar.gz /var/www/kanboard/data
Move both the database dump and archive to your new server or retain them for same-host deployment.
4. Deploy FrankBoard with Your Existing Data
Spin up the FrankBoard container with your preferred orchestration. Mount your transferred data directory and point the database configuration to your restored dump. Detailed container configuration is covered in Deploy FrankBoard with Docker and PostgreSQL.
5. Validate and Re-enable Access
Log in with existing credentials. Spot-check projects, swimlanes, file attachments, and plugin functionality. Once confirmed, redirect DNS or reverse proxy rules to the new instance.
Preserving Plugin Functionality and Custom Workflows
Not every Kanboard plugin has a FrankBoard equivalent, but core functionality and widely-used extensions typically work without modification. Plugin compatibility depends on whether the extension hooks into Kanboard's standard API or modifies core templates directly.
For a breakdown of which plugins transfer cleanly and which require alternatives, review FrankBoard and Kanboard Plugin Compatibility. The most reliable path: test your critical plugins in a staging environment before cutting over production traffic.
Eliminating Vendor Lock-in for Good
True data portability requires more than a one-time migration. FrankBoard preserves your freedom through:
- Standard database formats: PostgreSQL, MySQL, or SQLite—no custom blob storage
- File-system attachments: Files stored as ordinary directories, not opaque object stores
- Open configuration: Plain PHP and environment variables, not encrypted settings
- MIT license: Full source access with no commercial restrictions
This structure means your project data lives in formats any competent developer can work with. You're never hostage to a single vendor's roadmap, pricing changes, or shutdown announcements. For the broader implications of controlling your own infrastructure, see Self-Hosted vs. Cloud Kanban Boards: A Privacy-Focused Comparison.
Common Migration Pitfalls to Avoid
- Assuming plugin parity: Test custom integrations before go-live
- Forgetting background jobs: Recurring task notifications and automated actions may need reconfiguration
- SSL/certificate mismatches: Update OAuth or webhook URLs if domain changes
- Permission drift: Container UIDs may differ; verify file ownership in the new data directory
Key Takeaways
- FrankBoard accepts standard Kanboard database dumps and file structures with zero transformation required
- The entire migration runs on open-source tooling—no paid converters or proprietary lock-in
- PostgreSQL and SQLite databases restore directly; MySQL/MariaDB require minor adaptation
- Plugin compatibility varies; validate critical extensions in staging
- Your data remains portable before, during, and after migration through standard formats and MIT-licensed code
- Full deployment guidance is available in How to Migrate from Kanboard to FrankBoard Without Data Loss