Replacing operational software is a real project. Data needs to move, workflows need to transfer, and staff need to be trained. ClientSt0r treats migration tooling as a core adoption requirement, not an afterthought.
ClientSt0r supports import for the record types that matter most in an MSP migration. Coverage varies by import method — CSV wizard handles the most common types, the REST API covers everything.
Organisation names, contacts, addresses, account types, and custom fields. The foundation — import these first, as all other records link to an org.
Hardware assets, serial numbers, warranty information, linked organisation, and asset type categories. Device type and location metadata is preserved where available.
Credential records including username, URL, and notes. Records can be imported encrypted or re-encrypted on import using the destination vault key.
Documentation content, article categories, and linked client organisation. Article body content is imported as-is — formatting may require review after import.
Historical tickets, status, assignee, time entries, and notes — imported as a read-only archive. Active ticket workflows cannot be migrated from other platforms.
Contract type, billing cycle, start and end dates, and linked organisation. Contract line items and associated invoices are supported where the source platform exports them.
IP address assignments, subnet definitions, and VLAN configurations. Network topology data from other platforms maps to the IPAM module.
Staff user accounts and role assignments. Passwords are not migrated — all imported user accounts require a password reset on first login.
Choose based on your data volume, technical comfort level, and the source platform. Both methods end up in the same place — the choice is about how you get there.
The import wizard walks through column mapping and validation before committing records. Suitable for one-off migrations and smaller data sets where manual review is practical.
POST records programmatically using the ClientSt0r REST API. Suitable for large data sets, platforms with their own APIs, and migrations where you want full control over transformation logic before records land in the system.
The REST API accepts the same field structure as the CSV import wizard, with the same validation rules applied on write. Rate limiting applies — structure bulk imports with appropriate delay between batches.
Each platform exports data differently. These notes cover what maps cleanly and where you should plan for manual work.
IT Glue exports are available via their API or the data export feature in account settings. Organisations, contacts, documents, passwords, and configurations can be mapped to ClientSt0r equivalents. Password export requires IT Glue admin access. Network diagrams embedded in IT Glue documentation will need to be recreated manually in Draw.io — there is no automated conversion from IT Glue's diagram format.
Hudu provides CSV export for most record types from the admin panel. Organisations, assets, passwords, and documentation map cleanly to ClientSt0r. Hudu Magic Dash data and custom integration displays are presentation-layer features and will need to be recreated. Custom asset layout fields can be mapped to ClientSt0r custom fields during the import process.
PSA migration is primarily about ticket history and company/contact records. Active tickets should be wound down selectively before cutover — bulk migration of open tickets from a PSA into a new system mid-flight rarely goes well in practice. Bulk historical ticket import is supported as read-only archive data. Company and contact records export cleanly via both platforms' APIs and map directly to ClientSt0r organisations and contacts.
Company records, contacts, and ticket history export is available via HaloPSA's reporting and API. Asset and configuration data can be exported via the HaloPSA API. Time entry records and contract data are exportable but may require transformation before import — the field structures differ from ClientSt0r's PSA module.
CSV import covers most common cases for teams migrating from spreadsheet-based tracking. Prepare your data with consistent column headers before importing — the wizard expects each CSV to represent one record type. A single spreadsheet containing mixed record types should be split before upload. Simple cleanup in a spreadsheet editor before import saves time on the mapping step.
Migrations that go wrong usually go wrong for the same reasons: data was not exported before subscriptions lapsed, records were imported in the wrong order breaking linkages, or staff were put on a new system before training was done. This checklist reflects the order that works.
Migration issues range from CSV formatting quirks to API authentication problems. Most have been seen before — check GitHub Issues before raising a new one.
Migration-related bugs, import errors, and data mapping questions are tracked in GitHub Issues. Search before opening a new issue — there is a good chance the problem has come up before.
Open an issue →The installation guide covers server requirements, database setup, and initial configuration. If ClientSt0r is not functioning correctly before migration starts, work through the install guide first.
Read the install guide →Platform-specific migration scripts and import helpers are welcome contributions. If you built a migration script for a platform not covered here, a pull request adding it to the repository benefits the whole community.
View the repository →