How to plan a GLPI Racks and Domains plugin data migration
If your GLPI instance keeps Racks and Domains data in plugin tables, that data has to move into GLPI core tables as part of the GLPI 10 to 11 move. The supported path is to plan the work on a copy of your database, run the console migration commands on the target GLPI version, and then reactivate and verify the results. The console provides glpi:migration:racks_plugin_to_core for Racks data and migration:domains_plugin_to_core for Domains data. Both are documented in the GLPI documentation on the command-line interface, so check that page against the exact version you will run before you schedule anything.
Start by inventorying what the plugins hold in your environment: racks, rack models, Domains entries and the items linked to them. Confirm which plugin versions you run and whether they are compatible with the target version. The Racks command has an option to ignore PluginRacksOther models, so decide in advance whether any of your models fall into that group and who will own the decision. Record each choice, because the migration will not raise an error for data it skips. Also confirm that your backups cover the database, the files and the config directory, including glpi.key and glpicrypt.key, since the update procedure depends on them.
Run the commands against the copy first, then compare counts and sample records before and after. Check that rack positions, linked assets, Domains relations and any custom fields still display as expected, and that the items the Racks command ignored are either intentional or handled separately. Once the copy checks out, repeat the same sequence on production during an agreed window. Plugins are suspended after a new version is detected and must be reactivated after the major update, so verify plugin status after the move. Confirm the exact command options, prerequisites and any plugin-side steps for your versions with the vendor documentation and a test run, not from this page alone.
What changes for Racks and Domains data in GLPI 11
This table compares the GLPI 11 changes that affect a Racks and Domains plugin migration, with the impact on your data and the action to take. Read each row against your current GLPI version and your planned target, since the requirements differ between the 10.x and 11.x lines. The main takeaway is that the console commands move data into core tables only after the platform prerequisites and plugin reactivation steps are in place.
| Change | Impact on Racks and Domains data | Action needed |
|---|---|---|
| GLPI 11.0.0 released October 1, 2025 | Plugins are suspended when GLPI detects a new version, so the Racks and Domains plugins may not run until reactivated | Confirm the release you are moving to in the GLPI releases page and plan plugin reactivation before running any migration command |
| Plugin suspension after major updates | Migration commands depend on the plugin code and its tables being available, so a suspended plugin can block the move | Reactivate or update the Racks and Domains plugins on a test copy first, then record the plugin version used |
| PHP requirement for GLPI 11.0 | A host below the required PHP version cannot run the console commands that perform the migration | Verify the PHP version the GLPI 11.0 installation docs list for your target and check the CLI PHP version separately |
| MySQL or MariaDB requirement for GLPI 11.0 | Database version limits affect whether the schema changes made by the migration can complete on your server | Confirm the MySQL 8.0 or MariaDB 10.6 minimum for your target and test the migration on a database copy of that version |
| glpi:migration:racks_plugin_to_core command | Moves Racks plugin records into GLPI core tables, so the data becomes core data once the command runs | Back up the database and config directory, run the command on a copy, and check rack, location and item links afterward |
| migration:domains_plugin_to_core command | Moves Domains plugin records into GLPI core tables, which changes where those records are read and edited | Run the command on a copy, compare domain counts and linked items, and confirm the Domains plugin is no longer needed |
| Ignore PluginRacksOther models option | Racks models of type PluginRacksOther are skipped when the option is used, so their data stays outside the core tables | List PluginRacksOther models before the run and decide whether to migrate them manually or keep them out of scope |
| Command syntax and options by version | Option names and behavior can change between GLPI releases, so commands tested on one version may differ on another | Check the GLPI command-line interface documentation for your target release and run the help output on the target console |
What the Racks migration ignores and why it matters
The Racks migration command includes an option to ignore PluginRacksOther models, and whatever it skips stays outside the core rack data after the move. Before you run the command, confirm the exact option name and its effect in the GLPI command-line documentation, since the option is the single setting that decides whether those models come across. Treat the option as a scope decision, not a convenience flag, and record which setting you chose and why.
Start the inventory on the old instance, not the new one. List every rack model in use, mark which ones are standard and which were created by hand or came from a third party, and export the assets that reference each model, such as racks, enclosures and the devices placed in them. Note the rack positions, units and any custom fields attached to these records. This list tells you which data the migration would carry, which it would ignore, and which assets depend on either path.
Once the inventory is complete, the team has three choices for anything the command ignores: recreate the models and their placements in the core rack data by hand, keep the Racks plugin data available in a read-only copy for reference, or accept the loss and document it as a known gap. Each choice needs an owner and a sign-off from the people who use data center records for capacity or change work. Test the chosen path on a copy of the database and check that the affected assets still show the expected rack and position before you cut over.
What to back up and test before the Racks and Domains migration
The Racks and Domains migration rewrites plugin data into core tables, so it only works safely on a copy you can roll back. These five checks give you a rollback point, a clear picture of what will move, a rehearsal environment, a list of consumers to re-test, and a written record of what the Racks command leaves behind.
Take a full backup first
Back up the database, the GLPI files and the config directory, including glpi.key and glpicrypt.key. The GLPI update procedure requires this set, and the migration commands change tables you cannot easily reverse. Without the keys, encrypted values in the restored instance may be unreadable, so confirm you can restore the whole set together, not just the database dump.
Inventory plugin versions and records
Record the installed Racks and Domains plugin versions and count the rack and domain records in use, by entity. Note which racks hold models, and which entities own them. This tells you what the migration must carry across and gives you a number to compare after the run. Ask the plugin's maintainers which version matches your target GLPI release.
Rehearse on a restored GLPI 10 copy
Restore the backup to a separate server with the same PHP and database versions, then run the migration commands there first. Do not run them against production. Treat the rehearsal as a dry run that tests the commands, the plugin state and the time the run takes on your data volume, and repeat it until the results match your expectations.
List consumers of plugin tables
Identify every report, saved search, rule, integration, script and user who reads the Racks or Domains tables directly or through the plugin screens. Once the data moves to core tables, these consumers may point at empty or changed sources. Re-test each one on the rehearsal copy and assign an owner for the fix.
Sign off what the Racks command ignores
The Racks migration can skip PluginRacksOther models when you use the option that ignores them. Decide, with the owner of the data, whether skipped models are acceptable or need a manual move. Record the decision in writing, list the affected records, and confirm the result in the rehearsal before anyone approves the production run.
How to run the Racks and Domains migration commands in order
This sequence moves Racks and Domains plugin data into GLPI core tables on a copy of production, with a check and a rollback point at each step so the live instance stays untouched until the results are verified.
Confirm the target GLPI 11 build
Record the exact GLPI 11 build you plan to run, along with the PHP and database versions it requires. The installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, and the README on the main branch lists newer minimums, so check the requirements for your specific target release. Confirm that the console commands named in this sequence exist in that build by checking the command-line interface documentation for the same version. Done when the target version, PHP version and database version are written down and match the installation docs for that release. Rollback point: nothing has changed yet, so stop here if any version is unsupported.
Back up database, files and config
Before touching anything, take a full backup of the database, the GLPI files and the config directory, including glpi.key and glpicrypt.key. Losing either key makes encrypted data unreadable, so store copies of both outside the application directory. Verify that the database dump restores into a scratch database and that the archive of files opens without errors. Done when you have tested restores of the backup. Rollback point: this backup is the rollback for every later step, so label it with the date and the source GLPI version.
Run the database update on a copy
Restore the backup into a separate environment with the same web server layout, deploy the GLPI 11 application files there and run the database update with the console. Follow the update procedure for the exact order of steps. Because GLPI 11 suspends plugins after it detects a new version, expect the Racks and Domains plugins to be inactive at this point. Done when the update finishes, the instance loads, and the core tables for assets and the plugin tables both still contain the expected row counts. Rollback point: discard the copy and restore the backup again if the update fails.
Decide on the PluginRacksOther option
Review your Racks inventory and identify any models whose type is PluginRacksOther. The migration command offers an option to ignore those models, so only use it if your inventory confirms that those records are not needed in the core. Record the decision and the list of affected models in your change record. Done when the decision is documented and approved by the asset owner. Rollback point: the decision has no effect until the command runs, so change it at no cost before step five.
Run the Racks and Domains migration commands
Run the Racks migration command, glpi:migration:racks_plugin_to_core, with the ignore option only if step four required it. Then run the Domains migration command, migration:domains_plugin_to_core. Capture the console output from each run and keep it with the change record. Confirm exact syntax in the command-line interface documentation for your target version before running either command. Done when both commands exit without errors and the output lists the records processed. Rollback point: restore the copy from the backup and rerun from step three if either command fails partway.
Check counts and sample records
Compare row counts between each plugin table and its corresponding core table, accounting for any models excluded in step four. Then pick a sample of racks, models, locations and domains and check each field, including relations to assets and entities, against the original plugin data. Document every mismatch with its record ID. Done when counts reconcile and the sample has no unexplained differences. Rollback point: if a mismatch cannot be explained, restore the copy from the backup and rerun the migration after fixing the cause.
Reactivate plugins and retest
Reactivate the plugins that remain in use, and confirm that the Racks and Domains plugins are no longer needed before you disable or remove them. Then test the workflows that depend on the migrated data, such as rack views, asset linkage, domain reports and any integrations. Done when those workflows behave as expected on the copy and the test results are signed off. Rollback point: keep the backup and the copy until production cutover is approved, so you can return to the pre-migration state at any point.
What makes a Racks and Domains data migration take longer
This table lists the factors that change how much work the Racks and Domains move into GLPI core involves, and which way each one pushes the effort. Read it before you scope the rehearsal, because the drivers that grow fastest are usually the ones teams underestimate. Each row also names a step that keeps the work contained.
| Driver | Why it adds work | How to reduce it |
|---|---|---|
| Number of rack and domain records | Each record is read, mapped and written to core tables, so a larger inventory means longer runs and more rows to check afterward. | Count records per plugin before the rehearsal, and clean duplicate or unused entries in the source system first. |
| Custom or PluginRacksOther models | The Racks command can skip PluginRacksOther models when told to, so any model left out must be handled by hand or by a separate step. | List every model in use, decide per model whether to migrate or ignore it, and record that decision in the migration plan. |
| Links from assets and reports to plugin data | Assets, reports and saved searches that point at rack or domain records must still resolve after the move, and broken links often surface only in daily use. | Export the list of objects that reference plugin data and test each report and search on the rehearsal copy. |
| Customized plugin code or forms | Local patches, custom fields or forms built on the plugin tables may depend on column names or behavior that changes in core. | Diff any local changes against the released plugin, and confirm with the plugin maintainer which customizations survive the move. |
| Size of the database | Larger databases lengthen backups, restores and migration runs, and they make a rollback slower if a step fails. | Confirm the actual size of the source database, and plan backup and restore timing before the first rehearsal. |
| Time needed for a rehearsal copy | Each rehearsal requires a fresh copy of production data, so the copy and restore time repeats every time the migration is rerun. | Script the copy and restore steps, and schedule rehearsals so each run tests a specific fix rather than the whole process. |
| Number of environments to validate | Development, test and production may differ in plugin versions, database settings or data, so each one needs its own check of the results. | Agree in writing which environments must pass, and use one checklist for all of them so results are comparable. |
Choosing how to handle Racks models before the migration
Use this path when every Racks model is a standard model that the plugin defines, and no model needs to stay outside the core. The command can then migrate the full set in one pass without an exclusion step. The decision rests on whether your inventory shows any custom or unrecognized models at all.
- Decision: accept that every rack model becomes a core record, with no exclusions.
- Inventory evidence: export the list of Racks model records and their linked racks, and confirm each model is a standard one.
- Command run: take a full database and file backup, restore it to a test copy, and run
glpi:migration:racks_plugin_to_corethere first. The GLPI command-line interface documentation lists the available options. - Verification: compare counts of racks, models and linked assets before and after the run, then spot check several racks for correct positions and contents.
Before accepting the test copy as the source for production, confirm that the command log reports no unmapped models.
Use this path when some rack models are classified as PluginRacksOther and should not become core records. The migration command offers an option to ignore those models, so they stay in the plugin data while the rest moves. The decision is who owns the excluded models and what happens to them after the migration.
- Decision: decide whether each PluginRacksOther model will be recreated as a core asset type, kept as plugin data, or retired.
- Inventory evidence: list every PluginRacksOther model, the racks that use it, and the count of linked items, so the excluded scope is known in advance.
- Command run: run the migration with the option that ignores PluginRacksOther models. Confirm the exact option name in the command-line documentation before you script it, and test it on a copy.
- Verification: confirm that ignored models and their racks still exist in the plugin tables, and that migrated racks show no broken links to ignored models.
- Follow-up: record each excluded model in a tracked ticket with an owner and a target date for its replacement.
After the test run, check that every excluded model appears in your ticket list so that no custom data is left without a plan.
Use this path when you want to keep the full plugin data for reference but move only the records still in use into the core. This choice depends on whether the migration command can limit its scope to active records. No supplied source confirms that it can, so check the command options before you plan the run. If it cannot, you need a filtered copy of the plugin data.
- Decision: define "active" in writing, for example racks in use and not marked as retired, and name the person who signs off on that definition.
- Inventory evidence: query the plugin tables for active and inactive racks and models, and record the counts for each group.
- Command run: check the command-line documentation for a scope option. If none exists, build a filtered copy that contains only active records, run the migration against that copy, and leave the original database untouched.
- Verification: compare the active record counts in the core with the filtered source, and confirm that the archived database still opens and reports its original totals.
- Retention: keep the archive read-only and document how long it is retained under your records policy.
Confirm the scope behavior on a test copy before you script anything, because a partial migration is harder to reverse than a full one.
Questions teams ask before migrating Racks and Domains data
What drives the cost of migrating Racks and Domains plugin data into GLPI core?
The cost comes mostly from labor, and the labor depends on how much data you hold and how clean it is. Someone must take a copy of the production database, run the migration commands against it, compare the results with the original plugin tables, and fix the records that do not map cleanly. Costs rise when the Racks or Domains data is large, when many custom models or fields depend on it, when integrations read those tables, or when the team must reconcile the results with a data center or DNS owner. Costs also rise if a rehearsal copy must be built from scratch. Ask any partner for a written quote that separates the discovery and inventory work, the rehearsal runs, the production cutover, and the post-migration checks. Those are the one-time items. Any ongoing support is a separate, recurring line that should be priced on its own.
How long does a Racks and Domains migration take?
The duration depends on the same factors as the cost: data volume, how many customizations sit on top of the plugin tables, how many people must review the output, and how many rehearsal rounds your change process requires. Plan for at least one full rehearsal on a copy of your GLPI database before any production run, because the first run almost always exposes records that need cleanup. Your change window also matters, since you must back up the database, files and the config directory, including glpi.key and glpicrypt.key, before you touch anything. No figure for a typical duration is supplied for this topic, so ask your vendor or partner to state the expected duration in the written scope and to name the rehearsal count they assume.
What must our team provide before a migration starts?
You need four things before work begins. First, access to the GLPI application server, the database and the console, with an account that can run the migration commands. Second, a rehearsal copy of the production database and files that matches the production GLPI version and plugin versions as closely as possible. Third, a written inventory of Racks and Domains records, including the models, data center rooms and domain entries you use, and any PluginRacksOther models you intend to keep or drop. Fourth, named owners who can confirm the results, usually someone from data center operations for racks and someone from network or DNS administration for domains. Without these, the migration team will spend time discovering scope rather than checking it, which adds cost and delay.
Can our internal team run the Racks and Domains migration without outside help?
Yes, a team with Linux, PHP and database administration skills can run the console commands themselves, provided it follows the backup and rehearsal steps in the GLPI documentation. The GLPI CLI provides glpi:migration:racks_plugin_to_core, which can ignore PluginRacksOther models, and a migration:domains_plugin_to_core command for the Domains plugin. The harder part is judgment: deciding which records are wrong, which custom models to keep, and how integrations should read the new core tables. Teams that lack a staging environment, or that run GLPI with heavy customization, often bring in an outside partner for the rehearsal and review. Confirm the exact command options and their behavior against the version you run, using the GLPI command-line interface documentation.
What happens to PluginRacksOther models when the Racks migration runs?
The Racks migration command includes an option to ignore PluginRacksOther models, so those models are not moved into the core tables. That choice matters because any asset types or records that depend on an ignored model will not carry over in the same form. Before you run the command, list every PluginRacksOther model in use, check which items reference it, and decide whether it must be recreated as a core asset definition or retired. Record that decision in the change plan. After the rehearsal, confirm that the ignored models do not break reports, rules or integrations, because the command will not warn you about their downstream effects in any way the source material describes.
Do we need to reactivate plugins after the migration?
Plan to check plugin status after the upgrade, because GLPI 11.0 suspends plugins after a new version is detected and they must be reactivated after major updates. The Racks and Domains plugins are the sources of the data you are moving, so their status changes the migration sequence. Confirm whether each plugin remains needed once its data is in core, and retire it only after the core data has been checked. Keep the plugin files until your reports and integrations are verified, so you have a way to compare before and after results. Check each remaining plugin's compatibility with your target version before you reactivate it, since the source material does not state compatibility for individual plugins.
Where should the migration rehearsal run, and what must it prove?
Run the rehearsal on a separate GLPI instance restored from a recent production backup, with the same PHP, MariaDB or MySQL versions and the same plugins. The rehearsal must prove three things: the migration command completes, the row counts and key relationships in the core tables match what your inventory expects, and the reports, dashboards and integrations that read rack and domain data return the same answers as before. Document each run, including the command used, the options chosen and any manual corrections. The GLPI prerequisites list PHP 8.2 or later and MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, so confirm your rehearsal stack meets those requirements before you start.
How DeployOpen scopes and delivers GLPI plugin data migrations
DeployOpen plans and runs the move of Racks and Domains plugin data into GLPI core tables as part of a wider GLPI upgrade, inside infrastructure you control. The work starts from a written scope and is tested on a copy of your database before anything changes in production.
How we scope
- Inventory which Racks and Domains records exist, and which PluginRacksOther models are in use, before choosing command options.
- Confirm the GLPI 11 target version, PHP and database prerequisites, and the plugin versions present on the current instance.
- Agree in writing which data is migrated, which is reviewed by hand, and which integrations and rights must be re-checked afterward.
How we build
- Restore a copy of the GLPI database and files, then run the racks and domains migration commands on that copy first.
- Compare racks and domain records before and after the run, with particular attention to any items the Racks command ignores.
- Re-check rights, entities, rules and dependent objects after migration, and record every command option used for repeatability.
How we hand over
- Provide a documented runbook with the exact console steps, order of operations, rollback points and verification queries.
- Document which Racks items were skipped or handled manually, so your team knows what was not moved into core tables.
- Explain how to retire the old plugins once the core data is confirmed, and what to check before removing them.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer if your GLPI estate needs them after go-live.
- Ask any partner, including DeployOpen, to confirm how post-migration issues are reported, triaged and charged before signing.
