Skip to main content

Importing assets and people

Tagaris imports your existing records rather than asking you to retype them. Coming from Snipe-IT or GLPI, the whole register comes across through the old system's API. Otherwise assets come in from a CSV file, with source presets that recognise Snipe-IT and Halo exports and translate their status values. People come in from a CSV file or, still in testing, directly from Microsoft Entra ID. Every import runs through a preview (a dry run), so nothing is written until you confirm, and the preview shows exactly what will happen. All of it is free on every plan.

The asset importer is a four-step wizard: upload, map columns, preview, then commit. Find it at Assets, then Import.

How it works​

  • The first row of the file must be a header row.
  • You map each Tagaris field to a column in your file. The wizard guesses the mapping from the header names; adjust anything it gets wrong. Only "Name" is required.
  • Categories, locations and people referenced by name are created automatically if they do not already exist.
  • Duplicate serial numbers and MAC addresses are flagged as warnings, not errors, so the row still imports. Rows with real problems (a missing name, a tag already in use, an unreadable date) are reported and skipped.
  • The limit is 5000 rows per file. Split a larger export into several files.

Dates are read as YYYY-MM-DD or DD/MM/YYYY. Prices are a plain number.

Migrating from another system​

Coming from Snipe-IT or GLPI, the migration page reads the old system directly and brings the whole register across; the two sections below cover it. From anything else, or when the two servers cannot reach each other, use a CSV export: choose the system from the Source list in the CSV importer, which then recognises its column names and translates its status values into ours. You can still adjust the mapping by hand, so a preset only needs to get most of the way there.

Snipe-IT, the whole register through its API​

The quickest way over from Snipe-IT is the migration page: Assets, Import, then "Migrate the whole register through its API". It reads your Snipe-IT directly, so there are no files to export, and it brings across far more than the asset CSV can. It is free on every plan and needs an administrator.

  1. In Snipe-IT, open your account menu, choose Manage API keys and create a token. Use an account that can view everything you want to bring across.
  2. In Tagaris, enter your Snipe-IT address (the one you open it on) and the token, then choose Read and preview. The token is used for that read only. It is not stored.
  3. Check the preview: one line per record type, with how many are in Snipe-IT, how many would be created and how many are already here.
  4. Choose Migrate now. It all lands in one go, or not at all if something fails.

What comes across:

  • Assets, with their tag, name, serial, model, manufacturer, supplier, category, purchase date and cost, notes, MAC address and last audit date. Asset tags are kept exactly as they are, so the labels already on your kit stay right.
  • Warranty end dates, worked out from the purchase date and Snipe-IT's warranty months.
  • Who has each asset and where it is. Checked out to a user becomes assigned to that person; checked out to a location, or not checked out, becomes that location.
  • The location tree, users as people (name and email), and asset categories.
  • Status. Deployed becomes In use, Ready to Deploy and Pending become In storage, undeployable labels become Repair, and Archived, Lost/Stolen and Broken become Retired. Labels that say more than that (Out for Repair, Out for Diagnostics and your own) are created as Tagaris status labels and kept on the asset.
  • Custom fields that hold at least one value, with dropdown options. A MAC address field goes into the asset's own MAC address.
  • Accessories, components and consumables at the quantity on hand, software licences (name, seats, expiry and cost) and maintenance records.

What does not:

  • The activity history, images and uploaded files.
  • User logins, passwords and permissions. People are records to assign kit to; invite colleagues as users separately.
  • Licence product keys, and who holds checked-out accessories or licence seats.
  • An asset checked out to another asset. Tagaris has no asset to asset checkout, so it keeps its location and gets a line in its notes saying what it was attached to.
  • Encrypted custom field values that Snipe-IT hides from the API.

Running it twice is safe. Records are matched on what identifies them (asset tag, a person's email or name, a location's place in the tree, a name for everything else) and anything already here is left alone. So you can migrate, tidy up in Snipe-IT and run it again for what is new.

What can go wrong:

  • "Snipe-IT could not be reached": the Tagaris server has to be able to reach your Snipe-IT over the network. From a Docker container, localhost means the container, so use the server's name or IP address.
  • "Snipe-IT rejected the API token": create a new token and paste it again.
  • A record type is reported as not readable: the token's user lacks permission to view it in Snipe-IT. Everything else still comes across.

GLPI, the whole register through its API​

The same migration page reads GLPI: choose GLPI under "Migrating from". It uses GLPI's REST API (apirest.php), which is switched off on a new GLPI.

  1. In GLPI, open Setup, General, API and turn on Enable Rest API.
  2. On the same page, open the API client (GLPI ships with one called "full access from localhost"). It only accepts requests from the address range it lists, so either set the range to include the address Tagaris connects from, or clear it. If the client has an app token, copy it.
  3. Open your own user's preferences and, under Remote access keys, generate an API token. Use an account whose profile can read everything you want to bring across.
  4. In Tagaris, enter your GLPI address, the API token and the app token if there is one, then choose Read and preview. Neither token is stored.

What comes across:

  • Computers, monitors, network equipment, peripherals, phones and printers. Items in the bin and templates are skipped.
  • GLPI's inventory number becomes the asset tag. An item with no inventory number gets a tag made from its GLPI id (for example GLPI-PC-42). The made-up tag is the same every time, so running the migration again still matches.
  • Category. The item's own type (Laptop, Server, Switch) when it has one, otherwise the kind of item (Computer, Monitor and so on).
  • Name, serial, manufacturer, model, comment as notes, and the first usable MAC address from the item's network ports.
  • The user of the item as the assigned person, and its location. GLPI keeps both, and so does Tagaris.
  • Purchase date, value, supplier and warranty end, from the item's financial information. The warranty runs from the warranty start date if one is set, otherwise from the purchase date.
  • The location tree, and users as people with their default email address. GLPI's built-in accounts (glpi, tech, normal, post-only and the system account) are skipped unless you have given them a real name.
  • Statuses. A GLPI status is only a name, so Tagaris reads what it means from the name, in English or French ("En réparation" becomes Repair, "Au rebut" becomes Retired). A name that does not say ("On loan") follows what most items with that status are doing: in use if most have a user, in storage if not. Statuses that say more than In use, In storage, Repair or Retired are kept as Tagaris status labels.
  • Consumables and cartridges, at the number of unused units, with GLPI's alert threshold as the minimum quantity.
  • Software licences, named after their software, with seats, expiry and value.

What does not: tickets, contracts, documents, software installations, components inside a computer, licence serial numbers, user logins and profiles. If your GLPI has several entities, everything the token's user can see arrives in the one Tagaris organisation you are signed in to.

What can go wrong:

  • "The GLPI REST API is switched off": step 1.
  • "GLPI refused this server's IP address": step 2. From Docker, the address GLPI sees is the Docker host's, not the container's.
  • "GLPI rejected the API token": regenerate it in your user preferences and paste it again. A token is shown once.
  • A kind of item is reported as not readable: the token's profile cannot read it in GLPI. Everything else still comes across.

Tested against GLPI 11.0. The REST API is the same one GLPI 9.5 and 10 use.

Snipe-IT, from a CSV export​

If the two servers cannot reach each other, export your assets from Snipe-IT to CSV, then choose "Snipe-IT" as the source in the CSV importer.

  • Common columns (Asset Tag, Name, Serial, Model name, Category, Manufacturer, Supplier, Status, Location, Purchase Cost, Purchase Date, Checked Out To, Notes) are mapped automatically.
  • Statuses are translated: Deployed becomes In use, Ready to Deploy and Pending become In storage, Out for Repair and Out for Diagnostics become Repair, and Archived and Lost/Stolen become Retired.
  • Snipe-IT's warranty is a length in months, not an end date, so it is not imported. Set warranty end dates afterwards if you need them.
  • "Checked Out To" is imported as the assignee. People are created by name.

Snipe-IT users, licences, accessories, components and consumables are separate records and are not part of the asset CSV. The API migration above brings them across; with a CSV, import people with the People importer (People, then Import) and enter stock and licences in Tagaris directly.

For a concept-by-concept map of what carries over (statuses, stock, custom fields, warranty dates), see Switching from Snipe-IT on the website.

Halo​

Export your assets from HaloITSM or HaloPSA to CSV, then choose "Halo" as the source. Halo's asset field names are configurable, so check the mapping and set any column the wizard did not recognise. Common statuses (Active, In Stock, Spare, Faulty, Decommissioned, Scrapped) are translated.

People​

Import people (asset assignees) from People, then Import. Two sources:

  • CSV: upload or paste a file. It needs a name column, or separate first name and last name columns, and an optional email column. Common header names from Snipe-IT and Halo user exports are recognised. People are matched to existing ones by email, so re-running only adds new people.
  • Microsoft Entra: an administrator can pull people straight from Entra ID. This reuses the same Entra app you set up for Microsoft 365 email or single sign-on, so there is nothing new to register beyond granting the app the User.Read.All application permission with admin consent. Enabled users with a name are imported; disabled accounts are skipped. As with a CSV, people are matched by email, so pulling again only adds new starters. Nothing is written to the directory, and nothing is saved until you confirm the preview. The Entra pull is free and open, and still in testing across real tenants; tell beta@tagaris.co.uk how it behaves on yours.

Round-trip​

An asset CSV exported from Tagaris (from the assets list) re-imports with the generic source: the column names already match. This is a simple way to move assets between organisations or instances. For a full copy of everything, use a backup (see Backups and restore) or the full organisation export in Settings, Organisation, Data.