Moving your library to ToyHive

Moving a toy library that already exists — with members, balances, loan history and a shelf full of toys — onto ToyHive. If you are starting a library from scratch, you don't need this guide.

The short version: nothing about the move is one-way until you decide it is. You keep running your old system day to day for as long as you like, and you re-run the import right before you open on ToyHive to catch everything that happened in between.

What the whole move looks like

Get your export — Install the ToyHive exporter in your browser, then run a Full export from your old system with redaction turned off. You get a .zip file.
Create your library and upload the .zip — Members, households, memberships, loan history, payments, toys, piece lists, team members and roster history all come across. Photos and documents upload separately, from your browser, while the page is open.
Check what needed a hand — The import tells you what it could not place: skipped loans, team roles with no ToyHive equivalent, and imported membership plans, which all arrive set up for families. Check the outstanding-balance total against your old system.
Set the rest up, at your own pace — Payments, opening hours, branding and your public page are in the setup wizard. Matching your toys to the shared catalogue can be worked in sittings — every toy lends, counts and prints labels whether it is matched or not.
Cut over when you are ready — Keep lending and taking payments in your old system until then. Right before you go live, import a fresh export: members, loans and balances catch up, and the toy work you have done here is kept. Toys added over there arrive too — but EDITS to a toy already imported do not, so make those here.

Which route is yours

SeTLS or MiBase — self-service. A browser extension pulls a full export out of your admin, and you upload it here. Most libraries are done with the import itself in a few minutes.

Anything else — another digital system, spreadsheets, or paper ledgers — we do it for you by hand. Get in touch, send us whatever you have, and we'll quote the work; the free paths are SeTLS, MiBase, and starting empty. There is no self-service path for these, and you should not try to retype your library into ToyHive by hand.

Step 1 — the export

Install the ToyHive exporter extension in your browser, sign in to your old system's admin as you normally would, and run a Full export with redaction turned off. Redaction strips exactly the details — names, emails, balances — that the import needs.

You end up with a .zip. Don't unzip it; upload it as it is.

Can't install a browser extension? Get in touch — we'll do the migration by hand instead.

Step 2 — create the library and import

You only need a couple of details and your agreements to create the library; the import fills in the rest. If you don't have the export yet, create the library now and run the import later from Settings → Import from SeTLS/MiBase — it stays available until you go live.

What comes across:

People — households, adults and children, with their contact details: email, phone, and the household's address, suburb and postcode (on the main adult). Where an adult had both a mobile and a different home number, the mobile is kept — ToyHive holds one phone per adult — and the completion screen counts the home numbers left behind. A child your old system recorded without a name comes across as Child (name not recorded), with their birth month and sex, for you to name. "How did you hear about us?" comes across where your old system asked it. The staff notes you kept about each family (SeTLS member alerts, MiBase member notes and member alerts) land in the household's Notes, which also show at the loan desk — ToyHive has no pop-up for them, so they sit on screen rather than demanding a click. Each member's roster type ("Saturday mornings", "Term time only") is kept separately, on the household's Volunteering & waivers tab, and becomes their availability as soon as they are a volunteer here — straight away for your existing team, and later for anyone you approve.
Working With Children Checks — a member's WWCC number comes across as a volunteer credential, marked unsighted: ToyHive has not checked it, so sight the card (or look it up on your state's checker), record its expiry and mark it verified before rostering on it. The state is taken from your library's address. For your existing team it is on their record straight away; for everyone else it waits on the household's People tab and moves onto their record the day they become a volunteer
Account status — a suspended, resigned or lapsed member arrives with a first line in their account history saying what your old system called it (and since when, where it recorded a date), so the desk can see why. Nobody is emailed about it. A member who simply didn't renew stays an active household — their membership shows as expired, and renewing it is all it takes
Memberships — who is on what, when it expires, and the membership types themselves. A member your old system marked as holding a healthcare card arrives with their current membership marked as a concession (the card number itself is never stored)
Money — transactions and each member's outstanding balance
Loans — current loans and your loan history
Toys — the toys themselves and their piece lists
Waivers — signed waivers and agreements, shown on the household as imported from SeTLS/MiBase. One your old system marked signed but never dated is dated from the day the household joined, and the completion screen says how many
Your team — team members, plus roster sessions, shifts attended and no-shows
Settings and branding

What deliberately does not come across. ToyHive does not store disability, health or medical information, ethnicity or cultural background, languages spoken, religion, or identity-document numbers (driver's licence, proof of ID, concession card number) — nor notes about children, which is where allergies and diagnoses tend to be written. If your export has any of these, they are left behind rather than copied into notes or anywhere else, and both the import report and the completion screen say how many values that was.

Photos and documents are different. They upload from your browser while the import page is open — photos in small batches, documents one at a time — so leave the tab open until the counter finishes. If some fail, or you reload the page part-way, choose the same .zip again on that page: it re-sends only the missing photos and documents and touches nothing else.

Before that, two waits. Your export is uploaded in parts (a large library is 20–30 of them, several minutes on home wifi — keep the tab open), and then we read it through before showing you anything. Nothing is changed during either. If that read fails, the page asks you to upload the export again rather than offering a retry — there is nothing to retry, because nothing was written.

Plan about an hour for the whole thing. A library with a few thousand toys takes 30–60 minutes to export out of your old system, and produces a file of 100 MB or more. Leave the laptop awake.

Former members. Your old system keeps the name on every loan long after it deletes the member record, so an import brings across people it no longer has a record of — at one library, 936 of them against 268 current members. They arrive with their loans and nothing else, so the toys keep a complete history, and the members list hides them by default. Search for one and the page will tell you it is hiding them and offer to show them. Two things follow: your member count is the living membership, not the total; and your platform bill, which counts borrowing rather than membership, may include a few of them if they borrowed in the last twelve months. If a former member comes back and starts a membership (enrolled at the desk, or renewing in the portal), they show up as an ordinary member again. Until then their household page carries a Former borrower — imported from loan history label. If one is back without a new membership — or the import misread them — anyone who can edit members can choose List as a member again beside that label; it is recorded in the activity log.

Shared sign-in emails. Old systems often have two member records with the same email, for example a grandparent on two family accounts. An email can sign in for only one member, so the import links it to the first record and lists the rest on the completion screen. To give one of those members their own login, put a different email on their adult (People tab) and press Invite to the member portal.

Step 3 — check what needed a hand

The import is honest about what it could not place, and all of it is on the completion screen. Five things are worth a look every time:

The outstanding balance total. The import shows the total outstanding across everyone it brought in. Check it against the same total in your old system — if those two numbers match, the money came across.

Membership plans arrive set up for families. That is right for almost all of them. If one of your plans was the childcare or organisation rate, open Settings → Membership types, press Edit next to it and tick Organisation membership.

Team roles that couldn't be mapped. Anyone whose access level had no ToyHive equivalent — or who has no email on file to sign in with — is listed by name. Give them a role from Settings → Team if they still need staff access.

Skipped loans. A loan is skipped when it points at a toy that was already deleted, has a due date we can't read, or has no membership covering it. The count is on the completion screen.

Contact details we couldn't use. A member's details are held to the same rules as the forms in ToyHive. An email that isn't an address ("n/a", "none") or a phone longer than 50 characters comes across empty rather than as-is, an over-long name or address is cut short, and an adult with no first name keeps their place without one. Each is listed by member on the completion screen — saying what was wrong, not repeating the value — so you can look the member up in your old system and re-enter what was meant.

Work through this list within a month. Your uploaded export is deleted as soon as the import finishes (or 14 days after an attempt that never finished), and the detailed warnings on the completion screen are cleared 30 days after the import, leaving only the counts. Copy or fix anything flagged before then.

Step 4 — set the rest up

Continue setting up your library opens the setup wizard: taking payments, opening hours, branding and your public page. None of it is needed for the import to have worked; it's what you need before members can see you.

The other post-import job is matching your toys to the shared catalogue. Toys brought in by an import start as library-only records — yours alone, and fully usable. Matching them to shared catalogue entries is what earns you other libraries' photos, descriptions and piece lists, and one hold queue across your copies.

It is not a job that has to be finished before you open. Every toy lends, counts and prints labels whether it is matched or not, so work the queue in sittings. Match toys to the catalogue under Inventory suggests entries for each toy, offers to link the near-certain ones in one go, and puts your record beside the catalogue's — every field, plus exactly what linking would change — before you decide. Some suggestions carry a note saying how many other libraries linked the same toy name to that record (or ruled it out) — a plain count that helps you trust or distrust a suggestion; no library is named, and nothing about your own decisions is shown to anyone else. After a review pass has been run on your queue, a suggestion may also carry a one-line review note ("same product", "edition variant", "different") with the reason — it reorders and explains, and never links anything for you. See Library-only and shared-catalogue toys for what the two states mean and what linking does.

Step 5 — the cutover

This is the step libraries most often don't know about, and it is the one that makes the whole move safe.

Keep taking loans and payments in your old system for as long as you need. When you are ready to go live on ToyHive, run a fresh export and import it again from the same page. Anything borrowed, returned or paid in the old system since your first import is brought up to date, members and memberships already imported are left as they are (so a renewal, waiver or T&C acceptance recorded over there since then does not follow — the completion screen counts them, so you can record them here), and the toy work you have done here is kept — catalogue links, edits, photos, tags and all.

One thing to know before you settle in: toy edits are the exception. The re-import matches toys on their identifier, and a toy it has already imported is left exactly as it stands here — so a new toy you add in your old system comes across on the re-import, but a change to a toy already imported does not. Rename a toy, fix its age range or correct its pieces over there and that work will not follow.

So: edit toys here from the first import onwards. Adding them on either side is fine. If a lot has already been edited on the other side, get in touch — starting the import over on an empty library is cleaner than reconciling by hand, and we will clear the imported data for you.

With that one rule, there is no rush between the first import and going live, and no penalty for taking weeks over it.

Going live is the button under Settings → Billing. That is the handover: ToyHive becomes the system of record, and imports close for good — so run your final export and import before you press it, not after.

If something went wrong

Re-running the import with the same .zip is safe: members and toys that were already imported are skipped whole rather than duplicated.

If you imported the wrong data entirely — the wrong library's export, say — the clean fix is to delete the library under Settings → Danger zone and create a fresh one, then import again.

And at any point, for any reason: get in touch. We migrate libraries by hand for free, and would much rather do that than have you stuck.