Importing spreadsheet asset registers into GLPI: what the move involves
If you have an asset register, a user list, a supplier list and a contract log kept in spreadsheets, the work of moving them into a new GLPI instance is mostly data preparation, mapping and ordered loading, not software installation. The Data Injection plugin is the route GLPI documents for bringing this kind of tabular data in, using import models that map spreadsheet columns to GLPI fields. It is a practical loading tool, though, and it is not the same thing as a full migration project. A migration project also settles which records are authoritative, who owns them after cutover, how identifiers carry over, and how the old registers are retired.
The effort is driven less by the number of rows than by two factors. The first is data quality: duplicate asset tags, inconsistent location or model names, users without a stable login, and contracts whose supplier cell does not match any supplier record will each stop or distort an import. The second is the number of linked record types. Users, locations, manufacturers, suppliers and contracts must exist before the assets and contracts that reference them can load cleanly, so every additional linked type adds a dependency to sequence and test. Ask any partner to inventory the registers, count the distinct record types and flag the fields that have no clean target in GLPI before agreeing on a fixed scope.
Plan for a staging instance built from the same GLPI version and plugin set as production, and treat the first full load there as a rehearsal you can repeat. Confirm the Data Injection plugin's current compatibility with the GLPI version you will run before you commit to a schedule, because plugin support follows GLPI releases and the GLPI plugin documentation is the place to check. Agree in writing who cleans the source spreadsheets, who signs off the mapping, and who validates counts and sample records after each load.
Which spreadsheet data maps cleanly to GLPI and which does not
This table compares common register fields against GLPI item types, linked records and dropdowns, so you can see which columns import directly and which need a lookup, a value match or a different approach. Read each row before building an import model, because the work is usually in the linked records and the dropdown values rather than in the column itself. The main takeaway is that custom asset definitions and non-standard fields sit outside what the import plugin can be relied on to handle, so confirm model support in your GLPI version first.
| Register field | Maps to in GLPI | What to prepare | Where it breaks |
|---|---|---|---|
| Asset name | Name on the asset item type (for example, computer or monitor) | One unique name per row, trimmed of stray spaces | Duplicate names in the sheet create ambiguous updates on re-run |
| Serial number | Serial field on standard asset item types | Consistent format, no merged cells or scientific notation from spreadsheet software | Serials stored as numbers lose leading zeros |
| Model | Link to a model record (for example, computer model) | Models created first so each value matches an existing record | Free text that does not match a model name creates unintended records or fails the row |
| Location | Link to a location record in the entity tree | Full location path agreed and loaded before assets | Locations that differ only in spelling or case are treated as separate values |
| Owner or assigned user | Link to an existing user record | User import completed first, login names matched exactly | Emails or names that differ from the user record leave the owner blank |
| User name and email | Login, email and profile fields on the user item type | Unique logins, valid email format, profile and entity decided in advance | Users with the same login collide, and passwords or authentication source need a separate decision |
| Supplier | Link to a supplier record | Supplier list deduplicated before loading contracts and assets | Supplier names with variants create duplicate supplier records |
| Contract dates and cost | Dates and cost fields on the contract item type, linked to suppliers and assets | Date format fixed (for example, ISO 8601), currency and cost stated in one format | Locale-specific date formats and decimal separators can shift values silently |
| Department or cost centre | Usually a dropdown or group value, not a native link on every item type | Dropdown values listed and matched exactly | Values absent from the dropdown are rejected or need new dropdown entries first |
| Custom asset type or extra columns | Outside standard item types unless the model explicitly supports them | Confirm support for the exact item type in your GLPI version before planning columns | Custom definitions and non-standard fields are the most likely to need manual entry or a custom build |
Documented import paths for spreadsheet data
GLPI offers more than one documented way to bring spreadsheet data into a new instance, and each suits a different shape of data. The cards below cover the Data Injection plugin, native import and export, and the API, with the limits to check before any route is chosen. Confirm plugin compatibility with your exact GLPI version first, because plugin support is tied to releases.
Data Injection plugin import models
The Data Injection plugin reads CSV or spreadsheet files and maps their columns to GLPI fields through a saved import model. It suits repeatable loads of assets, users, suppliers and contracts, where the same column layout is reused across waves. Build the model on staging first, and confirm the plugin has a release for your GLPI version before you design the workflow around it. Plugin updates are a separate change from core upgrades, so record which versions were tested together.
Column mapping and linked record order
Assets reference users, locations, suppliers and contracts, so those referenced records must exist before the rows that point to them are loaded. Plan the import sequence as suppliers, then locations and users, then contracts, then assets, and verify that each lookup column matches an existing name or identifier exactly. Duplicate names in a register are a common cause of wrong links, so resolve them in the spreadsheet before loading.
GLPI native import and export
Native import and export features cover some object types and are useful for checking what the instance holds and for small corrections. Use exports from the source system or from staging as a control: compare row counts and key fields after each load. Do not assume native features cover every field or custom type, so test each object class you need against a sample file.
GLPI API for custom scripts
The GLPI REST API suits cases the plugin cannot handle, such as transforming source data, reconciling against another system, or loading records on a schedule. Scripts give full control over error handling and logging, but they also become code your team must maintain across upgrades. Use a dedicated API client with least-privilege rights, and confirm the API endpoints you depend on still exist in your target version.
Limits with custom asset definitions
Imports built on standard asset types do not automatically cover custom asset definitions or fields added to them. Before building a model, list every custom field the register needs and check whether the chosen route can write to it. Where it cannot, the gap must be closed by script, by a configuration change, or by changing the target design. Treat this as a scoping item, since it changes effort more than any other factor.
Testing and rollback on staging
Every import route should be proven on a copy of the target instance before production use. Load a representative sample, check linked records, counts and encoding for accented names, and keep the source files unchanged so a run can be repeated. Ask your implementation partner or internal team to document the exact plugin and GLPI versions used in the test, since the same model can behave differently after an upgrade.
How Data Injection models map columns to GLPI fields
A Data Injection *model* is the saved definition that tells GLPI which item type a spreadsheet feeds (computers, monitors, users, suppliers, contracts and so on) and how each column maps to a field on that item. Build one model per record type, and treat the column mapping as the artifact that matters most. Before you map anything, normalize the spreadsheet: trim whitespace, use one header row with stable names, and agree on value formats for dates, yes and no flags, and status values. Mapping a header such as "Purchase date" in one file and "PurchaseDate" in another forces you to rebuild the model each time, and inconsistent date formats are a common cause of rejected or silently wrong rows. Check the exact field names and accepted values in the Data Injection documentation for your installed plugin version, since the plugin is maintained separately from the GLPI core and its options can differ between releases.
Most asset rows reference other records: a location, a manufacturer, a model, a status or an assigned user. Data Injection resolves these by matching the text in the spreadsheet against existing GLPI records, so the referenced names must already exist and match exactly, including case and spelling. Decide per lookup field whether a missing value should create a new dictionary entry or fail the row, and keep that behavior consistent across the file set. For assigned users, the match usually depends on login name or an external identifier, so confirm which key your user records carry before you write the model. A spreadsheet that uses display names where GLPI expects logins will load without errors and still leave assets unassigned, which is why a dry run on staging with a sample of real rows matters.
Store each model definition and its sample file under version control, alongside a short note on the GLPI and plugin versions it was tested against. When the register changes, the change lands as a reviewed diff to the mapping rather than as an undocumented edit in the web interface. Keep the models in the same repository as your import checklist so that a later migration, or a second team member, can rerun the same import with the same results. Confirm with your own environment whether your GLPI version and plugin release allow you to export or import model definitions in a form you can commit, because that capability and its file format are not something this page can assume.
How to sequence the import, parallel run and cutover
The sequence moves spreadsheet data into GLPI in dependency order, proves each load against the source with reconciliation counts, and retires the old register only after the team has worked from GLPI for a period. Each phase ends with a written sign-off so no one is guessing which system is current.
Inventory source registers and their owners
List every spreadsheet, export or side register that holds assets, users, suppliers or contracts, and name the person who maintains each one. Record which file is treated as the master for each data type, along with the columns, row counts and known gaps. Owners confirm the list in writing. The step is done when every data type has one named source and one named owner, and nothing is left in an untracked file on a laptop.
Clean and deduplicate source data
Work through each register to remove duplicate asset tags, merge repeated supplier names, standardize user identifiers and resolve contract numbers that appear more than once. Decide the matching key for each object type before anyone edits rows, such as serial number for assets or login name for users. Owners approve each cleaned file. The step closes when the source files pass a duplicate check on their keys and the open questions are logged with an owner and a decision.
Build and review import models
Create one Data Injection model per object type in the staging instance, mapping each spreadsheet column to a GLPI field and marking which fields are mandatory. Record the mapping in a shared document so reviewers can check it against the source headers. Enumerated values, such as status or type, are matched to existing GLPI dropdowns or agreed additions. The step is done when a reviewer has walked each model against a sample of rows and signed off the mapping.
Load entities, locations, suppliers and contracts first
Import the foundation records in order: entities and locations, then suppliers, then contracts that reference those suppliers. Users, assets and anything else that points to these records depend on them, so they come later. Run each load on staging and check that the referenced objects were created or matched rather than duplicated. The step is done when the foundation counts match the cleaned source and no contract is left without a linked supplier.
Load users, then assets, on staging
Import users next so that asset ownership, location and group fields can resolve, then import assets and link them to the users, locations and contracts loaded earlier. Confirm how existing accounts from directory authentication are matched to imported records, so a later sign-in does not create a second identity. Review any rows that failed to resolve a link and fix the source or the model, then reload. The step is done when linked fields resolve for every row that should have a link.
Reconcile staging loads against the source
Repeat the full load sequence on a fresh staging copy and compare GLPI record counts per object type with the cleaned source counts. Spot-check a defined sample of assets, contracts and users field by field, and keep the list of exceptions with the reason for each. Agree the acceptance criteria with the register owners before the first production load. The step is done when a repeated load produces the same counts and every exception has a documented decision.
Run the parallel period with the spreadsheet authoritative
Load the production instance using the tested sequence, then keep the spreadsheet as the record of truth while the team checks GLPI against it. Changes made in the spreadsheet are re-imported or corrected in GLPI, and the team logs each discrepancy by type. The length of this period is set by the owners in the written plan, and it ends only when the discrepancy log stays clear for the agreed window. The step is done when the owners sign off that GLPI matches the register.
Cut over and archive the old register
Freeze the spreadsheet, run a final delta import or manual correction for any changes made since the last load, and reconcile counts one more time. Announce the date that GLPI becomes the single source, and make the spreadsheet read-only with a copy stored under the retention rules your organization already applies. The step is done when the final reconciliation is signed, the archived file location is recorded, and the team has been told where to record changes from now on.
Where spreadsheet import stops for custom asset definitions
Core GLPI item types such as computers, monitors, printers, network equipment, software, users, suppliers, groups and contracts are the most predictable part of a spreadsheet load. The Data Injection plugin builds import models around these types, and their fields map to columns that most asset registers already contain, such as name, serial number, location, status and owner. Confirm the exact list of supported item types against the Data Injection documentation for your GLPI version before you commit to a column layout, because model availability and field coverage can change between releases.
- Built-in fields: Map columns to fields that exist on the item type, including name, serial, model, manufacturer and location.
- Dropdown values: Locations, manufacturers and states are looked up by name, so spelling differences in the source file can create duplicates.
- Reference fields: Owners and groups must already exist in GLPI, or the import needs a preceding step that creates them.
- Test representative rows: Load a sample from each item type on staging before the full register.
Before planning, list every item type in your register and confirm each one has a supported model in your version.
Organizations often track assets that GLPI does not model by default, such as badges, licenses with custom attributes, medical devices or lab equipment. Where these need custom asset definitions or custom fields, the Data Injection plugin may not map them without extra work. Treat each custom type as a separate modelling decision: decide whether the data belongs in a custom definition, an existing type with a dropdown, or a custom field, and then check whether the plugin can target it. Some cases will need a scripted transform or a direct database load, and those carry their own testing and rollback requirements.
- Field inventory: List every column that has no matching GLPI field and assign each one a target.
- Model support: Confirm whether the plugin can import into your custom definition in your GLPI version.
- Scripted loads: A custom transform changes the cost and the review effort, and it must be repeatable.
- Upgrade impact: Custom definitions can need rework when GLPI or plugins are upgraded.
Ask the team that maintains your GLPI configuration to confirm, in writing, which custom definitions are supported for import before you agree the scope.
Many records in a register point to other records. A contract refers to a supplier and to the assets it covers, and an asset refers to a location, a manufacturer and an owner. If the linked records are not present when the dependent rows are loaded, the links fail or the rows are skipped. A defined load order solves most of these failures: load the independent reference data first, then the users and suppliers, then the contracts, and finally the relations between contracts and assets.
- Dependency map: Draw which item types depend on which before building any model.
- Reference data first: Load locations, manufacturers, suppliers and users before the records that point to them.
- Relation step: Contract-to-asset links usually need the asset identifiers to exist, so load assets first and keep the identifiers stable.
- Re-run safety: Confirm how a repeated load treats records that already exist.
Write the load order as a numbered runbook and test it end to end on staging with a copy of the real register.
The plugin's limits are easiest to find on a staging instance built from the same GLPI version, plugin versions and configuration as production. A staging run with a representative sample exposes unsupported columns, lookup mismatches and failed links before they affect live data. Record each failure and its resolution, because the same decisions will apply to the full load and to any later import. Staging also shows how much manual cleanup remains, which is the figure you need when comparing an internal effort with a fixed-scope partner quote.
- Representative sample: Include edge cases such as blank serials, duplicate names and retired items.
- Failure log: Keep row-level results for every import attempt.
- Clean snapshot: Restore the staging database before each full rehearsal.
- Sign-off: Have the asset owner check a sample of imported records against the source register.
Check that your staging environment matches production in GLPI version, plugin versions and database engine before you rely on its results.
After the initial load, the register continues to change, and custom definitions and imported links need the same care as records created in the interface. Decide who owns each imported field and whether future updates will come from a spreadsheet again or from GLPI Agent inventory. Mixed sources can overwrite each other, so set a rule for which source wins. Document the import models, column mappings and load order so the next migration or upgrade does not start from scratch.
- Source of truth: Name the system that owns each field after go-live.
- Model retention: Keep import models and mapping files under version control.
- Upgrade review: Recheck custom definitions and plugin models after each GLPI or plugin upgrade.
- Backup point: Take a database and files backup before any bulk import.
Confirm with your team which import models remain supported for your GLPI version and plugin set before the next upgrade is scheduled.
What drives the cost and duration of a spreadsheet import
This table lists the factors that change how much work a spreadsheet import takes, whether each factor is paid once or recurs, and what to ask for in a written scope. Read it before requesting a quote, because the source data and the number of linked record types usually matter more than the number of rows. No prices or durations are given here, since these depend on the scope agreed for your environment.
| Driver | Why it changes cost or effort | One-time or recurring | What to ask for in a written scope |
|---|---|---|---|
| Number and consistency of source spreadsheets | Each file has its own column names, date formats, encodings and duplicate patterns. Inconsistent files add mapping and cleanup rounds. | One-time | A list of every source file, its owner, and the rules for resolving conflicting values |
| Number of linked record types | Users, locations, suppliers, contracts and assets reference each other. Each added type adds an import model and an ordering dependency. | One-time | The record types in scope and the import order agreed for linked records |
| Cleanup volume before import | Duplicate serial numbers, orphan owners and free-text categories must be fixed or agreed before loading, and this work often falls to the client's data owners. | One-time | Who performs cleanup, the decision rules for duplicates, and a sign-off point before loading |
| Custom asset definitions | Assets that do not fit standard GLPI types need custom definitions. The Data Injection plugin does not cover every custom asset type, so the scope may split into a separate workstream. | One-time | A list of custom asset types, confirmation of which ones the import tooling supports, and any custom development needed |
| Entity and profile design | Entities, groups and profiles decide which records each user sees. Imported data must land in the correct entity, which requires agreed rules before the first load. | One-time, with later changes recurring as the organization changes | The entity tree, profile assignments and the default entity used for each imported record |
| Directory and identity integration | If users come from LDAP or Active Directory, the imported user records must match directory identities so that later sync does not create duplicates. | One-time setup, recurring sync checks | Confirmation of the authoritative source for users and how imported accounts will match directory accounts |
| Number of staging rounds | Each test load on staging exposes errors that need correction, mapping changes and a repeat load. Fewer rounds usually mean cleaner source files at the start. | One-time | The number of staging loads included, the acceptance checks for each round, and the criteria for moving to production |
| Ongoing imports after go-live | Regular updates from spreadsheets, if they continue, need the same models, mappings and checks to be maintained. | Recurring | Whether recurring imports are in scope, how often they run, and who owns the import models afterwards |
What usually goes wrong in spreadsheet imports and how to prevent it
Spreadsheet loads fail in predictable ways, and most of the damage shows up weeks later when a ticket, asset or contract points at the wrong record. The cards below cover the failures we see most often in asset, user and contract registers, each with a check to run before and after the load.
Duplicate records from naming drift
The same laptop, supplier or user often appears under several spellings across sheets, such as "Acme Ltd", "ACME Limited" and "Acme LTD." Data Injection creates a new record for each variant unless a match key is chosen first. Before loading, agree one key per object type, such as serial number for assets, login for users and legal name plus tax ID for suppliers, and count distinct keys in each source file. Compare that count with the number of rows GLPI reports as created after a test load.
Broken links from wrong load order
Assets reference users, locations and suppliers, and contracts reference assets and suppliers. If an asset is loaded before the user it is assigned to exists, the link is empty or wrong. Load in dependency order: entities and locations, then suppliers, then users, then assets, then contracts. After each step, check that the number of empty foreign-key cells in the next file is zero, and sample a few linked records in the GLPI interface.
Date and currency format errors
Spreadsheets mix day-first and month-first dates, text dates and locale-specific decimal separators. A purchase date of 03/04/2024 can land as 3 April or 4 March, and an amount written as 1.250,00 can import as 1.25. Convert dates to ISO 8601 (YYYY-MM-DD) and amounts to plain decimals in a staging copy, then check the minimum and maximum date and total amount per file against the source totals that finance signed off.
Users imported before entities or profiles
A user row that names an entity or profile that does not yet exist either fails or lands in the wrong place, which can give a person more access than intended. Create entities and profiles first, confirm their names match the sheet exactly, and then load users. Review the entity and profile assigned to each imported user with a sample check, and confirm that no account received a default profile by accident before anyone signs in.
Contracts without owners
A contract row with no business owner, technical owner or renewal contact will be loaded and then left unmanaged, so notices and renewal reviews go to nobody. Make owner fields mandatory in the source file and reject rows where they are blank. Confirm each owner exists as a GLPI user, and check that every contract with a renewal date within the planned review window has an owner before go-live.
Loss of history in the old register
Old registers often hold useful history, such as previous assignees, repair dates and replaced serial numbers, in comments or in extra sheets that are never loaded. Once the old file is retired, that context is gone. Decide which history must survive, load it into a documented field or note, and keep the frozen source file, a checksum of it and the reconciliation report together in the project record. Load into a staging copy first and keep the frozen source until the production results are signed off.
Questions teams ask before importing GLPI data from spreadsheets
How much effort and cost should we expect to import spreadsheet data into GLPI?
The cost depends mainly on how clean your source registers are, how many object types you load, and how many decisions the import forces on your team. Your internal effort covers exporting registers, deduplicating serial numbers, agreeing owners for each asset, and approving entity and profile choices. A partner quote covers the import model design, mapping, test loads, reconciliation and handover, priced against a written scope. Ask for the cost split between one-time build work and any recurring support, and ask what happens if the source data needs a second cleaning pass after the test load.
How long does a GLPI spreadsheet import take?
Duration follows the same drivers as cost: the number of record types, the volume and quality of rows, the number of linked objects such as suppliers, contracts and users, and how many test loads your change process requires. Each test load shows errors that usually need the source sheet corrected, so the number of rounds matters more than the row count. Ask any partner to show the phases and the gates between them, and confirm with your own change board how long a staging sign-off and a production window take in your environment.
What must our team provide before the import starts?
Three things determine whether the import runs smoothly:
- Cleaned registers for assets, users, suppliers and contracts, with stable unique keys such as serial numbers, asset tags and employee IDs.
- A named owner for each asset group, who confirms the data and answers questions during mapping.
- Decisions on entities, which control where records sit, and on profiles, which control who can see and edit them in GLPI.
If these decisions are open, the mapping work stalls. Agree them in writing before the build starts so that the import models reflect the final structure.
Can our own administrators run the import with the Data Injection plugin?
Yes, teams with GLPI administration experience can build import models and run loads with the Data Injection plugin, provided they confirm the plugin is compatible with the GLPI version they run. Plan for a learning curve around column mapping, the order of imports for linked records, and reading the error report after each test. A partner is useful when the data volume is large, when many object types are linked, or when internal staff cannot take time away from operations. Confirm the plugin version and its support status for your target GLPI release before you commit to a self-run plan.
Can we import custom asset definitions from spreadsheets?
Treat custom asset definitions as a separate question to confirm before planning. The import works from models built for the object types the plugin supports, so a custom asset type may need its own mapping work or may not be supported by the standard import path. Check two things in your instance: whether the plugin offers a model for each custom type, and whether the fields you need exist as standard fields. If they do not, plan a separate workstream to model the custom type first, then import into it. Ask any partner to state this limit in the written scope.
How do we test the import safely on staging first?
Build a staging copy of your GLPI instance from a recent database backup, with the same plugins and GLPI version as production, and disable outgoing notifications so test loads do not email users. Run each import model against a small sample, then the full file, and reconcile counts and sample records against the source sheet after each run. Keep the staging database and the file set separate from production, and record the import rules, model files and error reports so the production run can be repeated exactly. Confirm your backup and restore procedure before the first test, because the staging copy is only useful if you can rebuild it.
Do we need to decide the GLPI version before importing data?
Yes, because the import models, plugin compatibility and database schema are tied to the GLPI version you run. GLPI 12.0.0 was released on October 7, 2026, and GLPI 11.0.11 on October 1, 2026, according to the GLPI releases page. If you plan a move to a newer version, decide the target first, then import into a staging instance on that version so the models and plugins are tested against the final platform. Confirm your plugin compatibility on the target release with the plugin maintainers.
How DeployOpen scopes and delivers a GLPI data import
DeployOpen treats a spreadsheet import as a controlled data project inside your own GLPI instance. We agree the scope in writing, build and test the Data Injection models on a staging copy, and hand over the models, mappings and evidence so your team can repeat the load.
How we scope
- Inventory your existing registers for assets, users, suppliers and contracts, and agree which sources are in scope.
- Confirm the GLPI version, entities and profiles that the imported records must land in.
- Agree in writing the record types, column mappings, import order and acceptance checks before work starts, under a fixed-scope engagement.
How we build
- Build Data Injection import models for each record type, with column mappings that match your spreadsheet headers.
- Load suppliers and users before assets and contracts so linked records resolve on the first pass.
- Test every model on a staging copy of your GLPI database, then record rejected rows and the fixes applied to each one.
How we hand over
- Deliver the import models, mapping sheets, load order and test results as documentation your team can rerun.
- Walk your administrators through the staging run, the production load and the reconciliation counts.
- Document where custom asset definitions fall outside the plugin's scope and what manual or separate work those records need.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if your team needs help with later loads.
- Review the import models again when you move between GLPI versions, since the plugin and core change over time.
- Confirm with your team which support terms and response expectations apply before the engagement starts.
