Onboarding & migration
You do not have to retype ten years of records
The reason good software does not get adopted is almost never the software. It is that nobody has four hundred hours to key in the equipment list. So we do the migration for you — as a scoped, contracted engagement with a deliverable you inspect before anything goes live.
Included with Enterprise / Campus plans; quoted as a fixed-scope engagement otherwise.
What you hand over
- An export, a database dump, or read-only access — in whatever shape it is in today
- A couple of hours from the people who know what the columns mean
- A decision on the judgement calls: what carries over, what starts clean
What you do not have to do
- Clean the spreadsheet first — we normalise it as part of the mapping
- Learn an import format, or fight a column mapper at 11pm
- Assign a student worker to six weeks of data entry
Where it comes from
We have not been handed a clean dataset yet
Nobody's operational history lives in one tidy place. It is spread across a shared drive, a board, a database, and someone's memory. That is the normal starting condition, not a reason to postpone.
Spreadsheets
The inventory workbook with eleven tabs, three colour conventions, and a column someone added in 2019 that nobody can explain. Excel and Google Sheets both fine.
Work-management tools
Monday, Asana, Trello, Notion, Airtable. Boards of maintenance tasks and equipment records that were never meant to be an asset register.
Homegrown databases
Access, FileMaker, a PHP app a graduate student wrote, a MySQL schema with no documentation. If we can get a dump or a read-only login, we can read it.
Existing facility software
A system you are leaving, or one that only covers part of the operation. We work from its export — CSV, XLSX, or an API if it has one.
Campus systems
Student information systems, identity providers, and card offices. Usually an ongoing sync rather than a one-time load — see the API for the live paths.
Paper and tribal knowledge
Binders of signed training forms, a laminated machine list, the whiteboard. We help you decide what is worth keying in and what should simply start fresh.
The engagement
Six steps, about four to six weeks
Timelines scale with how many sources there are, not how many rows. A single inventory workbook can be done in a week; a multi-building program with training history and card data takes longer. You get a fixed scope before it starts.
- 01 Week 1
Discovery
A working session with the people who actually maintain the data. We inventory every source, agree what must come across versus what is better rebuilt clean, and identify the matching keys — SKU, asset tag, email, campus person ID.
Your part
An hour or two of the right people, and read access to the sources.
- 02 Weeks 1–2
Mapping
We write the mapping from your columns to MakerOps records — including the messy parts: split names, inconsistent units, a location column holding building and room in one string, duplicate suppliers spelled four ways. You review the mapping before anything is loaded.
Your part
Answer the judgement calls only you can answer.
- 03 Weeks 2–3
Dry run into a staging workspace
Everything loads into a private workspace that is a real, working copy of the product — not a spreadsheet preview. You log in and look at your own data in the actual interface. Every row that failed validation comes back as an error report naming the row and the reason.
Your part
Click around and tell us what looks wrong.
- 04 Weeks 3–4
Reconcile and re-run
We fix the mapping and reload, as many times as it takes. Counts get reconciled against the source — item for item, machine for machine — so you can prove nothing was silently dropped. This is the step most migrations skip, and it is why they go wrong.
Your part
Sign off on the counts.
- 05 Cutover day
Cutover
A final delta load picks up everything that changed while you were reviewing, and the staging workspace becomes production. We schedule it around your calendar — between semesters, over a break, whenever the floor is quiet.
Your part
Pick the date, and stop editing the old system.
- 06 Weeks 1–4 after
Landing
We stay on for the first month. Staff training sessions, mapping fixes for things nobody noticed until real use, and a documented record of exactly what was migrated and how — so the answer to "where did this come from?" outlives everyone involved.
Your part
Tell us what is not working.
Scope
What actually moves
Inventory has a self-serve importer in the product — a guided wizard with column mapping, validation, a preview, and a downloadable error report — so a workspace admin can load items without us. Everything else in the list comes across as part of the engagement, loaded through the same validated paths the product uses internally.
Where a category is better served by a live connection than a one-time load — campus identity, card numbers, student rosters — we set up the sync instead of importing a snapshot that goes stale the following week.
Bulk loading it yourself
If you have engineering capacity and would rather drive it, the public API writes every resource in this list. Some institutions migrate themselves and only contract us for the mapping review and the cutover.
See the API referenceData category
How
- Inventory items & stock levels Self-serve or assisted
- Suppliers & part numbers Assisted
- Equipment & asset tags Assisted
- Equipment types & fleets Assisted
- Rooms, areas & locations Assisted
- Maintenance schedules Assisted
- Open & historical tasks Assisted
- Members, staff & roles Assisted or SSO sync
- Groups & cohorts Assisted
- Training records & credentials Assisted
- Purchase history Assisted
- Badge / card numbers Assisted or card-office sync
How we work
The rules we hold ourselves to
A bad migration is not one that takes a while. It is one where nobody can tell you what happened to the missing rows.
Nothing is loaded you have not seen
Every load is a dry run first, into a workspace you can log into. There is no step where data appears in production without you having looked at it.
Counts get reconciled, not estimated
Source count in, loaded count out, failures itemised by row and reason. If 4,102 items went in and 4,097 came out, you get the five rows and why.
Provenance survives
Imported records carry an audit trail naming the import job that created them. Two years later it is still answerable where a record came from.
Your old system stays running
Until you sign off on cutover, nothing is decommissioned and nothing is deleted. A migration you cannot back out of is not a migration, it is a gamble.
Questions we always get
What does it cost?
It is quoted as a fixed-scope engagement after discovery, so you know the number before you commit — no hourly meter. Enterprise / Campus plans include migration; Starter and Professional customers can add it. Institutions can put it on the same purchase order as the subscription.
Can we run both systems in parallel for a while?
Yes, and we usually recommend it for a few weeks. The old system stays authoritative until you sign off; the final delta load at cutover picks up whatever changed in the meantime.
What happens to data we decide not to migrate?
It stays where it is. Part of discovery is deciding, deliberately, what is worth carrying forward — ten years of completed one-off tasks usually is not. We would rather you start with a clean, trustworthy dataset than a complete but unusable one.
Who owns the data once it is in?
You do. It is exportable to CSV and Excel from the interface at any time, and the API reads everything. There is no version of this where leaving is hard because your records are trapped.
Is student data handled appropriately?
Migration work runs under the same data-privacy terms as the subscription, with FERPA-aligned handling for student records. Where campus policy requires it, identity data stays in a live SSO sync rather than being copied at all.
Tell us what your data lives in
Bring the messiest export you have to a 30-minute call. We will tell you honestly what migrates cleanly, what needs judgement calls, and roughly how long it takes.