Migrate GLPI Generic Objects to custom asset definitions

Generic Objects asset types do not carry over to GLPI 11 by themselves. This page covers the plugin update, file copy, core migration command and the checks that follow, so you can plan the move before touching production.

Book a callTalk to us
On this page

How to migrate GLPI Generic Objects asset types into GLPI 11 definitions

If your GLPI 10 instance uses asset types built with the Generic Objects plugin, the move to GLPI 11 or 12 runs through a console command, but only after you update the plugin to at least version 2.14.14 and copy its files to the new instance. The supported procedure is to run the migration with php bin/console migration:genericobject_plugin_to_core as the web server user, against a copy of your data rather than the live system. The reason for the copy is practical: the command converts plugin-defined types into core asset definitions, which changes how those types are stored and displayed, and you need a working rollback point while you check the result. Older Generic Objects releases must be downloaded and activated first, because the migration reads the plugin's own structures.

Before you start, confirm that the plugin files under files/_plugins/genericobject on the GLPI 10 side are complete and that they travel with the copy to the new instance. Check the plugin's current version on the GLPI 10 instance, then confirm with the plugin's documentation or your own test copy that the update path from your installed version to 2.14.14 or later is available. Also confirm that your GLPI 11 or 12 target meets the PHP and database requirements in the installation docs, since a migration on an unsupported runtime will fail regardless of the plugin version. The full sequence of plugin reactivation and upgrade ordering is covered in the upgrade procedure linked from the migration procedure, so work through that document alongside this one.

Plan the post-migration review as part of the project, not as an afterthought. The converted asset types need their rights profiles, entity visibility, capacities and any integrations that referenced the old types (such as inventory rules, forms, search presets and external connectors) checked against the new definitions. Ask your partner or internal team to document each old type, its consumers and the expected result, then verify them on the copy. Only after that review should the migrated data be scheduled for the production cutover. Treat any integration you cannot confirm on the copy as an open risk to resolve before go-live.

What changes in GLPI 11 and 12 that affects these asset types

This table compares each GLPI release or procedure change against the impact on Generic Objects asset types and the action the reader needs to take. Read it top to bottom as a sequence: confirm versions and prerequisites first, then plugin handling, then the core migration and post-migration checks. The main takeaway is that the Generic Objects plugin must be updated before the core migration runs, and every rebuilt asset type needs its rights and integrations re-checked.

ChangeImpact on Generic Objects asset typesAction needed
GLPI 10.0.0 released (April 20, 2022)Asset types built on the Generic Objects plugin were created on the GLPI 10 plugin model, so the baseline is the plugin version in place today.Record the current Generic Objects plugin version and the GLPI 10 release you run before planning.
GLPI 11.0.0 released (October 1, 2025)Generic Objects content moves into the core as asset definitions, so the plugin is no longer the long-term home for these types.Plan the move as a data migration with a tested copy, not an in-place switch.
PHP and database requirements for GLPI 11.0The installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, which affects the target instance and the migration test copy.Confirm the PHP and database versions on the new instance before copying plugin data.
README requirements on the main branchThe README lists PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later, which is higher than the 11.0 docs for some components.Confirm which requirement set applies to your target release with your own environment before you build.
Plugin suspension after a new version is detectedGLPI suspends plugins after a new version is detected, so Generic Objects can be inactive during and after the upgrade.Update Generic Objects to the required version and reactivate it before running the core migration.
Generic Objects migration to coreThe migration command moves plugin-defined types into asset definitions, and it must run as the web server user.Confirm the plugin files are copied from files/_plugins/genericobject and the command completes on a test copy first.
GLPI 11.0.11 released (October 1, 2026)Patch-level release in the 11 line, so behaviour for these asset types should be verified rather than assumed.Confirm the exact patch level in your environment and re-test after applying it.
GLPI 12.0.0 released (October 7, 2026)Major release with changes to administrative controls and authentication, which can affect rights on rebuilt asset types.Re-check profiles, entity access and step-up authentication on the migrated definitions before go-live.

What to prepare before the first migration run

The migration command changes the database and moves plugin data into core tables, so nothing should run against production until the rollback path is proven. These four items run in parallel and feed one another: the backup makes recovery possible, the inventory defines what must survive, the test copy proves the migration, and the integration list shows what breaks afterward.

Full backup of database, files and config

Back up the database, the GLPI files directory and the config directory together, and make sure the backup includes glpi.key and glpicrypt.key. Without the key files, encrypted values stored in the database, such as credentials used by integrations, cannot be read after a restore. Store the copy outside the GLPI host and test a restore on a separate machine before relying on it. Confirm the backup is taken with the web server stopped or in a consistent state so the database and files match.

Inventory of Generic Objects types

List every asset type built with the Generic Objects plugin, with its fields, the rights profiles that can read or write it, and the items it links to such as computers, contracts or locations. This list is the checklist you verify after migration. A type that was visible to a helpdesk profile before and is missing afterward is usually a rights mapping gap, and the inventory shows you exactly which profile to re-check.

Test copy of GLPI 10

Restore a copy of the GLPI 10 database and files into a non-production environment at the same versions, then run the plugin upgrade and the migration there first. Record every error, every warning and the time the run took. Use the copy to confirm that plugins are reactivated correctly and that the generated asset definitions match the inventory from the previous step. Production should only receive the steps you have already executed on the copy.

Plugin files staged for the new instance

The migration reads Generic Objects files from the plugin directory under files/_plugins/genericobject, so confirm that directory is complete on the source instance and copied to the new instance. Confirm the Generic Objects version is 2.14.14 or later and that it is activated first. Check file ownership and permissions so the web server user can read the copied files and run the console command.

Integrations that reference the old types

List every LDAP sync, webhook, API client, report and saved search that refers to a Generic Objects type by name or by its internal item identifier. These references can point to the old itemtype and fail silently once the type is replaced by a core asset definition. Note the owner of each integration and the test you will run afterward, so the team that depends on the data can confirm it still arrives correctly.

The upgrade sequence for moving Generic Objects to asset definitions

This sequence moves Generic Objects asset types from a GLPI 10 instance into GLPI 11 asset definitions on a separate target instance. The source stays in service until the target passes verification, and each step ends with a check and a rollback point.

  1. Update Generic Objects on the source instance

    On the existing GLPI 10 instance, open the plugin list and check the Generic Objects version. Any version older than 2.14.14 must be updated and activated before the migration, so the core command runs against a supported plugin level. Make this change on a staging copy first, then repeat it on production during your change window. Done check: the plugin list shows 2.14.14 or later as active, and existing asset types still open with their items. Rollback: if the update or activation fails, restore the previous plugin files from a pre-change backup and keep production on the old version until the cause is found.

  2. Back up the database, files and config directory

    Before any copy or command, back up the database, the GLPI files directory and the config directory. The config directory holds glpi.key and glpicrypt.key, so keep both key files with the backup, because the restored instance needs them. Store one copy off the server. Done check: you can list the database dump, the file archive and both key files, and a test restore into a scratch database completes without errors. Rollback: this backup is the rollback point for every later step, so do not start the target build until the restore test passes.

  3. Prepare the target GLPI 11 instance

    Install a target GLPI 11 instance on a separate server or container. Confirm the PHP and database versions against the GLPI prerequisites page before you install, since the installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Point the web server document root at the public directory, not the installation root, and enable URL rewriting through index.php. Done check: the login page loads through the web server and the target database is empty. Rollback: remove the target instance and its database. The source instance is unchanged.

  4. Restore the source database copy into the target

    Restore the database dump from the backup into the target database and point the target configuration at it. Keep the target on the same database name and character set as the source backup so the migration reads the same tables. Done check: a sample of asset types, items and their relations is visible in the target, and the counts you record match the source. Rollback: drop the restored database and restore the empty database from the target setup step. The source database and its backup stay untouched.

  5. Copy the Generic Objects plugin files

    Copy the directory files/_plugins/genericobject from the source GLPI files location to the same path in the target instance. Copy only that plugin directory, and do not carry over core application files from the old version. Set ownership so the web server user can read and write the copied files. Done check: the directory listing and file count match on both sides, and the web server user can read every file. Rollback: delete the copied directory on the target. The source copy remains the reference.

  6. Run the core migration command

    As the web server user, run php bin/console migration:genericobject_plugin_to_core from the GLPI root on the target instance only. Save the full console output to a log file so the result can be reviewed and attached to the change record. Do not run the command against the source instance. Done check: the command exits without errors and the log has no unresolved failures. Rollback: restore the target database from the restored copy, fix the cause, and run the command again. The source instance remains in service throughout.

  7. Run db:update and reactivate plugins

    Run php bin/console db:update on the target as the web server user. GLPI 11 suspends plugins after it detects a new version, so review each plugin in the list, check its compatibility with GLPI 11, and reactivate only those that are supported. Plugins whose features moved into the core need separate handling. Done check: db:update completes, and each plugin you keep shows as active with no errors in the logs. Rollback: leave any failing plugin disabled, and if the schema update fails, restore the target database from the restored copy and correct the cause before retrying.

  8. Verify rights, capacities and integrations

    Sign in with test accounts from each profile and confirm that the rights, entity assignments and capacities applied to the old asset types now apply to the new asset definitions. Check every integration that referenced the old types, including import rules, inventory mappings, webhooks and API clients. Record each result in a written test list. Done check: the asset owner signs off the list, and every failure is logged with an owner and a fix. Rollback: keep the source instance in service and do not cut over users until the sign-off is complete.

Which path fits your current Generic Objects setup

If the Generic Objects plugin on your GLPI 10 source is already at version 2.14.14 or later, you can skip the plugin update step and move to the migration. The core command reads the plugin's existing data, so the work shifts to confirming the installed version and checking that the data is clean. Check this on the source instance itself, not on a copy you assume matches it.

  • Confirm the installed version: Read the version in the plugin list of the source and record it in the change ticket. Compare it with the plugin files on disk, since a label alone does not settle the question.
  • Check the plugin is active: The migration needs the plugin enabled on the source. Confirm it is active and that no asset type is left half edited.
  • Inventory the asset types: List each generic object type you plan to convert, with its fields, dropdowns and rights. This list becomes your post-migration checklist.
  • Test on a copy: Run the migration against a restored copy of the production database first, so the team can review the result before the real run.

Confirm the version, the active state and the asset type list before you schedule the change window.

Which rights, capacities and integrations need a second look after migration

Asset types that worked on GLPI 10 can behave differently once they are custom asset definitions in GLPI 11. The migration moves the type's records, but the controls that surrounded the old type do not automatically map one to one onto the new definition. Profile rights that were granted on the Generic Objects type, entity restrictions that limited who could see certain items, and capacities that were attached to the old type each need to be confirmed on the new definition before users rely on it. Treat the cutover as incomplete until those checks are done on a copy of the migrated instance.

Work through the re-check in a fixed order and keep evidence for each item. Start with rights: for each profile that used the old type, record the create, read, update, delete and purge permissions on the new definition, then test them with a representative account per profile. Next check entity visibility by signing in as users from at least two entities and confirming they see only their own assets. Then review capacities, meaning the features that were enabled on the old type such as assignment, document or contract links, and confirm each one exists on the definition and still behaves as expected. Keep a dated export of the profile matrix, the test accounts used and a screenshot or log entry for each result. Confirm the exact capacity names in your GLPI 11 version rather than assuming they carried over.

Integrations are the most likely place for silent breakage because they reference type names or IDs, which may change during the move. Review inventory imports and rules that create or update items of the old type, API consumers that call endpoints built around the type, and reports or saved searches that filter on it. Run one test import and one read-only API request per consumer on the migrated copy, and compare the returned item types and IDs with the GLPI 10 values recorded beforehand. Retain the old and new identifier mapping, the test outputs and the owner who signed off each integration. Confirm with your GLPI administrator and integration owners how each consumer should be updated before production cutover.

What makes this migration take longer or shorter

This table compares the factors that push the Generic Objects to asset definitions migration toward more or less work, and what each one means for scoping. Read each row as a question to put to a partner: the direction shows whether the factor adds or removes effort, and the last column lists what to have ready before asking for a fixed-scope quote. The largest swings usually come from custom code and integrations that read the old types.

DriverEffect on effortWhat to ask a partner to scope
Number of Generic Objects asset typesMore types mean more definitions to rebuild, verify and map to the core, so effort rises with the count.Confirm the full list of types, their fields and which ones are still in daily use.
Rights profiles and entitiesDeeper profile rights and entity-scoped visibility add rights checks after the move, so effort rises with complexity.Ask for a rights matrix per profile and entity, and how each type's visibility is checked.
Custom code or plugins that read the old typesCode that queries plugin tables or class names must be found and rewritten, which is often the largest variable.Request a search of custom scripts, plugins and reports for references to the old types.
Volume of existing asset recordsMore records lengthen the migration run and the verification sample, though the rule set itself stays the same.Ask how record counts will be measured and how the run will be timed on a copy.
Number of integrationsEach inventory feed, import, webhook or report that uses the old types needs its own re-check, so effort rises with each one.List every integration that reads or writes these assets, with owner and direction of data flow.
Existing test copyA tested copy of the database and files shortens rehearsal and lowers risk, so effort falls when one already exists.Confirm whether a restorable copy of the database, the files directory and the config keys is available.
Plugin version and update stateGeneric Objects must be at the version the procedure names before migration, so an outdated or unavailable plugin adds an update step first.Confirm the installed Generic Objects version and whether it can be updated in the current GLPI release.

How to test the migration on a copy and roll back if it fails

Run the full sequence on a copy of production data before anyone touches the live instance. That means a restored database dump, a copy of the GLPI files including the files/_plugins/genericobject directory, and the config directory with glpi.key and glpicrypt.key intact, all on a staging host that matches production's PHP and database versions. Run the plugin update, the file copy and php bin/console migration:genericobject_plugin_to_core as the web server user, in the same order you plan to use in production. Record every error and every manual step, because the production runbook should be the exact sequence that worked on the copy, not a memory of it.

Compare source and target in a structured way. Count the Generic Object types in the old instance and confirm each one has a matching custom asset definition in the new instance. Compare record counts per type, then sample individual assets and check that their fields, relations and attached documents carried over. Verify rights by logging in as representative users from each profile and entity and confirming they see, create and edit the same assets as before. Finally, test each integration that read or wrote these types, such as inventory imports, ticket links, reports and any outbound webhooks, and confirm the payloads still match what the downstream system expects.

Rollback depends on the backups you took before the migration: a database dump, a full file copy and the config directory. Because the migration writes to the database, restoring the database dump and the previous application files returns the instance to its pre-migration state. Keep the source database and config intact until acceptance testing is complete and the business owners have signed off, since a rollback after production users have created new assets is a data reconciliation exercise, not a restore. Confirm with your own change process how long the source remains available and who can authorize a restore.

Questions buyers ask about migrating Generic Objects to GLPI 11

What drives the cost of migrating Generic Objects to GLPI 11 asset definitions?

The biggest driver is how many custom asset types exist and how much depends on them. Each type carries its own fields, rights, dropdowns, relations and reports, and each one needs to be mapped to an asset definition and checked afterward. Other cost drivers include the number of records, how many integrations read or write those types (inventory agents, import scripts, webhooks, API clients), and whether the current GLPI 10 instance runs an older Generic Objects plugin version that must be updated first. Costs have two parts: one-time work to plan, migrate, test and cut over, and any recurring support you buy afterward. Ask any partner for a quote built from a written scope that lists each asset type, each integration and the environments to be migrated, and ask which items are fixed and which are priced as changes.

How long does a Generic Objects migration take, and what sets the timeline?

Duration depends on the number of asset types, the volume of data, the number of integrations that touch those types, and how many test cycles your business needs before sign-off. The steps are sequential: update the plugin to a version that supports the migration, copy the plugin files to the new instance, run the core migration command, then re-check rights, capacities and integrations. Any step that exposes a problem can add a loop. Your own change windows and approval process often set the final calendar time more than the technical work does. Ask for a timeline that separates test runs on a copy of the database from the production cutover, and confirm which dates depend on your team's availability.

What does the migration need from our team?

You need people who know the business meaning of each custom asset type, because the migration preserves structure but cannot decide which fields are still needed. Typical inputs are the list of Generic Objects types with their fields and dropdowns, a list of users and groups with rights on those types, the integrations and scripts that read or write them, and a named owner who can approve test results. You also need access to the GLPI 10 server, the database, the files directory and the config directory with the encryption keys, plus a non-production copy of the environment. Plan for these people to be available during planning, test review and cutover.

Can our in-house team run this migration without a partner?

Yes, if your team has administrators who can work with the GLPI console, the web server and the database, and who can test each asset type against real business use. The core task is a documented sequence of file copies and one console command, run as the web server user. What makes it harder is the surrounding work: checking rights after the move, confirming that inventory and import rules still match the new definitions, and confirming that API consumers still work. A partner can take over the planning, testing, documentation and evidence, or can review your plan before you run it. Decide based on who will own the instance after the migration and how much testing your team can carry alone.

Can we test the Generic Objects migration before touching production?

Yes, and you should. Restore a recent backup of the GLPI 10 database and files into a separate instance with its own URL, run the plugin update and the migration command there, and compare the result with production. Use the same config directory and encryption keys on the copy so that stored credentials behave the same way. Then test a sample of each asset type with users from each profile, check every rights rule and capacity setting, and run each integration against the copy. Record what you found and fix it before the production run. Keep the test copy separate from the live network, because a copy that can reach your inventory agents or identity provider can change production data.

What happens to our other plugins after the GLPI 11 major update?

Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after a major update. Each plugin needs to be checked for compatibility with GLPI 11 before you rely on it. Plugins whose features have moved into the core, such as some that overlap with generic objects or forms, may need to be retired rather than reactivated, and their data may need its own migration. Make a list of every installed plugin, its version, and whether a GLPI 11 release exists. Then decide which plugins to keep, replace or remove, and test each one on the copy. The GLPI upgrade documentation is the place to confirm current steps for your release.

How DeployOpen scopes and delivers a GLPI asset migration

DeployOpen treats the move from Generic Objects to GLPI 11 asset definitions as a scoped migration on a copy of your instance first, not a one-step command. We plan the plugin update, the file copy, the core migration and the checks on rights, capacities and integrations in your own infrastructure, and document each step so your team can repeat it.

How we scope

  • Inventory every Generic Objects type, its items, linked records and dependent rules before any work starts.
  • Confirm the current plugin version, the target GLPI 11 or 12 release and the PHP and database prerequisites in writing.
  • Agree in writing which rights, capacities, notifications and integrations must be re-checked after the migration.

How we build

  • Update the Generic Objects plugin to the required version on a staging copy and confirm it is active before migrating.
  • Copy the plugin files from files/_plugins/genericobject to the new instance and verify the file paths match.
  • Run the core migration command as the web server user, then review the generated asset definitions against the original types.

How we hand over

  • Deliver a test record listing each migrated type, its fields, rights profiles and any items that needed manual correction.
  • Document the rollback steps, including the backups of the database, files and the glpi.key and glpicrypt.key files.
  • Walk your administrators through the post-migration checks so they can repeat them on later upgrades.

How we support

  • Scope follow-on work such as retiring the Generic Objects plugin once the core definitions are verified.
  • Offer ongoing support, upgrades and testing as a retainer if your team wants continued help with GLPI releases.
  • Ask for a fixed-scope quote that lists each deliverable, so cost follows from the agreed written scope.

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com