How to Migrate from Kanboard to a Modern UI Without Losing Data
Migrating from Kanboard to a modern interface requires no data export, import, or schema conversion when the new frontend shares the same backend. FrankBoard is built directly on Kanboard's database architecture, which means existing projects, tasks, users, and history remain intact throughout the transition. Teams simply deploy the new UI layer alongside or in place of the legacy interface, with Docker handling the technical orchestration.
How to Migrate from Kanboard to a Modern UI Without Losing Data
Why Traditional Migrations Are Painful
Most Kanban platform switches demand painful extraction procedures. Administrators typically export CSV files, rebuild project structures manually, reassign permissions, and accept the loss of comment threads, file attachments, and activity logs. Even when APIs exist, mapping data between incompatible schemas consumes engineering hours that small teams cannot spare. The fundamental problem is that frontend and backend are treated as inseparable monoliths—forcing a complete replacement rather than an interface upgrade.
How FrankBoard Eliminates Migration Risk
FrankBoard preserves Kanboard's PostgreSQL or MySQL database schema unchanged. Every table—projects, tasks, users, columns, swimlanes, comments, attachments, and action history—remains fully compatible. The migration becomes a frontend swap rather than a data relocation.
This architectural decision means:
- Zero data transformation: No scripts convert timestamps, reformat IDs, or reconcile foreign keys
- Instant rollback capability: The original Kanboard interface can run against the same database if needed
- Parallel testing: Teams can evaluate the modern UI against live production data before committing
Prerequisites for a Seamless Transition
Before beginning, confirm these conditions are met:
| Requirement | Purpose |
|---|---|
| Kanboard 1.2.20 or newer | Ensures database schema compatibility |
| Existing database backup | Provides standard disaster recovery |
| Docker and Docker Compose installed | Enables containerized deployment |
| Database credentials available | Allows FrankBoard to authenticate against existing data |
The database engine—PostgreSQL, MySQL, or SQLite—requires no modification. FrankBoard connects using the same DSN format and credential pattern as the original application.
Step-by-Step Migration Process
1. Create a Database Backup
Standard practice for any infrastructure change. Use pg_dump for PostgreSQL, mysqldump for MySQL, or file-copy for SQLite. Store this independently from the deployment environment.
2. Deploy FrankBoard via Docker
Pull the official image and configure environment variables pointing to the existing database:
FRANKBOARD_DATABASE_URL=postgres://user:pass@host:5432/kanboard
FRANKBOARD_DATABASE_DRIVER=pgsql
The container initializes by validating schema version compatibility, then serves the modern interface against existing data.
3. Verify Data Integrity
Log in with existing credentials. Confirm that:
- All projects appear with correct column structures
- Task counts match the legacy interface
- Historical comments and attachments render properly
- User permissions and group memberships persist
4. Redirect Traffic and Decommission Legacy Frontend
Once validated, update reverse proxy rules to send requests to FrankBoard. The original Kanboard container can remain stopped as an emergency rollback option, or be removed to reclaim resources.
What Preserves Automatically
The shared backend guarantees these elements transfer without intervention:
- Task content and metadata: Titles, descriptions, colors, priorities, due dates, tags
- Workflow state: Column positions, swimlane assignments, board structures
- Collaboration history: Comments, file attachments, subtasks, links
- User ecosystem: Accounts, roles, group memberships, API tokens
- Automation logic: Existing actions and notifications continue firing through the same backend events
What Changes in the Interface
The modern UI introduces contemporary design patterns—responsive layouts, dark mode, keyboard shortcuts, and streamlined navigation—while maintaining conceptual familiarity for Kanboard users. No retraining is required for basic operations. The underlying concepts of boards, columns, tasks, and swimlanes remain identical because they are the same database entities rendered through updated presentation logic.
Handling Edge Cases
Plugin Dependencies
Kanboard plugins that modify database schemas may create compatibility considerations. FrankBoard validates schema on startup and flags deviations. Standard Kanboard installations without schema-altering plugins migrate without issue.
Custom Themes and CSS
Visual customizations from the legacy interface do not transfer, as they targeted the old rendering engine. FrankBoard provides its own theming hooks for equivalent customization.
API Integrations
FrankBoard exposes compatible API endpoints where external tools previously connected to Kanboard. Webhook configurations and API credentials remain functional.
Docker Deployment Patterns
Teams choose between two common topologies:
Side-by-side testing: Run FrankBoard on a separate port against a database replica or snapshot. Evaluate with real data without production impact.
In-place replacement: Stop the Kanboard container, start FrankBoard with identical database connection parameters. Total downtime under two minutes for most configurations.
Key Takeaways
- FrankBoard's shared backend with Kanboard eliminates data migration entirely—no exports, imports, or conversions required
- Existing PostgreSQL, MySQL, or SQLite databases connect directly without schema changes
- Docker deployment completes in minutes with standard container tooling
- Rollback to the original interface remains possible by reverting proxy rules
- All task history, user accounts, permissions, and project structures preserve automatically
- The transition is a frontend upgrade, not a platform replacement