Moving in
If you already run a service desk, the question before anything else is what happens to what is in it.
The things that describe your school today come across automatically and stay current. Your history does not come across.
What arrives on its own
Section titled “What arrives on its own”None of this is an import. Each of these is a connector that keeps reading its source, so what you see in Plugboard stays right as the source changes.
| What | Comes from | Stays current |
|---|---|---|
| Devices | Your MDM: Jamf, Intune, Kandji, Mosyle, Chrome Enterprise | Yes, continuously |
| People | Your SIS or directory | Yes, continuously |
| Group and class membership | The same source | Yes |
| Warranty status | The vendor connector for that hardware | Yes, on lookup |
| Print balances and card numbers | PaperCut | Yes |
You do not build an asset register. Your MDM already is one, and Plugboard reads it. See how connectors work.
The order to connect them in is on the setup checklist: email, then the directory or SIS so people exist, then the MDM so devices resolve.
What you type in once
Section titled “What you type in once”Configuration, not data. It is an afternoon, and it is on the checklist:
- Repair types and their coverage, statuses and priorities. See workflow.
- The parts list and prices.
- Loan groups, which can point at an MDM smart group so the pool then maintains itself.
- Roles, before users. See roles and permissions.
- Your first knowledge base articles.
Induction rosters are the one bulk load that exists: they import from Google Sheets or an uploaded roster. See inductions.
Historical tickets do not migrate
Section titled “Historical tickets do not migrate”There is no importer for closed tickets, and there is no supported path that creates them.
This matters most if you are coming from Web Help Desk or Zendesk, which
both have connectors here. Those connectors keep the two systems in
step going forward: Web Help Desk exposes
ticket.create, ticket.get and ticket.close. None of it reaches backwards
into what the old system already holds.
The REST API is read-only, so it will not do it either. The MCP server can create submissions, but a submission created today is dated today, so history built that way carries the wrong dates.
What to do instead
Section titled “What to do instead”Keep the old system, read-only. Stop new work going into it on cutover day and leave it running where the people who need history can reach it. Most schools do this, and after a term it is rarely opened.
Carry the open work across by hand. What is still open on cutover day is usually a few dozen repairs in progress. Lodging those in Plugboard takes an afternoon and leaves you with a clean starting point.
Export before you decommission. Whatever the old system offers, take it and keep it somewhere durable. Do this while you still have a licence and somebody who remembers the admin password, not eighteen months later.
Do not run both as the system of record. Pick a cutover date, because two live queues cost more than either one on its own.
If you are replacing Web Help Desk but keeping it as the institutional record for
general requests, that is supported and is not a migration: switch
off module.tickets, let Plugboard own device work, and let submissions raise
Web Help Desk tickets. See running it alongside
Plugboard.
Moving from another Plugboard
Section titled “Moving from another Plugboard”This one is a full migration and nothing is lost: an export, a provision, an import and a DNS change, including between self-hosted and managed in either direction. See support, restores and exits.
Remember the identity provider. Redirect URIs are absolute, and a cutover that changes the hostname without changing them locks everyone out of SSO.
Getting your data out again
Section titled “Getting your data out again”Admin, Backups exports a portable copy of your institution at any time, without asking us. See backups in the app.