Moving client documentation is mostly not a technical problem. It is deciding what is still true, who owns each part of it, and how to switch over without a week where nobody knows which system to trust. This is the checklist I would work through, whichever platform you are moving to.
1. Inventory what you have
- List every place documentation lives today: the documentation platform, the PSA, shared drives, wikis, spreadsheets, password managers, and individual technicians’ notes.
- For each, count roughly what it holds: organisations, assets or configurations, passwords, documents, contacts, locations, network records.
- Note what is linked to what. Links are the part a migration most often loses.
- Find the owner of each source, and who can export from it.
2. Decide what moves
- Archive, rather than migrate, anything nobody has opened in a year. Keep the export; do not carry it into the new system.
- Retire stale credentials before moving them. A migration is the cheapest moment to rotate.
- Agree a structure first — one organisation per client, how sites and parent companies are represented — so imported records land somewhere sensible.
3. Map each source to how it will arrive
If the destination is clientst0r, this is what its import tooling covers today, read from its code:
| Source | How | Brings across |
|---|---|---|
| IT Glue | Importer using the IT Glue API | Organisations, configurations as assets, passwords, documents. Contacts, locations and networks are not implemented yet. |
| Hudu | Importer using the Hudu API | Companies, assets, passwords, documents. Contacts, locations and networks are not implemented yet. |
| Spreadsheets | CSV or XLSX with a column mapper and a preview | Assets, passwords, contacts and documents, mapped column by column. |
| Bitwarden or Vaultwarden | JSON export into the vault | Vault entries. |
| MagicPlan | Floor-plan import | Floor plans. |
Anything else — another documentation platform, a wiki, a different password manager — has no importer. Export it to CSV and use the mapper, or move it by hand. Plan the hand-work explicitly: it is usually the contacts, locations and network records, plus the links between records.
4. Run a trial import first
- Install a throwaway instance, not the one you will keep.
- Import one real client end to end.
- Compare counts with the source, then open ten records at random and check them field by field.
- Check the links survived: is each password still attached to the right asset or organisation?
- Write down every manual fix, so the real run is a procedure and not a memory.
5. Handle credentials as the riskiest data
- Treat every export file as plaintext secrets. Keep it on an encrypted disk, and delete it securely when the import is verified.
- Use a read-only API key for the source where it allows one, and revoke it when you are done.
- Back up the destination’s encryption key (clientst0r’s
APP_MASTER_KEY) before the first real import, not after. - Rotate anything that was ever shared in chat or email while you are at it.
6. Cut over on a date
- Freeze edits in the old system on a set day; import; verify.
- Keep the old system read-only for an agreed period, then export it one last time and close it.
- Update runbooks, PSA links and bookmarks to point at the new records.
- Tell technicians where things now live, and collect what they cannot find in the first week.